Fidelity Domain Hijack?

Kevin Darcy kcd at daimlerchrysler.com
Thu Jun 28 00:10:50 UTC 2001


Arvid Carlander wrote:

> "Barry Margolin" <barmar at genuity.net> wrote in message
> news:9hd65l$fgu at pub3.rc.vix.com...
> > 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.
> >
>
> This seems like a potentially very serious issue if a malicious nameserver
> can use bogus information to gain partial "control" of TLDs.
>
> I'd like to understand what changes have been implemented in later releases
> to fix this problem. Can anyone clarify?

Without analyzing the code in detail, I'd imagine BIND deals with this by
simply not trusting any Authority records which are at a higher level than
where it was referred, e.g. if I'm following a referral to the example.com
nameservers, then I don't trust any Authority records for ".com" or "." in any
response I get from them.


- Kevin





More information about the bind-users mailing list