Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del
From: del@thrush.mlb.semi.harris.com (Don Lewis)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: follow-up to clouso.crim.ca. as bogus root name server.
Message-ID: <1990Nov15.041248.7602@mlb.semi.harris.com>
Date: 15 Nov 90 04:12:48 GMT
References: <9011142027.AA00555@bond.crim.ca>
Sender: news@mlb.semi.harris.com
Distribution: inet
Organization: Harris Semiconductor, Melbourne FL
Lines: 46
Nntp-Posting-Host: thrush.mlb.semi.harris.com

In article <9011142027.AA00555@bond.crim.ca> kinley@BOND.CRIM.CA (J. Darren Kinley) writes:
>HOW DOES THIS BAD INFORMATION GET PROPOGATED? If organization X
>has a name server which serves *only* the domain associated with
>X, no one outside of X should be asking the X name server anything
>other than the domain associated with X. So the bad information
>cannot possible be propogated outside of the X organization! More
>generally, I cannot see any scenario where bad root name server
>information can possibly be propogated by anyone other than root.
>The exception of course, is that humans force this bad information
>to be propogated while playing with nslookup or dig. If anyone
>can enlighten me it would be *greatly* appreciated.

Generally what happens is that the name server for X is somehow
broken and is not acting as a name server for X (usually it is
supposed to be a secondary server and is listed as a server for X
with the root servers, but it is not configured to be a server for X).
Its response to queries about X basically tells the client that it
doesn't know anything about X and that the client should go ask the
root servers.  Just to be helpful, it sends along the (possibly bogus)
list of the root server names and addresses that it has in its cache.
If the client happens to be BIND, it happily caches this root server
information.  If the client is broken in a similar way or is acting
as a forwarder for another server that is broken in a similar way,
this bogus information can continue to propagate.  There are a lot
of servers in this category in the in-addr.arpa domain.

I have also observed some versions of Sun's BIND responding with
the root server list in the authority/additional sections even when
they have an authoritative answer to the query.

>
>Concerning debugging, I have often heard (read) people mention
>reading traces. Reading a trace is the last thing that I want to do!
>Perhaps it is time to discuss alternative methods or procodures
>we (domain admins) can try in order to help isolate problems.
>I have listed the steps in my approach to the problem. Can someone
>suggest a better approach?

If you are running BIND, there are patches floating about that
will log all delegations to the root servers and the associated
questions and IP address of the culprit.  I try to scan the logs
periodically and harass the responsible parties.
-- 
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901