Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
I’ve mentioned before that there is something special about the .net top level domain - in particular .net is the place where the legacy root DNS servers and most of the TLD servers are to be found. Thus, if .net were to wobble there is more than a strong chance that the DNS root and other TLDs would also begin to wobble. This kind of cross-dependency is something that A) is a risk to overall internet stability and B) is something that ICANN seems utterly unable to perceive.
So I ask this simple question: Why can’t the domain names of the legacy root servers and TLD servers be moved to a new global infrastructure top level domain? Such a new TLD would be intrinsically much more stable than .net. In fact because the size would be small, a new infrastructure-only TLD could be readily cached and replicated, thus providing much more resiliency against attack and could be recovered much more quickly than .net should an attack be successful.
This new TLD should be used only for machines that provide services in support of DNS on a global basis (with the proviso that any server that delivers a TLD zone for any TLD, whether that TLD is ICANN approved or not, should be considered “global infrastructure”.)
For the moment let’s call this new TLD “q8m”, which is a short phrase without any annoying semantics (I hope).
Thus this infrastructure TLD would contain delegations for things like “root-servers.q8m” and “tld-servers.q8m” to replace the existing “root-servers.net” and “tld-servers.net”.
Anyone who wants to establish a group of infrastructure servers would register for a delegation in this this infrastructure TLD. The registration agreement would require that the registrant police the use of the delegation so that the resource records found via that delegation are all present for the exclusive purpose of providing infrastructure services.
In order to discourage spurious thrashing of the contents of this infrastructure TLD there should be a steeply ramped fee schedule for updates. The first 4 per year should be inexpensive ($25) but after that the fee should quickly ramp up to at least $100 per update.
Were this kind of infrastructure TLD to be established, much of the special nature of .net would be eliminated; a failure of .net would not then have the kind of destructive repercussions onto other parts of the internet that is now the case.
—-
Originally published on CaveBear Weblog.
Sponsored byWhoisXML API
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byCSC
Sponsored byRadix
A World-Renowned Source for Internet Developments. Serving Since 2002.
(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.