Hacker News Reader

Comment by zaik | Hacker News Reader

> As of December 2023, approximately 31 percent of web clients worldwide used DNSSEC-validating DNS resolvers

That doesn't seem right. Ever since enabling DNSSEC validation on my system, YouTube and every other Google product except basic searching is broken for me. The percentage of internet users who enforce DNSSEC must be much much smaller.

View on HN

I'm not sure the logic, since you have problems everyone else must have them too? Google DNS / Cloudflare DNS are both DNSSEC validating revolvers, two of the most popular DNS services on the planet. Most US based ISP resolvers are DNSSEC validating (Xfinity's 75.75.75.75 is). Google Chrome ships with DOH going to Google DNS on by default now, Firefox does DOH by default as well.

So I can absolutely see where this would easily be the case, if not more.

You can view a map of DNSSEC validation rates here: https://stats.labs.apnic.net/dnssec

> Ever since enabling DNSSEC validation on my system, YouTube and every other Google product except basic searching is broken for me.

Enabling DNSSEC wouldn't change resolution of those properties unless you somehow set your system to treat insecure delegations as bogus. Is that what you've done?

Then what’s the point of DNSSEC?

Nothing if its not enabled on a domain

DNSSEC evaluates answers as being one of secure, insecure, or bogus. Secure means there's proof the answer is correct going all the way back to the root. Insecure means at some point there was a delegation that either opts out, or requires use of an unknown signature algorithm or unsupported NSEC3 parameters (unknown/unsupported by the validating software). Bogus means there was no proofs or the proofs didn't check out.

Of course there's not much point to that evaluation if you're only looking up IP addresses and then relying on WebPKI to see that the other end is what you expected it to be.

EDIT:

I'm not allowed to reply for some reason, so in answer to tptacek:

> Right, which leaves open the question of what the point is.

No, I don't think it does. I think my summary reasonably conveys the functionality DNSSEC offers and how it is practically useful. (This is not a flippant response, the spade is a spade.)

Right, which leaves open the question of what the point is.

A more pointed critique implied by the thread you're replying to is: if virtually nothing on the Internet is signed, what's the point?

The ATHENE team's Black Hat talk from last year surveyed the "Tranco Top 500k", whatever that is, but I'll just say that 500k is more hosts than the 500 top hosts I use from the Moz500 for the same stat, and found that (wait for it) less than 5% of hosts in that dataset worldwide were signed, and a substantial number of those hosts are just signed by their registrars.

If you were going to make a case for an ordinary Internet user, like, the modal American user, to enable DNSSEC --- what would it be? What benefit would they get?

Not so long ago less than 5% of hosts were using HTTPS. But we're now in a world where being HTTP-only (or being HTTPS but not having a valid chain of trust signing your certificate) is unusual and suspicious, and presumably we believe that while that was something that had to be pushed out by browser makers etc., it ultimately benefits users. I would hope DNS will eventually go the same way for the same reasons.

The adoption curve, in addition to being a decade and a half back from DNSSEC at that point, was also the inverse of DNSSEC's: the most popular sites on the Internet generally used HTTPS, and the least popular sites on the Internet dominate DNSSEC, with only 4.5% of the Tranco Top 500k being signed. And DNSSEC is the older protocol! Respectfully, the comparison is risible.

I've had DNSSEC validation enabled for years and Google's services never broke for me. I don't think the problem lies with Google on this one, it's probably a bug in your resolver (or worse, your ISP may be intercepting DNS traffic to Google).

l.google.com has some kind of DNSSEC error [1] but it seems to be required to load youtube.com

[1] https://dnsviz.net/d/l.google.com/dnssec/

GOOGLE.COM isn't signed at all.

I am "forced" to allow "our" domains to be DNSSEC because... an auditor suggested it as a possible improvement and some manager thought it a good idea to do whatever said auditor proposes.

The argument that absolutely nothing that the world relies on, is not being singed (google Facebook reddit Cisco MicroSoft etc) holds no clout with the believers, unfortunately.

DNSVIZ is a bit unclear in this case. It doesn't warn that the initial delegation from .com to google.com is insecure, but it does warn that the delegation from google.com to l.google.com is.

Google doesn't use DNSSEC, unfortunately, so this shouldn't be a problem. If your resolver breaks on this, I think that may be the result of a bug or misconfiguration, because there's no DNSSEC to validate here.

Some public resolvers like quad9[1] valid dnssec for you. My guess is people using those resolvers is what they are talking about?

That number does still seem high though.

[1]: https://quad9.net/support/faq/#dnssec

Yeah, I don't buy that either.

Consulting and working for MSPs over the last 10 years I've probably been exposed to a couple hundred environments and I've never once seen DNSSEC validation used.

Reply on news.ycombinator.com