I thought the problem with CAs was that any compromised CA breaks security on all sites? Whereas with DNS there's one registrar that handles your domain (well, plus the tld admin, but that's still only 2 instead of lots), which is chosen by you rather than any attacker?
The better technology to look into if you're concerned about individual user rights and privacy is DNSCurve: http://dnscurve.org
After re-reading that, I still don't see how it authenticates the DNS server (and if it does, I imagine it could only do so by relying on information from the parent zone). So I'll assume that it's no more resistant to "registrar hack[s] or state level strong-arming" than anything else.
DNSCurve doesn't authenticate DNS data. It authenticates the connection between the client and the server. It does that because authenticating the data requires boiling the ocean by getting a huge portion of the Internet to agree on and implement a scheme to authenticate data, and authenticating individual connections works even if you and your server are the only people who agree to do it. DNSCurve solves a less ambitious problem than DNSSEC does, but that problem is (a) the most important problem in DNS security and (b) actually solvable, unlike the DNSSEC problem.
Moxie gave an absolutely fantastic talk at Blackhat a few years ago in which he explained problem as it relates to SSL and a proposed solution: http://www.youtube.com/watch?v=Z7Wl2FW2TcA
http://media.ccc.de/browse/congress/2010/27c3-4295-en-high_s...
This was djbs introduction to CurveCP, a project to replace TCP with an encrypted, authenticated, end-to-end solution that always gives you PFS. Unfortunately the Nacl code base (containing the CurveCP reference implementation) hasn't seen any community love that I know of, so the project seems to be kind of stillborn... although ZeroMQ recycled some of the ideas and cryptography in CurveZMQ
I'm not bashing nacl, I've just not heard of anyone using it over GnuTLS, OpenSSL, CryptoPP or others.
Edit: libsodium apparently. Awesome.
I think it's fair to say that CurveCP isn't production ready despite being "developer proof" since 2011.
What I mean to say about the project being "stillborn" is that it hasn't progressed to something like an IETF RFC or gained any real traction as an alternative to TLS. It's a real shame because a cryptographically secure session layer and long-overdue rework of TCP are things we really need. Projects like Mosh (SSH alternative) have already demonstrated how mobility can be improved with good crypto at the session layer, rather than above it.
Going back to ZeroMQ... it's one of the most "developer proof" libraries out there for messaging, yet they decided to implement the half they felt they could get away with. They could have opted for a "curvecp://<key>" URI scheme for bind() and connect(), defaulted to UDP under the hood, and perhaps gained endpoint mobility, but it didn't happen. Pragmatic perhaps, but if there was anyone who could have pushed CurveCP further it would have been those guys.
I don't see the complexity and mess of TLS going away anytime soon... and I expect most people implementing TLS in C or C++ to be using GnuTLS, OpenSSL or perhaps Mozilla NSS for the foreseeable future.
If you're talking about Nacl, though, from everything I can tell Nacl is very successful and seems to have a pretty bright future. Certainly, I'd recommend Nacl over any other crypto library you might use to build a new system with.
https://twitter.com/bascule/status/383364389576773632
https://twitter.com/jedisct1/status/381136544515375104
Lord knows if anyone is actually working on a protocol that fixes the issues mentioned.
That said, I understand how the network works up my DNS server. I don't know what happens after that so I can't really argue on how to build a better system but namecoin[1] seems the obvious solution.
DNSSEC doesn't do encryption. This is why DNSSEC isn't censorship-resistant.
If you want encrypted DNS, that's what DNSCurve does.
I get about 1-2% of my requests via DNSCurve, almost entirely from OpenDNS, which started supporting it years ago: http://blog.opendns.com/2010/02/23/opendns-dnscurve/
The problem is mainly in the tooling - there aren't good query and diagnostic tools out there for DNSCurve, beyond fairly complicated CLI incantations.
All of these crypto projects (Nacl, CurveDNS) would benefit from moving to Github. Nobody's going to use a seemingly stagnant project. That's ultimately the problem with most of djbs best work, and a lot of other good work, I think. He does world class research and reference implementation, but it doesn't feel like there's an open source community rallying around it.
We need more Linus' in the crypto world.
If you think users are confused by SSL warnings now, how the heck would they understand similar errors at the DNS resolver level?
Also, there's no-in flight encryption, so it offers no privacy benefit. It also aggravates DNS amplification attacks.
The better technology to look into if you're concerned about individual user rights and privacy is DNSCurve: http://dnscurve.org
It's not comparable to DNSSEC other than "It uses crypto with DNS" - they have entirely different goals, but the goals it solves are much more relevant to end users (privacy, forgery, etc.).
Personally, I'd recommend people run both techs, as there's no technical reason that makes them incompatible.
I have no idea how to solve the UI problems. We've had 15+ years of SSL and there's been almost no progress on that.