7 ms·

DNSSEC surpasses 50% of root domains

36 points by seky 13y ago

AndrewDucker 13y ago
At some point can they mandate DNSSEC?
- bazzargh 13y ago
  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 https://www.dns-oarc.net/oarc/data/zfr/root/ds
Jgrubb 13y ago
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?
- blumentopf 13y ago
  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.
- zimbatm 13y ago
  Similarly, is there a list of the TLDs that do support DNSSEC ?
  - fuqua 13y ago
    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.
  - fcambus 13y ago
    ICANN publishes the TLD DNSSEC Report : http://stats.research.icann.org/dns/tld_report/ http://stats.research.icann.org/dns/tld_report/ For ccTLDs only, there is this list : http://www.statdns.com/cctlds/ http://www.statdns.com/cctlds/
- nly 13y ago
  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.
  - slug 13y ago
    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-on-debian-squeeze-ubuntu-11.10 http://www.howtoforge.com/configuring-dnssec-on-bind9-9.7.3-...
- tptacek 13y ago
  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.
sanxiyn 13y ago
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 https://www.imperialviolet.org/2011/06/16/dnssecchrome.html
- ktt 13y ago
  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 https://code.google.com/p/chromium/issues/detail?id=50874 And in Mozilla Wiki: https://wiki.mozilla.org/Security/DNSSEC-TLS-details https://wiki.mozilla.org/Security/DNSSEC-TLS-details
- zhovner 13y ago
  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.
  - tptacek 13y ago
    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.
    - zurn 13y ago
      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?
      - tptacek 13y ago
        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.
zdw 13y ago
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 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.
- kingzero 13y ago
  More on this topic can be found in this talk by djb. https://www.youtube.com/watch?v=K8EGA834Nok https://www.youtube.com/watch?v=K8EGA834Nok
  - nly 13y ago
    Original video, complete with download links: http://media.ccc.de/browse/congress/2010/27c3-4295-en-high_speed_high_security_cryptography.html 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
    - zdw 13y ago
      Most 3rd parties are building on libsodium, not the Nacl code: https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium
oliao 13y ago
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?
- sanxiyn 13y ago
  You can track the progress of DNSSEC validation in Debian at https://wiki.debian.org/DNSSEC https://wiki.debian.org/DNSSEC
- spindritf 13y ago
  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#setup https://developers.google.com/speed/public-dns/docs/using#se... ² https://unbound.net/ https://unbound.net/
tptacek 13y ago
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=5571937 https://news.ycombinator.com/item?id=4071178 https://news.ycombinator.com/item?id=4071178 https://news.ycombinator.com/item?id=2932378 https://news.ycombinator.com/item?id=2932378
- IgorPartola 13y ago
  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?
  - tptacek 13y ago
    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.
    - IgorPartola 13y ago
      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 http://tools.ietf.org/html/rfc4255 [2] http://web.monkeysphere.info/ http://web.monkeysphere.info/

36 points by seky 13y ago

AndrewDucker 13y ago

At some point can they mandate DNSSEC?

bazzargh 13y ago
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 https://www.dns-oarc.net/oarc/data/zfr/root/ds

Jgrubb 13y ago

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?

blumentopf 13y ago
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.
zimbatm 13y ago
Similarly, is there a list of the TLDs that do support DNSSEC ?
- fuqua 13y ago
  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.
- fcambus 13y ago
  ICANN publishes the TLD DNSSEC Report : http://stats.research.icann.org/dns/tld_report/ http://stats.research.icann.org/dns/tld_report/ For ccTLDs only, there is this list : http://www.statdns.com/cctlds/ http://www.statdns.com/cctlds/
nly 13y ago
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.
- slug 13y ago
  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-on-debian-squeeze-ubuntu-11.10 http://www.howtoforge.com/configuring-dnssec-on-bind9-9.7.3-...
tptacek 13y ago
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.

sanxiyn 13y ago

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 https://www.imperialviolet.org/2011/06/16/dnssecchrome.html

ktt 13y ago
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 https://code.google.com/p/chromium/issues/detail?id=50874 And in Mozilla Wiki: https://wiki.mozilla.org/Security/DNSSEC-TLS-details https://wiki.mozilla.org/Security/DNSSEC-TLS-details
zhovner 13y ago
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.
- tptacek 13y ago
  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.
  - zurn 13y ago
    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?
    - tptacek 13y ago
      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.

zdw 13y ago

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

kingzero 13y ago
More on this topic can be found in this talk by djb. https://www.youtube.com/watch?v=K8EGA834Nok https://www.youtube.com/watch?v=K8EGA834Nok
- nly 13y ago
  Original video, complete with download links: http://media.ccc.de/browse/congress/2010/27c3-4295-en-high_speed_high_security_cryptography.html 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
  - zdw 13y ago
    Most 3rd parties are building on libsodium, not the Nacl code: https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium

oliao 13y ago

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?

sanxiyn 13y ago
You can track the progress of DNSSEC validation in Debian at https://wiki.debian.org/DNSSEC https://wiki.debian.org/DNSSEC
spindritf 13y ago
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#setup https://developers.google.com/speed/public-dns/docs/using#se... ² https://unbound.net/ https://unbound.net/

tptacek 13y ago

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=5571937 https://news.ycombinator.com/item?id=4071178 https://news.ycombinator.com/item?id=4071178 https://news.ycombinator.com/item?id=2932378 https://news.ycombinator.com/item?id=2932378

IgorPartola 13y ago
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?
- tptacek 13y ago
  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.
  - IgorPartola 13y ago
    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 http://tools.ietf.org/html/rfc4255 [2] http://web.monkeysphere.info/ http://web.monkeysphere.info/