[conspire] Dnsmasq and pdnsd

[Rick Moen]

Eric, I'm forwarding this one, too, because similar comments apply to
dnsmasq.  (I notice that dnsmasq is getting patches for cache poisoning
risks, i.e., finally implemention UDP port randomisation -- so Moestl
and Rombouts's "pdnsd" differs from dnsmasq in having gotten that design
point correct, from the beginning.)

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Sat, 2 Aug 2008 01:16:05 -0700
From: Rick Moen <rick at linuxmafia.com>
To: ben at linuxgazette.net
Subject: pdnsd

I've double-checked what I speculated in our telephone call. It was
correct.

Short version:  pdnsd is A Good Thing for your situation (you're better
off with it than without it), even though it doesn't address the
Kaminsky-publicised security threat.

Long version:  Main site http://www.phys.uu.nl/~rombouts/pdnsd.html
clarifies that pdnsd is 

o  DNS cache sofware, with a disk-based cache,
o  that forwards any incoming queries that _cannot_ be answered from
   cache to one of a series of IPs of recursive-resolver nameservers
   elsewhere, that you specify by IP in /etc/pdnsd.conf ,
o  and that can also be configured to serve up a modest amount of 
   authoritative local DNS names used for local devices.

It's thus a real boon to small networks with slow connections to
elsewhere, especially demand connections such as dial-up, because of the
cache plus some "offline-detection" features, etc.  The cache alone will
help you get much more out of limited bandwidth.


With pdnsd deployed, your vulnerability to Kaminsky-style DNS-forging
attacks is determined by how good the nameserver(s) are to which pdnsd
is pointed.  Essentially, pdnsd neither helps nor hurts that aspect of
security profile; it is orthogonal to the issue.

Well, not entirely....

One of the attack scenarios that Kaminsky _may_ have in mind (we'll know
when he delivers his Black Hat talk on Wednesday) is where an attacker
seeds (say) Web pages with URLs citing his captive "evildomain.com".
When his Web server registers browser hits coming from your LAN, the
attacker's scripts injects into your LAN a sudden blitz of forged DNS
answers to DNS queries that the attacker can reasonably guess are being
asked by some host in your LAN.  The forged packets will include ones
with each of the 2^16 possible transaction ID (QID) numbers, in hopes
that one of them will be accepted and cached.

Fortunately, pdnsd has from the beginning followed DJB's advice and
originated its queries forwarded elsewhere from randomised source ports.
See:
http://groups.google.com/group/linux.debian.security/browse_thread/thread/a3adbc6a3549486f/c94f956308fbbbf1?hl=en&lnk=st&q=pdnsd+advisory#c94f956308fbbbf1



----- End forwarded message -----