26

Looking at all the people who question the viability of DNSSEC, it's no wonder that the adoption rates are so poor.

However, what about DNSCurve? It supposedly fixes all the DNS security and privacy problems independent of DNSSEC, doesn't suffer from the problems that are specific and unique to DNSSEC, and, should one disregard the maturity of either approach, seems to be a clear win for the situation — yet even though it's much-much younger than DNSSEC, there are still practically no implementations for DNSCurve, other than djbdns and DNSCrypt support by OpenDNS. Why?

Improve this question
15
  • 3
    Also, that link that "explains" how DNSCurve solves all the problems DNSSEC suffers from? A list of papers by djb written in what certainly sounds like his trademark "my way is obviously superior and everyone who does things different from me is either stupid or letting their ego get in the way of common sense - unlike me, of course; I don't have an ego, I'm just that good. And if you don't like it, screw you" style that's probably done more to retard adoption of his various contributions than relative merits.
    – Shadur
    Nov 20, 2013 at 12:06
  • 6
    Technical merits aside, the answer can be boiled down to "Paul Vixie introduced DNSSEC, and Dan Bernstein introduced DNSCurve."
    – gowenfawr
    Nov 20, 2013 at 12:22
  • 4
    Yes, we need to develop one universal standard
    – jackweirdy
    Nov 20, 2013 at 12:54
  • 5
    DNSSEC was designed by the DNS people to do security in a way that is compatible with all of DNS's goals. DNSCurve was designed smart researcher with a strong personality to do security in a way that makes more sense to security people, and less sense to DNS people.
    – tylerl
    Nov 20, 2013 at 18:21
  • 1
    @Pacerier Each has its purpose. One guarantees the integrity of the conversation, and the other guarantees the correctness of the data. It's like how, TLS guarantees that your connection to Gmail is secure, but it doesn't guarantee that the email you read there is truthful. DNSSEC can guarantee truthfulness, but thats about it. Ultimately I think DNSSec is more urgent because it could readily replace our horribly broken TLS PKI, while nearly the entire benefit of DNSCurve can be achieved with a VPN to your DNS server.
    – tylerl
    May 23, 2015 at 3:16

2 Answers 2

Reset to default
51

There's a problem:

DNSCurve is more like TLS for DNS servers, in comparison to DNSSEC, which is signed records. DNSCurve uses point-to-point cryptography to secure communication, while DNSSEC uses pre-calculated signatures to ensure the accuracy of the supplied records.

So we can summaraize it like this:
DNSSEC: Accurate Results
DNSCurve: Encrypted Traffic

Theoretically you can use traffic encryption to ensure accuracy, the way TLS does for websites. Except that it's not really the encryption that's ensuring your accuracy, is the authentication provided through the PKI. And there's a set of critical problems with the basic DNSCurve PKI.

The first problem here is that with DNSCurve, each and every DNS server involved needs a private key, and since the key signature is encoded into the resolver's address, then in the case of anycast DNS servers, each server needs the same private key. But even if they use different keys, you're still trusting the local security where the DNS Server is installed. If the server is installed somewhere hostile, then the results can be compromised. This is not true with DNSSEC.

ICANN has stated that, in the case of the DNS Root zone servers, DNSCurve will not be implemented, ever. Many of the root servers operate in less-trusted locations, and the potential for abuse by local governments would be enormous. This is precisely why DNSSEC was designed such that signing happens outside the DNS server. DNS relies on a vast network of server which may not be individually trustworthy, so DNSSEC was designed such that the trust is based solely on the information they serve, not the honesty of the operator.

The second problem is that DNSCurve secures the public key by encoding it into the resolver name. But DNSSEC does not sign the resolver name. This means that DNSSEC (which is implemented in the root zone) cannot be used as a trust root for DNSCurve, because the one thing that DNSCurve requires to be accurate is in fact the very thing for which DNSSEC cannot ensure accuracy.

So essentially DNSCurve is pretty much a non-starter. While it can be used to guarantee the security of your communication with a single DNS resolver, there currently is no way of globally anchoring your trust in a way that could guarantee the accuracy of any results you retrieve.

Unless DNSCurve is re-designed to allow for trusted key distribution, it will have to remain a client-side security tool rather than a tool for ensuring the authenticity of DNS records.

Since DNSCurve is relatively new and was developed largely by djb in isolation, presumably these show-stopping issues were simple oversights on his part, and may be fixed at some future date. Though given Dr. Bernstein's track record of maintaining his inventions, I wouldn't hold my breath.

Improve this answer
14
  • 8
    djb also suffers from a severe "my way or the high way, and if you've got a problem with that, screw you" attitude which tends to severely slow the adoption of any of his works, regardless of their merit.
    – Shadur
    Nov 20, 2013 at 12:03
  • 3
    @Shadur: While that is true (and on top of that, DJB suffers from a seriously-unmaintainable-unreadable-code problem and some other problems) it is undeniable that DJB's stuff works, and works amazingly well. I've rarely seen software which is so much rubbish at first sight and so much ingenous at second sight as his stuff. Which distinguishes him from 1 million lamers who have the same attitude but don't produce stunning stuff.
    – Damon
    Apr 14, 2014 at 14:07
  • @damon Unfortunately at this point the vast majority of the people who've had to deal with him have pretty much decided that it doesn't matter how good his software is if the price for using it is dealing with DJB. And perhaps that's for the best -- if his code's that unmaintainable for anyone who isn't him, what'll happen when he stops maintaining it?
    – Shadur
    Apr 14, 2014 at 14:10
  • @tylerl, So how is OpenDNS affiliated to djb?
    – Pacerier
    Feb 16, 2015 at 19:31
  • @Pacerier they use a protocol he designed. Their focus and value proposition is also very different from the people who run the root zones.
    – tylerl
    Feb 16, 2015 at 19:40
10

The major reason is that DNSSEC was already being adopted by the major root servers when DNSCurve came out. Furthermore they do not tackle the same problems, they overlap on some points but differ on others. They could very well be used together.

Note that we have had a question DNSSec (Comcast) vs DNSCurve (OpenDNS) which details the differences very well:

First of all, DNSSEC does NOT sign your queries. Rather DNSSEC allows a zone (such as a domain) to be signed by its owner, and allows a resolver (for instance, Comcast's DNS servers) to verify the signature, and therefore be sure that the zone data it gets is authentic. It protects the resolver from receiving bad data, but does nothing to prevent MITM or snooping between you and the resolver.

DNSCurve on the other hand encrypts communications between recursive resolvers and authoritative servers and allows authoritative servers to sign their data against forgery, but does nothing to protect an end-user client from a bad recursive resolver. OpenDNS's DNSCrypt solution is based on the same technology as DNSCurve, but protects the last-mile between a trusted 3rd party recursive resolver like OpenDNS and the end-client.

As for which is more secure, neither is. They are both secure, however the security is applied in different areas. In either case you are picking which aspect of DNS security is more important, rather than which security tool is stronger.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .