[dns-operations] Kaminsky: Protect IP Act Would Break DNS

[Mark Andrews]

In message <B32BF6CF-77E1-498C-BC11-6A2F16CD0E56 at NLnetLabs.nl>, Olaf Kolkman wr
ites:
> 
> On Jul 17, 2011, at 2:08 PM, Joe Greco wrote:
> 
> >> [Authoritative DNS servers operator hat on.]
> >> 
> >> On Sat, Jul 16, 2011 at 07:29:24AM -0500,
> >> Joe Greco <jgreco at ns.sol.net> wrote 
> >> a message of 74 lines which said:
> >> 
> >>> Also, in the past decade, what was once considered a heavy duty
> >>> server is now available in the form factor of my cell phone.  The
> >>> resources to do resolution locally exist.
> >> 
> >> The hardware resources. For the software, there are still a few
> >> improvments to make. For instance, to have a local resolver on your
> >> Ubuntu box, you need to:
> >> 
> >> * install the server ('aptitude install unbound')
> >> * edit the DHCP config so ::1 is put before the DHCP-learned servers
> >> * work around the brokenness of middleboxes
> >> 
> >> The first two point are not a big deal for a dns-operations subscriber
> >> but still too complicated for the average user. 
> > 
> > That's probably not the most likely point at which to tackle the
> > issue, due to choices made years ago by Microsoft, etc.  Since your
> > average consumer doesn't use Ubuntu, you might as well discuss the
> > difficulty of setting up a local resolver on a Sun workstation.
> 
> 
> First a shameless plug:
> http://www.unbound.net/documentation/unbound-windows-manual-01.pdf
> 
> 
> > 
> > Let's talk real world.  
> 
> Note that the shameless plug was above that statement.
> 
> > Let's talk your next door neighbor's network.  That's a Windows XP box, a M
> ac, some wifi, and random other devices
> > on a DHCP network hanging off a D-Link router.  The obvious place for
> > this sort of thing to start out is at the D-Link router; it offers a
> > single point at which a resolver can be installed for this "site" with
> > minimal hassle, and a bonus that the configuration of the rest of the
> > network is automagic.
> > 
> 
> The CPE would be a good place, although I believe that in the end the DNSSEC 
> validation needs to be very close to the application. Preferably on the same 
> device.

DNSSEC validation needs to be in the recursive server *and* in the
application or else it is very easy to DoS the application (downstream
nameserver) by sending bogus RRSIGs.  There is no way of signaling
to the upstream cache "fetch a new response".

Applications including nameservers (when talking to forwarders)
shouldn't be sending queries with CD=1 unless the answers they get
SERVFAIL from the upstream.  This allow the caches to work by
filtering out the obviously bogus respones.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org