DNSSEC surpasses 50% of root domains | Hacker News Reader

DNSSEC surpasses 50% of root domains

blog.icann.org

36 pointsseky50 comments

No, 50 of the root domains now support DNSSEC. Nothing resembling 50%, 5%, or .5% of the Internet uses DNSSEC. Nor will it ever.

DNSSEC is a bad idea. It provides very little value. It drastically complicates the Internet. It bakes the worst part of TLS --- the static tree PKI --- into the core design of the Internet... and then gives the root of the tree to the US government. It's clunky, it uses antiquated crypto (its proponents have been trying to standardize it since 1995), and it leaks your private hostnames to the Internet.

I can go on and on and on. Instead, here's some older posts I've written about it:

https://news.ycombinator.com/item?id=5571937

https://news.ycombinator.com/item?id=4071178

https://news.ycombinator.com/item?id=2932378

So DNSCurve then? Does it basically just allow me to encrypt my connection to a DNS server of my choice? If I run my own DNS server on my own network, and I resolve example.com will I know if the entire recursive resolution was done over a secure channel or just that the connection from my host to my DNS server was secure?

Also is there any chance of it actually becoming adopted widely?

How about "nothing"? There's a movement inside the IETF not to standardize any new protocols that transmit data in cleartext. TLS has already successfully demonstrated that you can run critically important protocols without trusting the DNS.

Interesting. I have been thinking about this in terms of SSH more so than HTTPS. So I own a domain, and I want to be able to set up a bunch of hosts in that domain for access by a bunch of users. I don't want to keep trying to distribute server key fingerprints all the time, much less trying to keep them up to date. Two solutions I found that would actually solve this problem:

a. Use a DNS TXT record to store the fingerprint [1]. This is all great except unless I can be sure that the DNS response is authentic, I cannot trust the TXT record. In fact this is worse than just keeping my own known_hosts as now I don't even get a warning when someone is actively MITM'ing me.

