[dns-operations] OpenDNS adopts DNSCurve

Crist Clark Crist.Clark at globalstar.com
Wed Feb 24 21:39:38 UTC 2010


>>> On 2/24/2010 at 11:52 AM, Matthew Dempsky <matthew at dempsky.org> wrote:
> On Wed, Feb 24, 2010 at 11:38 AM, Paul Vixie <vixie at isc.org> wrote:
>> the trust anchor plan for DNSSEC is, sign the root, everybody configures
>> a trusted key for the root, and RFC 5011 keeps it rolling thereafter.  we
>> are only using DLV during initial startup while there are still islands.
>>
>> what's the corresponding plan for DNSCurve?
> 
> The same general plan works for DNSCurve.
> 
> An authoritative server can today setup DNSCurve, and benefit from the
> "optimistically trust the first response" mechanism, and already have
> better security than DNS currently provides.  If the parent server
> later adds DNSCurve support, resolvers will automatically use the
> "secured lookup to a parent server" mechanism.  (Of course, the parent
> then has to similarly worry.)
> 
> Orthogonal to that, there's no concrete plan yet for automating trust
> anchors yet, and ideas are welcome.
> 
> The root zone file is available with PGP signatures, so if a TLD were
> to support DNSCurve, recursive servers could extract the appropriate
> NS records from the root zone file to setup as a trust anchor.
> 
> Also, some TLD zone files (in particular, .com and .net) are also
> available for download with PGP signatures, and a trusted party with
> access to them could republish just the zones with NS records
> indicating DNSCurve support.

This argument is going to go nowhere. There is no point in pretending
that DNSCurve is in anyway a substitute or competitor to DNSSEC.

As the DNSCurve IETF draft says,

   DNSCurve only provides link-level security between a client-server
   pair.  It does not attempt to ensure end-to-end security for queries
   and responses relayed by untrusted DNS proxies and caches.

Whereas end-to-end security is the purpose of DNSSEC. In DNSSEC, anyone
can verify the authenticity of a RR from its source. In DNSCurve,
you know the response was actually from the server you queried, and
it's just "trust me" for all of the magic behind that recursive 
resolver.

DNSCurve, to me, seems roughly equivalent to a client doing IPsec AH on
53/udp and 53/tcp with the server.




More information about the dns-operations mailing list