North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: returns NXDOMAIN for com.

  • From: Greg A. Woods
  • Date: Fri Aug 04 20:55:01 2000

[ On Saturday, August 5, 2000 at 06:39:41 (+0800), Mathias Körber wrote: ]
> Subject: RE: returns NXDOMAIN for com.
> Regardless of whether has .com delegation pointing
> to it, it is still listed as a root-server (in most users's hints file
> and I think even in the current one).
> So people *will* ask it for any- and everything and should get proper answers.

No, only really broken resolvers, or people who don't quite know what
they're doing, or people who are trying to catch it off guard, will ask
it for anything but NS (and maybe SOA) records for the root zone or the
top level zones.

> A client cannot know that is not delegated .com until it has
> asked one of the root-servers (assuming it had no cached knowledge),
> and it it happened to ask, it will be told that the whole
> .com hierarchy does not exist...

Ah, no, that's not what will happen now; and it is not happening *now*:

	$ host -r -t ns com.
	com                     NS      F.ROOT-SERVERS.NET
	com                     NS      J.GTLD-SERVERS.NET
	com                     NS      K.GTLD-SERVERS.NET
	com                     NS      A.GTLD-SERVERS.NET
	com                     NS      M.GTLD-SERVERS.NET
	com                     NS      G.GTLD-SERVERS.NET
	com                     NS      C.GTLD-SERVERS.NET
	com                     NS      I.GTLD-SERVERS.NET
	com                     NS      B.GTLD-SERVERS.NET
	com                     NS      A.ROOT-SERVERS.NET
	com                     NS      E.GTLD-SERVERS.NET
	com                     NS      F.GTLD-SERVERS.NET

	$ host -r -t ns NS record currently not present at

(i.e. it knows it is not authoritative for my zone and it is not
returning a mistaken authoritative NXDOMAIN)

BTW, I think the only way you should get an authoritative NXDOMAIN
domain for a top-level zone from a BIND-based nameserver is if that
nameserver were authoritiative for the parent zone, *and* the parent
(i.e. root) zone itself contained *no* data for the top-level zone in
question.  While the former is supposed to be true for at all times, the latter was only true for a short
period of time while they futzed with it trying to make it continue to
do something that it apparently did not want to do.  This *may* indicate
a bug in BIND-8 -- I don't know for sure.

> The .com delegation is irrelevant in thiscase. is broken
> right now and should be fixed or shut down until it is.

At the moment it is not broken in any way that I can discern.  It has a
"lame" delegation of .COM, .ORG, and .NET from the point of view of some
nameservers out there in the world.  This is indeed the best solution to
the problem (and in fact the previous attempts to continue to try and
load the zone when there were known problems were what was wrong wrong
and that's what ended up causing people problems).  Shutting it down
completely and abrubtly would cause more delays to a portion of the
average DNS queries than is necessary.  So long as it can continue to
reliably serve the zones that are currently delegated to it, it should
stay up and running and simply be left "lame" for COM/ORG/NET.

Assuming this isn't a spoofed reply, it may give some indication as to
the source of the problems it had though:

	$ host -t txt -c ch version.bind
	VERSION.BIND            TXT     "8.1.2-P2"

The lesson learned here should be that if you operate *any*
authoritiative nameserver, you will pull the public network cable to it
immediately if you suspect it is answering incorrectly for domains it
should know about (be they delegations from a parent zone or zone it
should have loaded itself) and that it not be plugged in again until it
is guaranteed to be answering correctly, *and* that it be monitored most
closely until it can be shown that it still answers all queries
correctly under real-world load.  If it cannot answer only for a few of
its zones then it should be made lame for those zones such that it can
continue to serve queries for other zones with which there are no
problems.  I thought previous incidents would have taught these lessons
to everyone by now, but it seems not.  If this kind of thing happens for
top level zones with very experienced operators who have most of the
world's eyes staring down on them, you can just imagine how often it
happens to many piddly second level domains and even more 3rd and so on! 

Perhaps a good project that would assist in these situations would be to
write a sniffer tool that could look for authoritative NXDOMAIN replies
and compare them to a list of known zones to see if any incorrect
answers are flying by on the wire out to unsuspecting clients.  It
shouldn't be too hard to munge something like this together from the
source of tcpdump in fact....

							Greg A. Woods

+1 416 218-0098      VE3TCP      <[email protected]>      <robohack!woods>
Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>