In message <alpine.BSF.2.00.0908051952480.3301@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.
R's, John
The DNSCurve concept is fine the implementation however is really poorly done. 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org