CircleID

(a) there already is a top-level domain used purely for architecture: it's called ARPA.

(b) priming queries to the root nameservers do not rely on the NET zone; they use a hints file usually shipped with the nameserver software.

(c) glue records exist in the root zone for all the root nameservers, and for all top-level zone nameservers. This means that referrals to names not in the NET domain can proceed without the NET servers being a dependency.

(d) the root nameservers are all authoritative for the zone ROOT-SERVERS.NET, and will return authoritative answers to queries in that zone directly rather than returning a referral to the NET servers.

The NET servers are hence not a dependency for priming queries, for obtaining authoritative answers from the ROOT-SERVERS.NET zone or for referrals to any other top-level zone.

The cross-dependency you identified does not actually exist; the concern about wobbles is unnecessary.

I agree with Joe - this is a solution in search of a problem.

Although, I will say this - I'm not sure ARPA can be considered purely infrastructure anymore with the advent of ENUM.

In any event, .net can go away and the root and TLD servers will work fine.

Good, remove one single point of failure and introduce another - even though the chance for failure is quite less here, as you point out. Add to it the time and headache that pushing through a new TLD involves.

Why not just suggest using a "basket" of TLDs for the root servers so that they're spread across a wider range of TLDs, and a wider range of providers handling these TLDs?

It would be slightly (!) easier for you to push for that.  If you don't remember a few other things like .arpa, root.hints, glue records etc already make your proposal redundant.

[reading further downthread - hmm, Joe Abley beat me to repeating DNS 103, thanks, Joe!]

To Joe Abley:

A. .arpa would make a handy infrastructure top level domain.  There could be some national and cultural difficulties, however, because ARPA refers to a part of the United States Department of Defense.

B. As for the hints files: The hints files are not authoritative, they are merely "hints" to get things bootstrapped.  And the hints files are often quite out of date and serve only to initially locate root servers, not TLD servers.  And it is those TLD servers which are i) the must vulnerable part of the DNS server hierarchy and ii) often found in .net (e.g. *.gtld-servers.net)

C. The glue records that come in root-server responses can i) be inconsistant with the addresses (authoritative and otherwise) provided by a sub-zone (e.g. a TLD) itself that has gone awry and ii) can be incomplete due to the UDP DNS packet size limitation and the introduction of AAAA records into the set of glue records.

D. Although as you point out the legacy root servers are authoritative for root-servers.net they are not authoritative for the parent zone, .net.  So to fully follow an authoritative chain of delegations for the root servers one has to go to the .net servers.  Sure one can, and we usually do, short circuit the chain of referrals.  But doing so risks inconsistencies should the bypassed intermediary (.net) go awry (and say, repoint the delegation.)

I agree with the most of details of your points, but the forest is much more than the individual trees: If every part of the net were composed of code that was up-to-date with all the latest knowledge of how to resolve inconsistencies and errors, then perhaps all might be well without an infrastructre TLD.  But as it stands we are simply going forward blindly, making an assumption that if should inconsistencies appear that all of the software in all of the resolvers will operate well. That, to me, is a great leap of faith.  To my way of thinking it is better to be prudent and avoid, or reduce, the possibility of inconsistency rather than simply dismissing it as not likely to happen in this best of all possible worlds.

I spend most of my time testing the behaviour of network gear in the face of unusual (but often legal) protocol exchanges and other kinds of relatively minor inconsistencies.  From this I have little hope that the net will behave gracefully should some serious inconsistencies arise.

You might be right that there is nothing to fear.  Or I might be right.  The real question is not which one of use is right but rather whether the community of internet users ought to bear the risk of the uncertainty about which of us has the more firmly grounded argument - a bit of prevention, and an infrastructure TLD is certainly an inexpensive and easy bit of prevention, could remove this uncertainty.

To Daniel Golding:

Enum - The idea of regular folks doing regular expressions is something that scares the bejeebers out of me.  Buffer overruns are the security vector of today; wacko regular expressions might be the security vector of the future.

(Fortunately, at least for SIP anyway, I'm not yet seeing people using the reg-ex part of NAPTR records.)

Karl, ".arpa" no longer refers to the original ARPA. During 2000, the abbreviation was redesignated to "Address and Routing Parameter Area". RFC 3172 documents best current practice for this domain.

If there is a problem - and I'm not totally convinced either way without testing some common DNS software and rereading some standards - surely the answer is to put the root servers in the root domain, and thus avoid any delegation issues.

Or is that too scary to contemplate.