The that the longer your domain name, the less susceptible is it to cache poisoning attacks, right? Since there are more possible case variations.
Google Public DNS's approach to fight against cache poisoning attacks
31–40 of 72 posts
Re: Google Public DNS's approach to fight against cache poisoning attacks
#32Weird 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…
If we didn't have the web, all networking above OSI L4 on all operating systems would have been encrypted by default. A simple set of syscalls and kernel features could have enabled it. But since the web was there, and popularized a solution for secure communications (TLS + HTTP), everyone just jumped on that bandwagon, and built skyscrapers on top of a used books store.
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.
Re: Google Public DNS's approach to fight against cache poisoning attacks
#33Earlier quoted context omitted.
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...
Did it take 25 years? That's the baseline. :)
Re: Google Public DNS's approach to fight against cache poisoning attacks
#34Earlier 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…
If we didn't have the web, all networking above OSI L4 on all operating systems would have been encrypted by default. A simple set of syscalls and kernel features could have enabled it. But since the web was there, and popularized a solution for secure communications (TLS + HTTP), everyone just jumped on that bandwagon, and built skyscrapers on top of a used books store. The weird irony is it's the old "worse is bett…
Can you articulate what you believe is bad about TLS?
Re: Google Public DNS's approach to fight against cache poisoning attacks
#35Earlier 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 };
How is this supposed to work, exactly?
Re: Google Public DNS's approach to fight against cache poisoning attacks
#36I 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…
A recursive resolver is not a database. They're under no obligation to cache for a day.
Re: Google Public DNS's approach to fight against cache poisoning attacks
#37I 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)
Ask and you shall receive: https://news.ycombinator.com/item?id=21436448
Re: Google Public DNS's approach to fight against cache poisoning attacks
#38Earlier quoted context omitted.
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...
Check out the DPRIVE working group (ekr's comments in particular) for some of the backstory. DNSSEC isn't happening either way, but I think ADOX might.
Re: Google Public DNS's approach to fight against cache poisoning attacks
#39I 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…
A recursive resolver is not a database. They're under no obligation to cache for a day.
Okay stupid question… I thought TTL was a count of hops, not time in seconds. Or do people use it differently where instead of subtracting 1, their routing devices subtract n seconds?
Re: Google Public DNS's approach to fight against cache poisoning attacks
#40Earlier quoted context omitted.
A recursive resolver is not a database. They're under no obligation to cache for a day.
Okay stupid question… I thought TTL was a count of hops, not time in seconds. Or do people use it differently where instead of subtracting 1, their routing devices subtract n seconds?
TTL is a general term standing for "time to live". In the context of an IP packet it's a number of hops. In the context of a cache, it's a time until expiration.