[kj4ips]

I think the idea here is to induce the request to a garbage domain (such as by using it as an email domainpart, to get an SPF and/or DKIM lookup), and forge a response with other names in the additional section. This also somewhat fits with DNSSEC as a mitgation, as the additional section (if not discarded outright) should result in a signature chase by the resolver, which should fail if the targeted domain is dnssecd.

Imagine that:

* I have an evil system at 192.0.2.1

* target at 198.51.100.1 which is an MTA, and is it's own resolver with dnsmasq.

* foobar.com has a nameserver that silently drops any request with a ! in the first label

I first send a mail to 192.51.100.1 claiming to be from bob@"foo!bar.foobar.com"

192.51.100.1 sends a request to the auth ns for foobar.com, which gets droped.

While this is happening, I spam the crud out of 192.51.100.1 from 192.0.2.1 with forged answers for foo!bar.foobar.com that contain additional responses stating deb.debian.org is at 192.0.2.1 with a ttl of months.

If I am lucky dnsmasq caches BOTH the foo!bar.foobar.com response, and the deb.debian.org one, meaning that future accesses to deb.debian.org instead go to my attacker-controlled nastybox.

[charcircuit]

That's surprising to me that DNS records received for domains not queried for can be set. I would expect DNS to require a query before being able to handle a response. I don't know why such behavior would ever be wanted.

[ectospheno]

RFC 2181 section 5.4.1 covers this a bit. Search for “additional data section”. So since at least 1997 you shouldn’t trust it. Subsequent rfcs also reference this topic a bit.