DNSCurve vs DNSSEC

DNSCurve provides actual encryption to DNS packets, albeit only on a hop-by-hop basis, and specifically on the hop between the recursive server and the authoritative server.

When used on that path it can provide authentication of the zone data. However any client further downstream cannot benefit from this authentication because the security is only "hop-by-hop". A malicious resolver sat in the middle of the resolution path can still provide false data.

DNSSEC on the other hand provides an end-to-end verifiable cryptographic signature that proves that the data received is the same as that on the authoritative server. DNSSEC uses cryptographic techniques, but does not actually encrypt any DNS traffic.

DNSCurve's use of elliptic curve encryption algorithms permits much smaller keys to be used than with RSA to achieve the same level of cryptographic strength. However there are proposals to include similar algorithms in the list supposed by DNSSEC.

DNSSEC is standardised by the IETF (RFC 4034 and RFC 4035, updated by RFC 5155) and implemented in several very popular name server implementations, including BIND (of course) and NSD/Unbound. PowerDNS will have DNSSEC support very soon.

DNSSEC is admittedly complicated but efforts are ongoing to simplify this (see e.g. http://opendnssec.org/) and deployment is increasing all of the time. Various TLDs (.se, .br, .org, .gov, etc) are already signed with DNSSEC and it has been announced that the root zone will be DNSSEC signed by the end of the year.

DNSCurve is quite interesting, but due to the independent way in which it has been developed it has very little chance of seeing any significant deployment. IMHO it has zero chance of ever being deployed on the root servers.

BTW your assertion about DNSSEC using "breakable encryption" appears to be completely unfounded. On what basis do you say that?

Zone signing keys are usually (but not necessarily) 1024 bits long. These keys are typically rolled every month or so, and current best estimates are that it would take at least a couple of years to brute force a 1024 bit key.

At this point in time a brute-force attack against 1024-bit RSA would require about two years on a few million compute cores with many tens of gigabytes of memory per processor or mainboard

which isn't exactly your typical botnet. From the same paper:

Next considering special purpose hardware, the most optimistic approach suggests that sieving for a 1024-bit RSA modulus can be done in a year for about US $10,000,000, plus a one-time development cost of about US $20,000,000, and with a comparable time and cost for the matrix. In our opinion, (common) skepticism met by such designs is beside the point. Such figures should not be interpreted as upper bounds, i.e., “Be careful, 1024-bit RSA can be broken in two years for about twenty million bucks (assuming free development),” but as lower bounds, i.e., “No reason to worry too much: even under very favorable attack conditions, factoring a 1024-bit RSA modulus still requires enormous resources.” The estimates should thus not be read as threatening but as confidence-inspiring.

Or from a one year old PCPro article:

To put that into perspective, to crack an RSA 1,024-bit key Kaspersky estimates it would take something like 15 million computers running flat out for a year to succeed

Frankly, no-one's going to put that amount of effort into cracking one domain's ZSK!

Besides, the real security is in the key signing keys, and those are usually at least 2048 bits and often longer (4096 bits). The amount of time it takes to crack an RSA key rises exponentially with the key length, not linearly.

A comment on LWN claims

DNSCurve secures the conduit, not the message. It can't be used to protect against malicious caches, and isn't a functionnal equivalent to DNSSEC.

and links to a discussion in French.

Its important to understand "trust" rather than "encryption" is the key to security. You can have a "secure" conversation with someone using "encryption" but what good does it do you if the person on the other end is not who you think they are?

The major take-home difference between DNSSec and DNSCurve is that DNSSec signs everything, there is a clear trust-chain from the root all the way up to the host records provided by each operators DNS servers.

DNSCurve does NOT sign anything there is no trust chain at all. DNSCurve focus is narrowed to preventing passive or blind poising of DNS responses.

It boils down to practicality... There are huge operational challenges with DNSSec - how do you practically create a trust anchor the size of the planet? When the millions upon millions of domains are being signed what mechanisims are used to instill confidence that keying material necessary to forge any signature does not fall into the wrong hands or is not used improperly? Trust on a large scale is very difficult from an operational perspective to pull off and maintain.

DNSCurve does not even try.

Now having answered the basic question heres my take of what the problem to be solved actually is and which of the two technologies is a better fit.

The Internet is inherently as much a condiut of nonsense as it is of salient discussion and enlightenment. In my view a fully trust-worthy Internet isn't a reasonable or obtainable goal and if it were to become so there would likely be negative implications in terms of freedoms and anomyous speech and actions.

In my opinion all thats needed is a DNS solution which is at least as trustworthy as the underlying transport. It needs to practically prevent poisioning of DNS records by attackers who blindly inject false messages or passivly sniff requests and forge UDP responses. It does NOT need to gurantee security above and beyond that. This way the Internet continues to route packets and provide DNS services in a reliable but not necessarily secure manner.

DNSSec and its global trust anchors in my opinion is a fools errand which focuses almost entirely on solving a problem that does not exist. (All end-end encryption systems that can be used over the Internet already have their own methods for verifying identity)

DNSSec is slow, expensive and will significantly delay the clear and present issues with DNS that like moving to IPv6 should have been resolved yesterday.

What DNSCurve does is protect the network so that the naming service is at least as reliable as the underlying transport of packets over the network but not more so. In my view it solves the exact problem that is actually being faced in the real world. DNSCurve prevents passive MITM but it does not practically protect against active MITM without ssh style "leap-of-faith" signature caching.

To play the devils advocate large scale deployment of DNSSec can potentially have positive implications. The PKI infustructure can replace the SSL secure server CAs and provide some trust binding for IPSec and other encrypted conversations between peers.

Honestly? Neither one is good enough. DNSSEC collapses under its own weight: it's overly complicated, full of holes, and will probably never work properly. DNSCurve is good at what it does, but doesn't go nearly far enough. It's easier to patch into a DNS server, but due to the way in which it was written and is being promoted, will probably never see widespread use.

I would rather deploy DNSCurve than DNSSEC on my own (recursive) DNS server, but only because DNSCurve is more explicit about what it can and can not do, and does not provide a false sense of security the way DNSSEC can -- a lot of smart people think DNSSEC is good enough, and it is not.

My hunch is that there's more yet to come in the DNS security wars, and we'll probably see a third option emerge. Hopefully it'll be built on DNSCurve, since I think DNSCurve is extremely well-designed for securing the conduit in a backwards-compatible manner.

I have arrived at a conclusion, that DNSCurve is a better option.

Because:

DNSSEC uses 1024bit RSA keys for signing, which were already considered unbreakable in 2003 by large netowrks, botnets. The case is still true today.

To be correctly implemented much code has to be rewritten.

The root servers won't sign the complete database, not offering full protection.

Replay attacks up to 30 days after a domain expires are possible.

In order to achieve security it is necessary to expose all domain names.

DNSCurve does not have these problems, and allows for authentication, availability and confidentiality(as in not having to expose names) in a way DNSSEC does not. Additionally, it requires no code modifications, just additional software.

It also has protection against forged packets, which DNSSEC does not, as well as protection against replay attacks, due to the use of nonces. DNSCurve may be subject to a MITM attack that DNSSec is not, but it is my understanding that if DNSCurve was implemented all the way to the root, this would not be the case.