Fidelity Domain Hijack?

[Barry Margolin]

In article <9hb2ra$ltc at pub3.rc.vix.com>,
Carl Hirsch <carlhirsch at hotmail.com> wrote:
>
>Apologies if this is the wrong forum, but I'm in the process of doing
>a post-mortem on a network hiccup we experienced this afternoon.
>
>Today our DNS servers started resolving "www.401k.com" as
>"www.xxlteen.com".
>
>401k.com, www.4o1k.com were just fine. Clearing the cache on our DNS
>servers resolved the problem of our execs trying to check up on their
>mutual funds and getting Hot Teen Action instead.
>
>We've got no evidence that any of our boxes were compromised, so I'm
>wondering what happened. Could a DNS serve closer to the root than us
>have been compromised and propogated bad information? A brief search
>of various security sites turned up no mention of Fidelity's Primary
>DNS getting cracked.
>
>This situation strikes me as an excellent opportunity to learn more
>DNS-fu.

Occasionally when a customer has reported problems looking up some domains,
I've queried their DNS server and found strange NS records for COM in their
cache.

What seems to be happening is that some hosting organizations have been
configuring their nameservers as authoritative for TLD's like COM and NET,
and entering all their data in these zones, rather than having separate
zones for customer1.com, customer2.com, etc.  When their server responds,
the Authority Records section of the response contains the bogus NS records
for COM and NET that point to these servers, and some nameservers replace
the cached NS records that came from the root server with these.  From then
on, they query those nameservers instead of the real GTLD servers when
looking for new domains in that TLD.

In most cases, this just results in lots of "Host not found" errors,
because these bogus TLD servers don't have complete COM zone files.  But a
malicious organization could easily use this same mechanism to redirect
lots of domains to their own server simply by putting a wildcard A record
into the COM zone.

We're running BIND 8.2.3 on our caching servers and it seems to be immune
to this sort of cache poisoning, as I haven't been able to reproduce it by
looking up the domains that are delegated to these misconfigured servers.
So when a customer who is running their own caching DNS complains, I tell
them to upgrade or configure their nameserver to forward to ours.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.