DNS cache poisoning attacks -- are they real?

Tue Mar 29 15:59:17 UTC 2005

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