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