North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: DNS cache poisoning attacks -- are they real?

  • From: Florian Weimer
  • Date: Sat Mar 26 18:24:59 2005

* 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).