Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: DNS cache poisoning attacks -- are they real?

  • From: Joe Maimon
  • Date: Tue Mar 29 08:50:39 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.

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


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?

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.