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 TTL's with the caveat I have to wait for each node behind their anycast clusters to cache the record but that's fine.<p>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. <i>Some people watch birds when they retire, I watch packets ... and critters.</i>
Wondering what prompted the blog post. The recent publication of RFC 9539?<p>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.<p>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).
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.
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).<p>Today I let my curiosity dive deeper and quickly found the ietf publication on 0x20 encoding and this article.<p>Just odd to see others post it to hn on the same day.. coincidences are weird.
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.
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.
I updated <a href="https://crates.io/crates/dns-server" rel="nofollow">https://crates.io/crates/dns-server</a> to support case randomization.