Just one bad packet can bring down a vulnerable DNS server thanks to DNSSEC

https://support.mozilla.org/en-US/kb/firefox-dns-over-https#...

Chrome followed:

https://duo.com/decipher/google-makes-dns-over-https-default...

Isn't it possible under WebPKI rules to get an intermediate cert for all of your subdomains so that only the intermediate cert needs to get logged in certificate transparency? Or at the very least, you could use a wildcard underneath the domain you own...

From the perspective of something like a browser, the mapping from the domain name to the IP address (i.e., the A or AAAA records) need not be secured via DNS because the connection to the server is secured via TLS and the WebPKI. So DNSSEC isn't helping here, especially because the clients don't check DNSSEC, so it doesn't protect them from attack on the local network, which is one of the main loci. If the DNS server provides the wrong IP, this is mostly a DoS attack.

I am aware that the situation is somewhat different in email but I'm not sure how different really. Note that it is the case that DNSSEC could help secure ACME validation queries, but as tpacek observes, CT has greatly reduced the risk of misissuance.

Of course there are other mappings in the DNS, but as a general matter those are being designed under the assumption that the DNS is untrustworthy, due to the low level of DNSSEC deployment. For instance, if you look at the HTTPS RR, it's fine to put a key for Encrypted Client Hello in it because the resolver already knows the desired domain name, so lying about the key doesn't really help. However, we can't safely publish the server's public key to be used for TLS 1.3 early data ("Zero RTT priming") because that would require trusting the DNS. So, any features which require the DNS to be secure have the usual chicken-and-egg deployment problems (this is also to a great extent what happened with DANE).

Taking the opportunity to reference myself, the following longer writeups might be useful on this topic:

https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dane/

Not as it's deployed today. Since over 80% (conservative guesstimate) of the zones that most people care about are not signed, it's pretty much useless.

The 'evil ISP or IT MITMs my DNS traffic' scenario is much more effectively addressed with DoH (since it only requires clients and some resolvers to coordinate, not the entire Internet, and it looks like regular HTTPS, which implementers already understand how to deal with, as a bonus).

And the 'evil government redirects some or all zones' play is still very much possible even with DNSSEC, since, guess who ultimately controls the keys.

Even if you think that making the latter scenario more difficult to implement is worth it, getting more people to sign their zones is a losing battle, since they're very much likely to self-DoS themselves in the process, significantly reducing their enthusiasm...

It does no such thing. An attacker on the resolver or between the resolver and authoritative is able to strip DNSSEC.

DNSCrypt was the solution to all the problems we had, but at the time DNS software vendors and operators also had a financial interest in passive monitoring so DNSSEC being clear on the wire won.

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

This is one of those HALT problems that everyone likes to dismiss :)

From where I sit, I work at a registry and DNS server host (among other things) where about 40% of all our domains have DNSSEC (and that number is constantly climbing). Every conference I go to, and in every webinar, people seemingly always talk about DNSSEC and how usage is increasing.

From my perspective, your continuous claim that “nobody uses” DNSSEC is simply false. DNSSEC works, usage of DNSSEC is steadily increasing, and new protocols (like DANE) are starting to make use of DNSSEC for its features. Conversely, I only relatively rarely hear anything about MTA-STS.

(Originally written as a two year old comment of mine: <https://news.ycombinator.com/item?id=27837530>, but the details given have not changed substantially.)

There exist other application-layer protocols than HTTP.

The Web PKI relies heavily on DNS, and thus without DNSSEC it's vulnerable to spoofing. Of course people like Thomas have worked very hard to get people not to enable DNSSEC, and so a great many domains can be spoofed. Are they? Maybe†. It's hard to tell, after all there would be no sign of a problem, everything looks fine, there's no validation step because you said you didn't want one...

† At a previous employer in 2019 I looked into this. Military intelligence definitely perform attacks on foreign country Internet infrastructure, but at that time they mostly seemed to rely on the fact that users don't use TLS and/or dismiss dialogs saying the certificates didn't match. The UX got better since, so I'd expect today they routinely ask a CA to issue for these unvalidatable domains once they control the packet flow.

For most users there's really no reason for a ZSK/KSK split or rolling keys, much the same as there's no need for rolling SSH keys for most users.