DNSCurve vs DNSSEC

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.