North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: DNS cache poisoning attacks -- are they real?
On Tue, 2005-03-29 at 08:49, Joe Maimon wrote: > > TIC: Apparently DNS was designed to be TOO reliable and failure resistant. Ya, sometimes security and functionality don't mix all that well. ;-) > 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. >From an admin perspective, this is the way to go. This is a real easy fix with Bind via "allow-recursion". I don't play with MS DNS that often, but the last time I looked recursion was an on/off switch. So of the MS DNS box is Internet accessible, you are kind of hosed. > 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> Back in the InterNIC days this was SOP. This security check got lost when things went commercial. Not sure if it would be possible to get it back at this point. Too many registrars out there to try and enforce it. IMHO lack of verification is only part of the problem (that has been going on for years). What has made this more of an issue is registrars that offer immediate response time to changes. This makes it far easier to spammers to move to other stolen resources as required. > 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? Possibly. I ran into a bug/feature with Bind back in the 8.x days which causes the resolver to go back to the last know authoritative server when a TTL expires. On this plus side, this helps to reduce traffic on the root name servers. On the down side, if the remote name server still claims authority you will never find the new resource. I ran into the problem moving a client from one ISP to another while the old ISP was acting vindictive and refused to remove the old records. This of course caused problems for their clients because when the TTLs expired they kept going back to the old resource. Only way to clear it is a name server restart at every domain looking up your info. When I reported this the bug/feature was changed but I noticed a while back (late 8.x maybe 9.0) that it is back. So if the purp can get you to the wrong server only once it may be possible to keep you there. > 2) Stricter settings as regards to all lame delegations -- SERVFAIL by > default without recursion/caching attempts? See my last post. IMHO there are too many broken but legitimate name servers out there for this to be functional for most environments. > Is all the local limitations on TTL values a good thing? In this case, absolutely! With the default Bind setting, a TTL of 3600000 will get quietly truncated to a week. This means a trashed cache will fix itself in one week rather than six. HTH, Chris