Google Public DNS's approach to fight against cache poisoning attacks
security.googleblog.com
Google Public DNS's approach to fight against cache poisoning attacks
1–10 of 72 posts
Re: Google Public DNS's approach to fight against cache poisoning attacks
#2I see most of the bot traffic hiding behind Google and Cloudflare. I appreciate that. They take a lot of load off my servers. If I had one request of Google it would be to remove the TTL cap of 21600 or raise it to 86400 to further reduce the traffic that comes through from them as my TTL records are very high on purpose for my own reasons that I will not debate. I know memory is still a limit. CF seem to honor my TTL's with the caveat I have to wait for each node behind their anycast clusters to cache the record but that's fine.
As a side note, whatever group in Google are running DNS are doing a great job. I do not see malformed garbage coming from them. Some people watch birds when they retire, I watch packets ... and critters.
Re: Google Public DNS's approach to fight against cache poisoning attacks
#3Good to hear the world's infrastructure relies on a kludge like case randomization.
Re: Google Public DNS's approach to fight against cache poisoning attacks
#4Weird 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.
Re: Google Public DNS's approach to fight against cache poisoning attacks
#5Weird 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.
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.
Re: Google Public DNS's approach to fight against cache poisoning attacks
#6Weird 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.
Just guessing but it could be the lack of adoption. Despite having climbed rapidly in the last few years [0] the percentage is still very low. [1]
[0] - https://www.verisign.com/en_US/company-information/verisign-...
[1] - https://www.statdns.com/
Re: Google Public DNS's approach to fight against cache poisoning attacks
#7I see most of the bot traffic hiding behind Google and Cloudflare. I appreciate that. They take a lot of load off my servers. If I had one request of Google it would be to remove the TTL cap of 21600 or raise it to 86400 to further reduce the traffic that comes through from them as my TTL records are very high on purpose for my own reasons that I will not debate. I know memory is still a limit. CF seem to honor my TT…
I aspire to be you when (if) I retire.
Re: Google Public DNS's approach to fight against cache poisoning attacks
#8Weird 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.
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…
> 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 ?
Re: Google Public DNS's approach to fight against cache poisoning attacks
#9Weird 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.
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…
> there won't even be a real architectural argument for DNSSEC anymore
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).
Re: Google Public DNS's approach to fight against cache poisoning attacks
#10[flagged]