[ On Saturday, August 5, 2000 at 06:39:41 (+0800), Mathias K�rber wrote: ]

Subject: RE: g.root-servers.net returns NXDOMAIN for com.

Regardless of whether g.root-servers.net 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 g.root-servers.net 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 g.root-servers.net, 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. g.root-servers.net 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 weird.com. g.root-servers.net weird.com NS record currently not present at g.root-servers.net (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 g.root-servers.net 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. g.root-servers.net 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 g.root-servers.net 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 <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>