Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

security.googleblog.com

Post reply on HN
Print view View original

21–30 of 72 posts

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

#21

Post by tptacek »

omoikane wrote: post #18
LinuxBender wrote: post #6

Earlier quoted context omitted.

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

The rabbit hole on people gradually pulling up stakes on DNSSEC goes deeper than that; I'd say the canary in the coal mine is probably Geoff Huston switching from "of course we're going to DNSSEC everything" to "are we going to DNSSEC anything?":

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.

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

#22

Post by contingencies »

freedomben wrote: post #20
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)

Guess - possibly some sort of outbound port-knock alternative:

   if (SYN->dest port && TTL > X) { ACK };

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

#23

Post by singpolyma3 »

8organicbits wrote: post #14
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.

Unfortunately it's quite easy for some actors to get a valid TLS cert https://notes.valdikss.org.ru/jabber.ru-mitm/

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

#24

Post by akira2501 »

ape4 wrote: post #3

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

That's how you maintain backwards compatibility while improving security. I'm not sure lamenting the imperfection is valuable, but it is a worthwhile lesson for those designing new protocols.

If it becomes popular enough you will certainly face future security challenges you failed to even imagine. Leave some room for that.

Otherwise, this is great work.

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

#25

Post by phicoh »

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.

DNS is where the web would have been if browsers basically didn't force websites to support HTTPS.

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.

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

#26

Post by tptacek »

phicoh wrote: post #25
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.

DNS is where the web would have been if browsers basically didn't force websites to support HTTPS. 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 al…

The key thing to note is that anti-poisoning countermeasures deployed at major authority servers scale to provide value without incurring cost for every (serverside) Internet "user", and DNSSEC doesn't. A lot of these thing seem like (really, are) half-measures, but their cost/benefit ratio is drastically different, which is why they get rolled out so quickly compared to DNSSEC, which is more akin to a forklift upgrade.

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

#27

Post by radicaldreamer »

freedomben wrote: post #20
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)

[flagged]

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

#28

Post by Hazelnut2465 »

tptacek wrote: post #19
Hazelnut2465 wrote: post #9

Earlier quoted context omitted.

> 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/

And? The IETF RFC draft for ADoT still specifies that it relies on DNSSEC.

https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-a...

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

#29

Post by phicoh »

tptacek wrote: post #26
phicoh wrote: post #25

Earlier quoted context omitted.

DNS is where the web would have been if browsers basically didn't force websites to support HTTPS. 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 al…

The key thing to note is that anti-poisoning countermeasures deployed at major authority servers scale to provide value without incurring cost for every (serverside) Internet "user", and DNSSEC doesn't. A lot of these thing seem like (really, are) half-measures, but their cost/benefit ratio is drastically different, which is why they get rolled out so quickly compared to DNSSEC, which is more akin to a forklift upgra…

There is no quickly in the Google article. It took them ages to roll out 0x20. Cookies are not very well supported. And then the elephant in the room is the connection between the stub resolver and the public DNS resolvers.

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

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

#30

Post by egberts1 »

contingencies wrote: post #22
freedomben wrote: post #20

Earlier quoted context omitted.

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

Guess - possibly some sort of outbound port-knock alternative: if (SYN->dest port && TTL > X) { ACK };

this
Post reply on HN