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.
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:
DNSSEC only attempts to provide security, without even any attempts at providing any privacy.
DNSCurve provides both security and privacy.
At the point of a recursive DNS resolver (e.g. Comcast and OpenDNS in your question), the question comes down to whether at least one of these technologies is deployed by the authoritative nameservers of the domain names for which the resolutions are made, and by the whole recursive path needed for the resolution. This point ensures that Comcast/OpenDNS servers themselves would be getting legitimate resolutions from elsewhere in the internet.
However, before their servers could get around to do any resolutions on your behalf, you have to send them your request.
If you don’t yourself use any software that is savvy in DNSSEC or DNSCurve, then all bets are off.
With DNSCurve and the DNSCrypt client from OpenDNS, all your queries are encrypted through DNSCurve, and only OpenDNS can see the actual content, and provide a valid reply.
With DNSSEC, you might also have to use something like a local_unbound in FreeBSD. I’m not entirely sure how it works yet — it has only been imported a couple of weeks ago, and documentation is somewhat lacking, but I think it supports forwarding traffic to other recursive servers like the one of Comcast (with forward-addr keyword), where it would supposedly also ensure that DNSSEC validation is taking place.
As such, your question is not specific enough to know your objective; however, it would seem like you’re using OpenDNS for a reason, and simply changing your nameserver back to Comcast would not offer any benefits in regards to security.
However, if you’re already using OpenDNS, then you should most certainly consider embracing their DNSCrypt client.