Chris Brenton wrote:
On Mon, 2005-03-28 at 01:04, John Payne wrote:
And to Randy's point about problems with open recursive nameservers... abusers have been known to cache "hijack". Register a domain, configure an authority with very large TTLs, seed it onto known open recursive nameservers, update domain record to point to the open recursive servers rather than their own. Wammo, "bullet proof" dns hosting.
I posted a note to Bugtraq on this process about a year and a half ago as at the time I noticed a few spammers using this technique. Seems they were doing this to protect their NS from retaliatory attacks. http://cert.uni-stuttgart.de/archive/bugtraq/2003/09/msg00164.html
Large TTLs only get you so far. All depends on the default setting of max-cache-ttl. For Bind this is 7 days. MS DNS is 24 hours. Obviously spammers can do a lot of damage in 7 days. :(
HTH, Chris
TIC: Apparently DNS was designed to be TOO reliable and failure resistant. As I understand from reading the referenced cert thread, there is the workaround which is disabling open recursion and then there are the potential fixes. 1) Registrars being required to verify Authority in delegated to nameservers (will this break any appreciated valid models?) before activating/changing delegation for zone.<REAL FIX> If this is all there is to it, than I see no reason why Registrar laziness and desire for profit$ should take precedence over ops changes across the board. Is it possible/practical to perpertrate this kind of hijak without registrar cooperation by first seeding resolver's caches and then changing NS on authoritative so that future caches will resolve from seeded resolvers? Is it possible to not even need to change the zone served NS/SOA and to use the hijaking values from the get-go? 2) Stricter settings as regards to all lame delegations -- SERVFAIL by default without recursion/caching attempts? 3) Paranoid checking for situations such as these by having recursing nameservers attempt to periodically check for suspicous NS and glue from the parent zone's POV and compare it to cache, trashing cached records if they do not like result. 4) Rate limiting? Since at this point I am out of my depth, I think I'll stop here after a simple question. Is all the local limitations on TTL values a good thing?