Google Public DNS's approach to fight against cache poisoning attacks • Hacker News Board

Re: Google Public DNS's approach to fight against cache poisoning attacks

#11

Post by mjl- » Sun, Apr 07, 2024, 3:10 PM UTC

Wondering what prompted the blog post. The recent publication of RFC 9539?

It would be interesting to hear how often the google dns servers see attempts to poison their cache. The mitigations probably prevent folks from even trying, but he numbers would be interesting.

The OARC 40 presentation PDF mentions cookies deployment is low for large operators but open source software has compliant implementations. Are large operators writing their own dns servers, but badly? I would think there wouldn't be many custom implementations, and that you would be able to detect which software nameservers are running, each with known capabilities. But from the way the numbers are presented it seems they only look at behaviour without considering software (versions).

Re: Google Public DNS's approach to fight against cache poisoning attacks

#12

Post by rainsford » Sun, Apr 07, 2024, 3:16 PM UTC

I'm a little surprised Google only implemented case randomization by default in 2022 considering it's been around since 2008. Presumably they had concerns about widespread compatibility? Although my understanding is that for a lot of DNS servers it just worked without any specific implementation effort...but maybe there was a long tail of random server types Google was concerned about.

Re: Google Public DNS's approach to fight against cache poisoning attacks

#13

Post by spydum » Sun, Apr 07, 2024, 3:45 PM UTC

This is so weird to see. Just this morning I was checking thru my public authoritative NS query logs, and noticed the random capitalization. I had also noticed this in a similar work environment roughly end of 2023, but attributed it to people just doing DNS wordlist bruteforcing to find stuff (couldn't explain the case, but figured it was some evasion).

Today I let my curiosity dive deeper and quickly found the ietf publication on 0x20 encoding and this article.

Just odd to see others post it to hn on the same day.. coincidences are weird.

Re: Google Public DNS's approach to fight against cache poisoning attacks

#14

Post by 8organicbits » Sun, Apr 07, 2024, 3:59 PM UTC

AndyMcConachie wrote: post #4

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.

For end users, TLS is the key protection. I don't care if my DNS is poisoned, MITMed, or malicious: if the IP address I connect to can't present a valid TLS cert, then I don't proceed.

If you can't securely authenticate your server (as HTTPS/TLS does) you have other problems too.

Re: Google Public DNS's approach to fight against cache poisoning attacks

#15

Post by jeffbee » Sun, Apr 07, 2024, 4:09 PM UTC

I first heard about this 0x20 scheme around 2015 when I was working on a DNS cache (also at Google, but not for the public DNS team). I noticed and had to work around the fact that some servers were responding in vixie-case even when the requests were not. Those servers would be broken if the requests were paying attention to 0x20, right? I wonder what software was doing that.

Re: Google Public DNS's approach to fight against cache poisoning attacks

#16

Post by bradfitz » Sun, Apr 07, 2024, 4:58 PM UTC

ape4 wrote: post #3

Good to hear the world's infrastructure relies on a kludge like case randomization.

Longer domain names are more secure!

Re: Google Public DNS's approach to fight against cache poisoning attacks

#17

Post by jamespwilliams » Sun, Apr 07, 2024, 5:28 PM UTC

bradfitz wrote: post #16

ape4 wrote: post #3

Good to hear the world's infrastructure relies on a kludge like case randomization.

Longer domain names are more secure!

And conversely, short domains like Google’s own g.co are less secure!

Re: Google Public DNS's approach to fight against cache poisoning attacks

#18

Post by omoikane » Sun, Apr 07, 2024, 5:39 PM UTC

LinuxBender wrote: post #6

AndyMcConachie wrote: post #4

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.

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/

The low adoption of DNSSEC might be due to posts like these:

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://hn.algolia.com/?q=dnssec

Re: Google Public DNS's approach to fight against cache poisoning attacks

#19

Post by tptacek » Sun, Apr 07, 2024, 6:08 PM UTC

Hazelnut2465 wrote: post #9

tptacek wrote: post #5

Earlier quoted context omitted.

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).

https://educatedguesswork.org/posts/dns-security-adox/

Re: Google Public DNS's approach to fight against cache poisoning attacks

#20

Post by freedomben » Sun, Apr 07, 2024, 6:14 PM UTC

LinuxBender wrote: post #2

I 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…

> my TTL records are very high on purpose for my own reasons that I will not debate.

Why are your records high? Is the load on your servers too intense otherwise? (not trying to debate, am curious because I've really appreciated your comments/insights in the past)