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