DNS cache poisoning attacks -- are they real?

Joe Maimon jmaimon at ttec.com
Tue Mar 29 13:49:19 UTC 2005




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?




More information about the NANOG mailing list