[78954] in North American Network Operators' Group
Re: DNS cache poisoning attacks -- are they real?
daemon@ATHENA.MIT.EDU (Florian Weimer)
Sat Mar 26 18:24:24 2005
From: Florian Weimer <fw@deneb.enyo.de>
To: Sean Donelan <sean@donelan.com>
Cc: nanog@merit.edu
Date: Sun, 27 Mar 2005 00:23:54 +0100
In-Reply-To: <Pine.GSO.4.58.0503261733230.24905@clifden.donelan.com> (Sean
Donelan's message of "Sat, 26 Mar 2005 17:52:56 -0500 (EST)")
Errors-To: owner-nanog@merit.edu
* 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).