Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Can someone informed, please give a lengthy reply about the differences and advantages/disadvantages of both approaches?

I am not a DNS expert, not a programmer. I have a decent basic understanding of DNS, and enough knowledge to understand how things like the kaminsky bug work. From what I understand, DNSCurve has stronger encryption, is far simpler to setup, and an altogether better solution.

DNSSEC is needlessly complicated and uses breakable encryption, however it provides end to end security, something DNSCurve does not. However, many of the articles I have read have seemed to indicate that end to end security is of little use or makes no difference.

So which is true? Which is the better solution, or what are the disadvantages/advantages of each?


I would appreciate if someone could explain what is gained by encrypting the message contents, when the goal is authentication rather than confidentiality.

The proof that keys are 1024bit RSA keys is here.


locked by Chris S Jul 3 '12 at 13:44

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

"DNSSEC [...] uses breakable encryption" That's pure bullshit. Provide references or avoid relaying FUD. – bortzmeyer Jul 16 '09 at 11:58
So you don't think 1024 bit RSA keys will be breakable if the task is set over a distributed network? – Bill Gray Jul 17 '09 at 6:41
Here are some, hopefully not to biased slides explaining – Bill Gray Jul 17 '09 at 6:42
and a pertinent quote from Paul Vixie: 'dnscurve solves a problem i'm not having, and fails to address one that bites me in the ass every hour of every day. technically it looks like fine work, but it's still a 95% misfit for what i actually need from "dns security".'… – Alnitak Jul 21 '09 at 16:26
@bill - that 1024 bit setting in the ISC slides is an example. – Alnitak Aug 2 '09 at 8:26

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. 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.

+1 DNSSEC is a real alternative, DNSCurve is not... – Antoine Benkemoun Jul 15 '09 at 13:50
Interesting. One thing is that we don't need to meet a confidentiality requirement for DNS packets, only Authentication. DNSCurve seems to be the better alternative, objectively on technical grounds. The RSA keys DNSSEC uses would not take to long to break with a botnet – Bill Gray Jul 15 '09 at 20:26
@Bill Gray: you're welcome to try. Please provide a pointer to a report describing a successful brute-force attack against RSA and then read the size of the keys involved. – bortzmeyer Jul 16 '09 at 12:04
@bortzmeyer: 1024 bit RSA keys. Botnets. Think about it. – Bill Gray Jul 17 '09 at 6:40
actually, most people are planning to rotate keys regardless "just in case". And as soon as they do, the whole cracking process has to start from scratch again. – Alnitak Feb 25 '10 at 9:56

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.

Indeed, that's why DNScurve is not a competitor to DNSsec but to other channel security protocols like IPsec, TSIG, DNS cookies, etc. If you deploy DNScurve, you still have to deploy DNSsec afterwards, to get end-to-end security. – bortzmeyer Jul 16 '09 at 12:02

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.

the conduit already has protection (TSIG), albeit that provides verification and not confidentiality. – Alnitak Jul 27 '09 at 10:52
As far as I can tell, TSIG only secures updates to DNS, not queries. – kquinn Jul 27 '09 at 21:13
no, TSIG can also be used for queries, although admittedly that's not a common configuration. – Alnitak Aug 2 '09 at 20:00
up vote -9 down vote accepted

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


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.

I added a -1 too, because there are many mistakes such as "DNSSEC uses 1024bit RSA keys" or "much code has to be rewritten" or "The root servers won't sign the complete database" (the root is not signed so this sentence means you know the future of root signing better than its operators), etc. – bortzmeyer Jul 27 '09 at 12:32
Care to back up your statements? The infomrmation above is available everywhere online. DNSSEC does use 124bit RSA keys, why are you disputing this? Just because you were not aware of the information does not make it wrong. – Bill Gray Jul 29 '09 at 21:16
@bill - Your own analysis is completely flawed. DNSSEC can use any key length. No system can sign the "complete database" because by definition it's a distributed database. DNSCurve does not "sign the database", it just encrypts packets. – Alnitak Aug 2 '09 at 8:27
Downvote for answering yourself and accepting it when you didn't like any of the responses you got. – Mark Johnson Dec 21 '09 at 22:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.