b. Use Monkeysphere [2] and get everyone to do the same. The problem with this is that support for this requires the users to know what they are doing. It also requires everyone to securely exchange GPG keys (don't even get me started on exchanging keys. Working remotely is a nightmare for this).

I think if this can be solved for a decentralized system like SSH where you control everything about the key (generation, expiration, revocation, etc.) It can be solved for the web as well, but I have not found a solution that's less of a PITA than the status quo.

[1] http://tools.ietf.org/html/rfc4255

[2] http://web.monkeysphere.info/

On the other hand, you're more vulnerable to DOS attacks during the handshake. Not replacing DNS, why not. But then, we may want to replace TLS.

http://curvecp.org/ maybe?

TLS has demonstrated no such thing. Right now, you can still subvert most TLS deployments by subverting the DNS, because everyone trusts CAs who provide signatures that rely on unauthenticated MX record lookups followed by cleartext SMTP connections.

DNSCurve is a reasonable replacement for TSIG, and I'm all for deploying it on that basis, but it doesn't make sense to give up on signed records. Signed records are at least non-repudiable, which provides some disincentive against forging them at a higher level in the tree. The DNSCurve proposal is to basically just hand over your private keys to a bunch of machines that are probably owned and operated by third parties, in an environment where they can forge arbitrary records at will without any accountability.

Sure, there are problems with the DNS being a hierarchical protocol, but we still need authenticated DNS and we need it yesterday. DNSSEC isn't a great solution and we certainly can't stop at DNSSEC, but that doesn't mean we're better off without it. Unless you know something that I don't about the relevant politics, the alternative to DNSSEC is probably to wait another 10+ years for something else to gain traction, and I don't think we can afford to wait that long.

We are in fact better off without DNSSEC:

* DNSSEC bakes a hierarchical PKI controlled at the roots by world governments into the core of Internet connectivity, in a way that can't be policy-controlled by users.

* DNSSEC has a poorly-thought-out interaction with Internet security and security policy; when TLS validation fails, users get a click-through that allows them to proceed to the site anyways. No similar state machine is built into the overwhelming majority of programs that do DNS lookups. As a result, if anything goes wrong with your DNSSEC configuration, you will more or less vanish from the Internet. "gethostbyname()" doesn't include a popup dialog feature.

* Mainstream deployments of DNSSEC are based on 1990s crypto, including PKCS#1v1.5 RSA padding; at exactly the moment when the rest of the Internet is transitioning away from crappy old RSA protocols, DNSSEC doubles down on it.

* DNSSEC leaks internal hostnames to the Internet because the designers of the protocols prioritized authenticated denials (availability) over confidentiality. NSEC3 is a great illustration of how slapdash the protocol design is: in an attempt to plug that leak, the IETF standardized what is in effect a password hash (and a bad one) to help obscure internal hostnames. When challenged on why the Internet should adopt a 1990s password hash as an Internet core protocol security mechanism, DNSSEC proponents say, "well, well-managed domains make domain cuts carefully to solve this problem", as if any commercial network in the world actually does that.

* DNSSEC creates yet another huge amplifier for DDoS attacks, allowing trivially small requests to elicit gigantic responses from servers.

Now, two fun things to know about all these problems:

1. They are, unlike your citation of crappy CAs, baked in design flaws in the protocol. You can evict a CA that misbehaves or isn't careful about validation. The EFF or ACLU could run a program that would allow people to subscribe to a trusted subset of CAs. None of that is possible in DNSSEC, because DNSSEC's problems aren't implementation or deployment problems, but rather fundamental attributes of the system.

* For all its flaws, DNSSEC doesn't actually protect queries from end systems to servers: it is a server-to-server system that leaves end-user DNS queries unprotected and spoofable.

I don't think this system is something we need "yesterday".

I have a lot of random opinions and thoughts about things, including security things, that I come to because discussions in places like HN prompt me to develop those opinions. DNSSEC is not one of those things. I've been following DNSSEC standardization since... well, since DNSSEC was an effort of TIS Labs, which was owned by my employer, where I was building DNS security testing tools. I've particularly followed namedroppers since the early 00's, when the list drove Daniel Bernstein away from DNS standardization.

DNSSEC basically has all the problems of SSL registrars with almost no user-facing of the benefits - it's still a centralized system that could be overridden by a registrar hack or state level strong-arming, and very few end user systems support actually doing anything when DNSSEC signed records don't verify.

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.

More on this topic can be found in this talk by djb.

https://www.youtube.com/watch?v=K8EGA834Nok

Original video, complete with download links:

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

Most 3rd parties are building on libsodium, not the Nacl code:

https://github.com/jedisct1/libsodium

libsodium is the nacl code; it's just been forked to make it easier to compile on different platforms.

Nacl is the most widely used and supported high-level crypto library in the world. "Stillborn"? Nonsense.

Wouldn't that be OpenSSL? I can't find a single package in the Debian repos that depends on nacl. Do you have any examples?

I'm not bashing nacl, I've just not heard of anyone using it over GnuTLS, OpenSSL, CryptoPP or others.

Edit: libsodium apparently. Awesome.

GnuTLS, OpenSSL, and CryptoPP are low-level libraries that for the most part provide only primitives and protocol compatibility. Keyczar, Nacl, and cryptlib are high-level libraries that provide secure constructions designed to be "developer-proof". The vast majority of people who try to build new cryptosystems using OpenSSL fail, because combining low-level crypto primitives to try to build a cryptosystem is very difficult and requires domain knowledge that people don't realize they lack.

The CurveCP implementation in libchloride doesn't claim to be embeddable, and I wouldn't personally use libcurvecpr where it mattered because it's yet well eye-balled. The author, Noah Fontes, with utmost kudos and respect to him, seems to be working on it alone and admits that he lacks that domain knowledge ("I don't claim to be a security or cryptography expert in any senses of the terms").

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 are talking about CurveCP, I don't have strong opinions. In fact, there are issues with CurveCP; CodesInChaos posted a critique of the CurveCP key exchange awhile back. Trevor Perrin pointed out at Baysec a few months back that key exchanges are particularly hard to get right, using CurveCP as an example. CurveCP may very well be DOA. I don't know.

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.

Yeah, here's a couple of good twitter threads that sum up some of the issues with CurveCP (and perhaps ZeroMQ)

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.

This is a really important point and isn't stated enough. People think of DNSSEC as some panacea that "fixes" DNS, but it really does nothing of the sort.

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

Good comment, I use them both with OpenNIC DNS servers which accept both DNSSEC and DNScrypt (based on DNSCurve) encryption.

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.

[1] https://www.namecoin.org/

DNS servers which accept both DNSSEC and DNScrypt (based on DNSCurve) encryption.

DNSSEC doesn't do encryption. This is why DNSSEC isn't censorship-resistant.

If you want encrypted DNS, that's what DNSCurve does.

DNSCurve hasn't seen any implementation love. Seems to be a dormant project since ~2011.

I've been running CurveDNS (http://curvedns.on2it.net) for the last few years for a few externally facing sites.

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.

It'd be pretty nice if the last blog post was more recent than 3 years. It's also really nice to know that curvedns-0.87 has been downloaded 1050 times... but i have no idea when it was actually released. No sign of a changelog... No public repository? No mailing list?

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.

For the last 15 years people have said that about everything Daniel Bernstein wrote. Meanwhile, people deploy the stuff, use it, don't have security holes, get better performance, and generally don't have to think about it every week... see if you can say that about BIND.

Occasionally, mostly DJB, programmers write code and it is DONE. This is such an astonishing accomplishment that when it happens, it is mistakenly branded for not being "active".

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.

Plus, your DNS provider doesn't have a business incentive to prevent you from bootstrapping other systems off DNS. So it happily could put eg per host IPSEC keys, or SSH host keys in strongly authenticated DNS records.

That one registrar is chartered and controlled by a government; for much of the Internet, that government is the United States, which already has a system in place for seizing control of domain names. I'm baffled that people could be sanguine about also giving them control of encryption certificates.

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.

Can one of you knowledgable HNers tell me how I, as a dude who owns some domains and occasionally uses DNS to point them somewhere can get on board with this? Or is something that can only be implemented if you're hosting your own DNS?

Your zones need to be either online-signed by the authoritative DNS servers for these zones or offline-signed (using e.g. OpenDNSSEC) and then pushed to the authoritative DNS servers. Offline-signing is obviously more secure but signatures need to be refreshed regularly, so it's not sufficient to sign the zone once and be done with it. The zone needs to be resigned and pushed out to the authoritative DNS servers continually. If that process fails somehow, the signatures will expire and your zones will no longer validate. It's like a self-inflicted DoS. Setting this up properly is a nightmare.

The ISP you're hosting your domains at needs to support this.

Similarly, is there a list of the TLDs that do support DNSSEC ?

This is the right question. ICANN likes to put out these happy press releases, but they don't give us the details. It's necessary to name and shame the TLDs that are behind the curve.

ICANN publishes the TLD DNSSEC Report : http://stats.research.icann.org/dns/tld_report/

For ccTLDs only, there is this list : http://www.statdns.com/cctlds/

Your domain registrar needs to support it, as they need to push your keys upstream. I currently use Gandi, who do support DNSSEC in their web interface. I think Namecheap support it but you have to email them to get it setup.

You need to run your own DNS server (this is really the whole point of DNSSEC!), and setting it up is an absolute dog atm.

Setting up is actually fairly easy using bind and the right tools if you are familiar with DNS configuration. On debian/ubuntu there's a package for it ( dnssec-tools ). Here's a simple tutorial: http://www.howtoforge.com/configuring-dnssec-on-bind9-9.7.3-...

If you were my client and asked me this, I would probably suggest you wait. My personal guess is that any effort you sink to deploying DNSSEC is going to be wasted, not in the sense that "DNSSEC will have bugs" (though it will), but in the sense of "the world is not going to end up using DNSSEC".

In the immediacy, you should know that deploying DNSSEC isn't going to do anything for the security of your site, nor is it going to make it more reliable for computers around the world to reach your site.

It used to be possible to get HTTPS on Chrome, without warning, without getting certificates from CA, by using DNSSEC. Nobody used it so it was removed.

https://www.imperialviolet.org/2011/06/16/dnssecchrome.html

Wow, I didn't know about it! That's a shame it was removed - I couldn't find a site to test it or the issue in Chromium tracker about removing it though.

More information: https://code.google.com/p/chromium/issues/detail?id=50874

And in Mozilla Wiki: https://wiki.mozilla.org/Security/DNSSEC-TLS-details

Very strange, because this feature was removed from Chrome just after DANE RFC was published and all work is done. It is evident that DANE will kill SSL certification business. The development suspension may result from pressure coming from CA's.

It will "kill" the certification business by vesting that authority with governments: the USG controls the root of .com, and Libya(!) controls .ly. If DANE had been successful a few years ago, Ghaddafi's government would have controlled bit.ly's certs.

This is a feature! You can see from the domain name who you're trusting. Wouldn't it be great if TLS let you know in a similarly obvious manner when your CA is the USG?

No it's not! Your browser has a UI for changing which CAs you trust. Someone took actual time design buttons and dialogs for it. It's a crappy UI and nobody uses it, but it's clear that you do not need to trust the same set of CAs as everyone else to use the Internet.

That is not at all true of DNSSEC. The DNSSEC roots are fixed. If you're not trusting the same roots as everyone else, you're not really even on the same Internet anymore.

As you well know, browsers come configured with an endless list of CAs that "the user trusts", including CAs from various nebulous governmental entities from all over the world. And they are all good for authenticating any .com domain.

The UI you speak of is almost never invoked, unlike with the DNSSEC model where the address itself conveys information to the user in a form that even many non-technical users are accustomed to interpreting.

You've totally missed the point. As I acknowledged in the comment you just replied to, nobody uses the crappy certificate UI in browsers. The fact that the UI exists means it is possible to change your certificate list.

It is not possible to have users configure different DNS roots. DNS is part of Internet connectivity.

Does anybody know if it is the browser or the operating system that checks the validity of the dns records? Is it enabled on all clients?

You can track the progress of DNSSEC validation in Debian at https://wiki.debian.org/DNSSEC

No, but Google's public resolvers¹ support it and it's very easy to set up your own local validating resolver like Unbound².

¹ https://developers.google.com/speed/public-dns/docs/using#se...

² https://unbound.net/

At some point can they mandate DNSSEC?

They've mandated DNSSEC for new gTLDs, and the uptick is usage is almost entirely down to that. 100 or so have been delegated so far, and there are hundreds more in the pipeline. To some extent the 50% stat is meaningless as there's about to be a ton of gTLDs with tiny amounts of traffic relative to .com etc.

More DNSSEC uptake is still good news though.

Prior to opening the floodgates, DNSSEC was at 35% and climbing slowly: https://www.dns-oarc.net/oarc/data/zfr/root/ds

Reply on news.ycombinator.com