

DNSSEC surpasses 50% of root domains - seky
http://blog.icann.org/2014/01/dnssec-surpasses-50/

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

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

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

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

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

~~~
zdw
I've been running CurveDNS
([http://curvedns.on2it.net](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/](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.

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

------
Jgrubb
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?

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

~~~
fcambus
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/)

------
sanxiyn
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)

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

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

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

------
oliao
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?

~~~
spindritf
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://developers.google.com/speed/public-
dns/docs/using#setup)

² [https://unbound.net/](https://unbound.net/)

------
AndrewDucker
At some point can they mandate DNSSEC?

~~~
bazzargh
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)

