Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!uokmax!munnari.oz.au!cs.mu.oz.au!kre
From: kre@cs.mu.oz.au (Robert Elz)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: BOGUS ROOT SERVERS!!
Message-ID: <6045@munnari.oz.au>
Date: 18 Nov 90 18:04:17 GMT
References: <9163@ncar.ucar.edu>
Sender: news@cs.mu.oz.au
Lines: 28

In article <9163@ncar.ucar.edu>, woods@ncar.ucar.edu (Greg Woods) writes:
> What happens is that when a machine is rebooted (or named is restarted), it
> goes into an infinite loop burning tons of CPU time and refusing to answer
> queries.

While several people have been hunting for the source of the trash
in the DNS, I haven't seen an answer explaining why the loop ...

I believe that what is happening is that BIND is using a UDP request
to (one of more of) the servers in your root.cache, asking for a
list of the root servers.   It is expecting that the reply it gets
will contain a list of NS records for '.', and at least, an address
for one of them.

What's happening with all of the trash NS's included, is that there is
no space left in the UDP reply packet for any "additional info" records,
and its those that contain the A recods corresponding to the NS's.
Hence, you end up with a list of root NS's, but no idea how to
actually reach  any of them.

At this point BIND goes nuts ... one could hope that it would just
send additional queries to the server that replied with the list
of NS's, explicitly asking for A's to match, or perhaps try a TCP
connection to that server and ask for the root NS's again, something...

But as been said before, BIND has many, many, problems.

kre