dnscurve and DNS hardening, was Re: Dan Kaminsky
marka at isc.org
Wed Aug 5 20:43:12 CDT 2009
In message <alpine.BSF.2.00.0908051952480.3301 at simone.lan>, "John R. Levine" writes:
> >>> http://dnscurve.org/crypto.html, which is always brought up, but
> >>> never seems to solve the problems mentioned.
> > As I understand it, dnscurve protects transmissions, not objects.
> > That's not the way DNS operates today, what with N levels of cache. It
> > may or may not be better, but it's a much bigger delta to today's
> > systems and practices than DNSSEC is.
> I took a closer look, and I have to say he did a really good job of
> integrating dnscurve into the way DNS works. Each request and response is
> protected by PKI, sort of like per message TLS. The public key for a
> server is encoded into the server's name, and the one for a client is
> passed in the packet. The name server name trick gives much of the zone
> chaining you get from DNSSEC.
> He doesn't say anything explicit about chained caches, but it seems pretty
> clear that you's have to tell the client cache about the server cache's
> key at the same time you tell it the server cache's IP address.
> It seems to me that the situation is no worse than DNSSEC, since in both
> cases the software at each hop needs to be aware of the security stuff, or
> you fall back to plain unsigned DNS.
The DNSCurve concept is fine the implementation however is really
It also only works well for iterative resolvers. It doesn't work
well for stub resolvers, nameservers that forward etc. as one now
has a key distribution problem.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the NANOG