BIND recursive resolver exploit?

[Rick Moen]

Quoting Robert Hajime Lanning (lanning at lanning.cc):

> From what I have been reading, the issue is that the nounce (query ID)
> is just 16 bits.

...and about half the resursive-resolver nameserver software in common
use, and all (?) common "stub" resolver libraries, originate
recursive-resolver queries from a fixed, predictable source port,
usually 53, with the result that the information required to believably
forge a reply to the query approximates 16 bits of variability, which
isn't enough.

_However_, OS "stub" resolver libraries are not a credible target for
this particular threat, because they don't cache results.[1]
Consequently, there's no cache to poison, and attacks don't pay off
well.

The obvious way to protect resolver libraries against even that much of
a threat is to have /etc/resolv.conf point to a _local_
recursive-resolver nameserver via 127.0.0.1, and ensure that the
nameserver software package is one that randomises _its_ source ports
for recursive-resolver queries:  BIND9's July 8th "P1" patches, djb's
dnscache, PowerDNS Recursor, MaraDNS, or Unbound.  Maybe Posadis, Oak
DNS Server, Twisted Names, Yaku-NS, lbdns, dnsjava. (Avoid pre-P1 BIND9,
any BIND8, unpatched pdnsd, unpatched dnsmasq.)

And of course border filtering against spoofed traffic is good, and 
ACLs on the recursive-resolver limiting what IPs are allowed to send it
recursive queries couldn't hurt (but aren't a cure-all for the reasons
David cited).

Bestiary:
"DNS Servers" on http://linuxmafia.com/kb/Network_Other/


[1] Absent things like nscd, both the Linux and Solaris implementations
of which have somewhat regrettable reputations, and should ideally not be
used to cache hostnames in the first place.  (I'm not sure about
FreeBSD's "cached", which occupies a similar niche.)