North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: DNS cache poisoning attacks -- are they real?
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. 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?
|