No, it obviously isn't, because less than 5% of zones are signed, and an even smaller fraction of important zones (the Moz 500, the Tranco list) are.
That's why they don't mention DNSSEC: because it isn't a significant security mechanism for Internet DNS. It's also why they do mention ADoT: because it is.
I think this is also why DNSSEC advocates are so fixated on DANE, which is (necessarily) an even harder lift than getting DNSSEC deployed: because the attacks DNSSEC were ostensibly designed to address are now solved problems.
Note also that if ADoT rolls out all the way --- it's already significantly more available than DNSSEC! --- there won't even be a real architectural argument for DNSSEC anymore, because we'll have end-to-end cryptographic security for the DNS.
Thanks for calling this out! That Google feels case randomization is more important than DNSSEC is indeed telling.
Check out the DPRIVE working group (ekr's comments in particular) for some of the backstory. DNSSEC isn't happening either way, but I think ADOX might.
I think this is a bit of an apples and oranges moment.
While I agree transport confidentiality is important, that is not what DNSSEC solves, nor should you see people saying that it does solve confidentiality.
DNSSEC protects the transport integrity of DNS responses. DNSSEC enabled zones 100% defeat on-path cache poisoning attacks to recursive resolvers that are DNSSEC enabled. Full stop.
ADo"X" protects the transport confidentiality of DNS responses. I suppose this "weakly" protects the transport integrity of DNS responses, but, again, the primary purpose is confidentiality.
After reading RFC 9539, it's clearly stated that it's opportunistic encryption. An on-path attacker will find it trivial to disable encryption and start poisoning caches. The RFC states in multiple places that if TLS setup fails, fall back to plaintext DNS.
If DNSSEC fails, an on-path attacker has no similar recourse. A properly configured recursive resolver will SERVFAIL and _never_ send back a potentially poisoned response to clients for DNSSEC signed zones.
> the attacks DNSSEC were ostensibly designed to address are now solved problems.
Maybe you can help figure out where you went wrong here by explaining what - in your understanding - were the problems that DNSSEC was "ostensibly designed to address" ?
> because we'll have end-to-end cryptographic security for the DNS.
In 1995 a researcher who was annoyed about people snooping his passwords over telnet invented a protocol (and gave away a free Unix program) which I guess you'd say delivers "end-to-end cryptographic security" for the remote shell. Now, when you go into a startup and you find they've set up a bunch of ad hoc SSH servers and their people are just agreeing to all the "Are you sure you want to continue ..?" messages, do you think "That's fine, it's end-to-end cryptographic security" ? Or do you immediately put that on the Must Do list for basic security because it's an obvious vulnerability ?
Many years ago, when HTTPS adoption was in the 5% range, if someone would have said “HTTPS is the ultimate defense against web page spoofing”, would you have argued that it was false, just because the adoption was so low?
DNSSEC is the ultimate defense against cache poisoning attacks, no matter the adoption percentage.
Google is aware and has enabled DNSSEC on their recursive resolvers for a long time.
Unfortunately, most people do not DNSSEC sign their zones, so Google have to resort to also enabling 0x20, which is helpful, but also (to an extent) security theater.
I think your posting style of making confident statements, but responding to counter-arguments with rhetorical cheap shots and condescending non-answers, is unsuitable for HN.
That's why they don't mention DNSSEC: because it isn't a significant security mechanism for Internet DNS. It's also why they do mention ADoT: because it is.
I think this is also why DNSSEC advocates are so fixated on DANE, which is (necessarily) an even harder lift than getting DNSSEC deployed: because the attacks DNSSEC were ostensibly designed to address are now solved problems.
Note also that if ADoT rolls out all the way --- it's already significantly more available than DNSSEC! --- there won't even be a real architectural argument for DNSSEC anymore, because we'll have end-to-end cryptographic security for the DNS.
Thanks for calling this out! That Google feels case randomization is more important than DNSSEC is indeed telling.