Hacker News Reader

Comment by bluejekyll | Hacker News Reader

Exactly. Does anyone know of any standard deployments that actually have the clients verify the DNS key chain?

Edit: I moved the OpenSSL 1.1.0 comment to the DANE thread, see

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

That depends on how you define a client. If you're a Comcast customer, for example, they are performing DNSSEC validation for you transparently. Recursive resolvers on most Linux distributions have DNSSEC validation by default.

One school of thought is to migrate DNSSEC from relying on validating resolvers sitting within the network provider, and moving it closer to the edge, in web browsers and so forth. Not much of that has happened to date.

> One school of thought is to migrate DNSSEC from relying on validating resolvers sitting within the network provider, and moving it closer to the edge, in web browsers and so forth. Not much of that has happened to date.

Fedora is actively working to including a system-local DNS resolver by default that will validate DNSSEC-signed zones. The change was originally slated for F24 but was deferred due to lack of resources, but I suspect it should make it in by F26/F27 if all goes well and some of the NAT64 issues that were discovered with Unbound are fixed.

What Fedora plans to do is to use a local resolver with a fallback in case DNSSEC doesn't work. By this trick they try to prevent the inevitable deployment problems of DNSSEC. Of course they also make it completely insecure and it doesn't make any sense.

The fallback is to be configurable, but breaking the entire UX is not desirable when a full recursive resolver is unable to function. Personally, I would like to see some indication as part of the GNOME Network icon whether the resolver is secure or not, but I have a hard time determining what that would look like and how to implement it without giving users false assurances or worrying them if they don't care.

It's a tricky problem to solve, but Rome wasn't built in a day either. I'll probably disable the insecure fallback myself and only turn it on when I connect to my work VPN, I already don't trust public hotspots so unless I can connect to my OpenVPN server at home I don't use them.

>if you're a Comcast customer, for example, they are performing DNSSEC validation for you transparently.

Also, if you are using Google's public DNS (8.8.8.8), they are doing DNSSEC validation for you... that is a significant percentage of the Internet today.

So what? You yourself are speaking plain-ol'-DNS over the public Internet, probably using UDP packets, to some data center that happens to have a Google DNS server in it. Why do you trust that link? And if you do: what is DNSSEC doing for you? Google's DNS servers are the most heavily cached and carefully monitored on the Internet.

Here we see the single most batshit aspect of DNSSEC: validation is done on the servers and not on the endpoints (you "can" do endpoint validation, in the same sense as you "can" run your own recursive caching server locally).

This is a relic of the early-mid 1990s, when the core DNSSEC design was finalized and any kind of encryption was thought to be too expensive to deploy to end-systems. It's also the reason DNSSEC is signing-only, with no privacy protections. The people who made those decisions were wrong. It was in fact possible to predict that cycles-per-byte costs for encryption would be driven down a rounding error in just a dozen or so years.

But we're still forced to live with that bad decision, because nobody in the IETF wants to admit they were wrong.

I was not implying the opposite (and I agree that all of this without end-to-end is less than effective), simply stating that DNSSEC is used much more than the parent assumes.

Since very little of the Internet is DNSSEC-signed, I think it's used a lot less than you think it is.

  1493 TLDs in the root zone in total
  1343 TLDs are signed;
  1330 TLDs have trust anchors published as DS records in the root zone;
  5 TLDs have trust anchors published in the ISC DLV Repository.

http://stats.research.icann.org/dns/tld_report/

It matters that the TLDs are signed in the sense that DNSSEC is on its face a weird joke if BANKOFAMERICA.COM can get a signature, but .COM is itself not signed.

After 20+ years of standardization effort, we finally reached the point just a few years ago where Bank of America could theoretically get a meaningful signature, because .COM was signed (chaining to an RSA-1024 signature!).

But BANKOFAMERICA.COM is not signed. Nor is the overwhelming majority of the Internet. Most of the TLD's are signed, because they can be required to sign by fiat, and were. But for BANKOFAMERICA.COM to be signed, the market has to recognize some value for the effort of signing and then keeping the site signed (because if they screw it up somehow once they do sign, they'll be taken off the Internet by the small but unfortunately significant portion of end-users whose ISPs are, without them asking for it, validating DNSSEC lookups).

Smart operators are unlikely to do anything like that, because they all saw (for instance) what happened to HBO NOW, which was unavailable to anyone with a Comcast connection on its launch day due to a DNSSEC glitch.

> Google's DNS servers are the most heavily cached and carefully monitored on the Internet

Is your point that we trust Google's DNS too much?

> most batshit aspect of DNSSEC: validation is done on the servers and not on the endpoints (you "can" do endpoint validation, in the same sense as you "can" run your own recursive caching server locally).

You "can" and we "should" be validating this at the client. So why don't we start doing this? We should be beating on the security layer in DNS as heavily as we do with HTTPS and other TLS implementations.

> This is a relic of the early-mid 1990s, when the core DNSSEC design was finalized and any kind of encryption was thought to be too expensive to deploy to end-systems. It's also the reason DNSSEC is signing-only, with no privacy protections.

There are several proposals at this point that resolve the privacy issue, DNSCrypt, DNSCurve, and DNS over TLS.

> But we're still forced to live with that bad decision, because nobody in the IETF wants to admit they were wrong

Given the number of revisions to the DNS RFCs, specifically around DNSSec, I don't think it would be accurate that they didn't admit being wrong, people are constantly working to resolve issues with the system.

If we're going to accept that shit is broken and we should go ahead and fix it, why can't we fix DNSSEC itself? It's a terrible, broken, already-obselete protocol that sees virtually no meaningful real-world deployment. Why would we spend tens of millions of dollars to deploy something we already know is broken.

see my comment in a sibling thread: https://news.ycombinator.com/item?id=12392121

Reply on news.ycombinator.com