DNS cache poisoning attacks -- are they real?
Simon Waters
simonw at zynet.net
Tue Mar 29 10:37:46 UTC 2005
On Monday 28 Mar 2005 4:54 pm, John Payne wrote:
>
> This is _nothing_ to do with what you're running on the recursive
> nameserver. It is doing _exactly_ what it is supposed to do. Get
> answers, store in cache, respond to queries from cache if TTL isn't
> expired.
The answers from a recursive servers won't be marked authoritative (AA bit not
set), and so correct behaviour is to discard (BIND will log a lame server
message as well by default) these records.
If your recursive resolver doesn't discard these records, suggest you get one
that works ;)
I assumed the reason open recursive servers are a "bad idea" are that you can
guess to within a second when they will rerequest a record from the
authoritative servers, so you know when to try and send a spoofed answer for
a domain you are trying to poison. Thus it makes brute force poisoning
attacks less obvious because you don't have to send thousands of packets till
you hit the right time and client id, you just have to guess the right client
id, as you can guess the "right time" (for busy domains at least) by asking
when will this record expire.
I've never seen a malicious attack of this type in anger, but it is
theoretically possible (although much harder again DJB dnscache because it
opens a new port per request), and well documented as a vulnerability of the
DNS protocol.
For large ISPs I would have thought this was a legitimate concern, but being
able to poison one cache, at one small ISP, one time in so many thousand, is
a limited result for a lot of effort. Still if you have a "botnet" spare and
no spam runs to process I guess the effort is writing the software to try.
More information about the NANOG
mailing list