Weird that they don't even mention that Google's public DNS performs DNSSEC validation. It does, and that's the ultimate defense against cache poisoning attacks.
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.
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 ?
ADoT relies on NS records to be DNSSEC signed.
The TLS certificates that ADoT relies on need to be hashed into TLSA records (DANE, DNSSEC).
https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-a...
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.
DNSSEC is the ultimate defense against cache poisoning attacks, no matter the adoption percentage.
(I also note that you didn’t answer my question, and instead opted for a rhetorical cheap shot reply to my second paragraph only.)
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.
If you can't securely authenticate your server (as HTTPS/TLS does) you have other problems too.
Still, good to see that monitoring the CT logs would have caught this problem much sooner.
The reasoning is that DNS is not important enough to go through the trouble of deploying DNSSEC. These days TLS is often cited as the reason DNSSEC is not needed.
At the same time we see a lot of interest in techniques to prevent cache poisoning and other spoofing attacks. Suddenly in those cases DNS is important.
If all DNS client software would drop UDP source port randomization and randomized IDs, then lots of people would be very upset. Because DNS security was more important than claimed.
DNS cookies are also an interesting case. They can stop most cache poisoning attacks. But from the google article, big DNS authoritatives do not deploy them.
The interesting thing is what happens when BGP is used to redirect traffic to DNS servers: https://www.thousandeyes.com/blog/amazon-route-53-dns-and-bg...
The weird irony is it's the old "worse is better" winning again. HTTP and TLS are fairly bad protocols, in their own ways. But put them together and they're better than whatever else exists. It's just too bad we didn't keep them and ditch the browser.
The problem is that applications typically use TCP connections, but IPSEC works at the IP level. Early on, the (BSD socket) kernel API was basically fixed at the IP level instead of associating it with a TCP socket.
So the whole thing became too complex (also for other reasons). So SSL and SSH were created to have simple things that worked.
SSL took many iterations to get any kind of security, so IPSEC had plenty of time to get it right and take over. But as far as I know, there just never happened. It also doesn't help that TLS is trivial to combine with NAT, and for IPSEC that is quite tricky.
[0] - https://www.verisign.com/en_US/company-information/verisign-...
[1] - https://www.statdns.com/
https://news.ycombinator.com/item?id=36171696 - Calling time on DNSSEC: The costs exceed the benefits (2023)
And also many news regarding validation failures:
https://www.potaroo.net/ispcol/2023-02/dnssec.html
(Geoff Huston is an Internet infrastructure giant.)
But really it all just boils down to the fact that the DNS zones that matter --- the ones at the busy end of the fat tail of lookups --- just aren't signed, despite 25 years of work on the standard. IPv6 is gradually mainstreaming; in countries where registrars auto-sign zones, DNSSEC is growing too, but very notably in countries where people have a choice, DNSSEC deployment is stubbornly stuck in the low single digit percentages, and the zones that are getting signed are disproportionately not in the top 10,000 of the Tranco list.
Some other counterpoints to general DNSSEC doomsayers:
• <https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-...>
• <https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and...>
Edit: Is this authoritative enough for you? <https://www.icann.org/resources/pages/dnssec-what-is-it-why-...>
This is what I mean when I say we're not really talking to each other. I don't think you understand or care about the argument I'm making, and so you're not engaging with it. That's fine! But then: let's just stop engaging.