* Sean Donelan:
You forgot the most important requirement, you have to be using insecure, unpatched DNS code (old versions of BIND, old versions of Windows, etc). If you use modern DNS code and which only follows trustworthy pointers from the root down, you won't get hooked by this. A poisoned DNS cache is irrelevant if your resolver never queries servers with poisoned caches.
Yes, this is yet another reason why I'm inclined to apply Hanlon's razor here. Totally forgot to mention it, thanks.
If you do, you should fix the your code.
This would defeat its purpose, at least to some extent. 8-) I'm interested in recording bogus RRs as well because I can't really be sure whether there isn't some resolver which takes them for valid.
On the other hand, there are a lot of reasons why a DNS operator may return different answers to their own users of their resolvers. Reverse proxy caching is very common. Just about all WiFi folks use cripple DNS as part of their log on. Or my favorite, quarantining infected computers to get the attention of their owners.
And sometimes such things leak to the Internet. However, most of the publicly visible bogus records seem to be caused by laziness. If you handle thousands of com. domains, it's easier to use a fake com. zone on your authoritative servers, with a few records like: com 172800 IN SOA ns1.example.org [...] *.com 172800 IN NS ns1.example.org *.com 172800 IN NS ns2.example.org *.com 172800 IN A 192.0.2.1 In most cases, 192.0.2.1 runs a web server that serves a "buy this domain" page. Uh-oh, this hurts. There must be a how-to somewhere which recommends this shortcut.
Why Microsoft didn't make "Secure cache against pollution" the default setting, I don't know.
Apparently, they do in recent versions. It might have been viewed as a change too risky for a service pack or regular patch (Microsoft's risk assessments are sometimes rather bizarre).