DNS is only the beginning. The easy to understand, free crypto "framework" that underlies DNSCurve (~DNSCrypt) can be applied to any service: HTTP, SMTP, etc. That framework is not an OpenDNS creation. It was written by university professors and it's in the public domain.
DNS is simply the first service to try it out on. Maybe because DNS is rather important, since so many other services depend on it.
Users need to decide what is important to them.
A. Having cryptographically signed DNS information as a means to authenticate it.
B. Having protection against people sniffing or tampering with your traffic, e.g. your DNS requests, on the wire.
C. Or both.
A. The best way to avoid cache poisoning is to refrain from using someone else's cache. Using your own cache, accessible to you only, alleviates the need for DNSSEC as a means to combat cache poisoning.
B. But how many alternatives to the fast, strong crypto that underlies DNSCurve are there? Are they as fast for use in this way?
C. "Securing DNS" is an _ambiguous_ description. As such, it can mean at least two different things. Two of those things are addressed by DNSCurve and DNSSEC, respectively. From a functional perspective (i.e. in terms of what they do), they are not in competition with each other. They each address different things. But because we use the amibiguous idea of "securing DNS", the user has to decide what "securing DNS" means: A, B or both?
The IETF, DNSSEC hype and OpenDNS's deceptive business model are all red herrings.
Users simply need to decide what is important to them.
A. Are they concerned they're not getting the right IP addresses for the domain names they inquire about, because the source for DNS info they're using is not dependable? (e.g. it's a shared cache like OpenDNS and can be poisoned)
B. Or are they more concerned someone is sniffing and possibly tampering with their DNS traffic, in transit?