Setting aside the motivations for this draft, the idea of removing the one single DNS 'root' is a reasonable one. It acts as a single point of failure for the DNS system and puts the entire DNS hierarchy under the jurisdiction of the United States Department of Commerce. There are already existing alternative roots[1], but no interoperability between them and no standards governing them. Indeed, the IETF is strongly against them at present [2].
With that in mind, let us examine the flaws in the proposal at hand.
* 1. Lettered roots
This proposal puts the existing DNS root under a lettered virtual root above it, with implicit resolution to the local AIP. The existing DNS root locations are ALREADY indexed by letter, so this is a recipe for confusion. Even more importantly, this system _will not scale_: There are 26 possible letters, if drawing from the ASCII set only, which permanently restricts the number of autonomous zones. What happens then?
This could be resolved by using a unique suffix scheme that does not conflict with the existing or requested TLDs, but would make it that much harder to type an external DNS address. yahoo.com.extdomA for general use would be quite unfortunate.
* 2. Who hands out the AIP designations?
If every AIP must have a single unique designation, there must be an organization handing them out. The ICANN would be the obvious choice, but that brings us back around full circle.
* 3. Ownership conflicts
As rfc2826 points out [2], the internet is built on the assumption that domain names are unique. With multiple implicit zones, either the same entity must be able to control their domain within each or we will end up with conflicts. If yahoo.com resolves to the 'Yahoo' corporate entity in most AIDs, but is controlled by Baidu in one, can they claim it? If not, what about the user confusion that would entail?
Regardless of the answer to this question, I expect in an AID world everyone would start using external domains for the stronger guarantees they provide. So Yahoo would be permanently yahoo.com.A. Which is complicated by...
* 4. Blocking.
If AIPs start blocking resolution of specific external domains, what happens? Obviously China would like this, but for the internet at large, having siloed intranets would likely be a huge problem. Every time someone misconfigures BGP and one region of the internet cannot talk to another, things break. A shifting set of resolvable domains would likely cause exactly the same headaches, only they wouldn't go away with the next BGP update.
* 5. Proxying and scale.
The AIP DNS are required to proxy requests to external domains (3.2 from the draft). Presumably this is to facilitate blocking, but it would also impose significant load issues and key bottlenecks. Note that right now the only equivalent is the root DNS, and it only handles resolution for the TLDs. Something far larger would need to be set up to be able to handle the load of proxying all external requests.
Overall, this proposal has far too many foundational issues to be seriously considered. I am personally happy it was drafted - work to break the One True Root should be done in the open with all relevant parties involved. But this draft isn't going to cut it.
Yes and no. There are 13 'installations' (essentially IPs), some anycasted, but they all serve the same contents that are provided by the ICANN. So they are one conceptual root, albeit a geographically distributed one. The IETF has worked hard to make it robust (successfully so far), but the fact remains that 13 hardcoded IPs and one file that comprise the root of the DNS system.
Those 13 IPs aren't as hard coded as you suggest. They typically ship with the DNS server software (ISC bind for example) but these are updated at regular intervals. As long as all 13 IPs aren't changed at once you could quite easily transition from one set of IPs to others. In ISC bind this root "cache" even has its own zone type; "hint".
Thanks, I wasn't aware they changed regularly. From what I can find, 4 v4 IPs have changed since 1997, plus the addition of a number of v6 IPs over the years. I'd be curious to know the last time all IPs were different, if ever.
Of course, it's something we already know what we disagree about. Whereas using another set of names is an additional thing to disagree about on top of the existing things we already disagree about.
At discussion here are the root DNS servers, which are at a higher level in the hierarchy than any of the ccTLD or gTLD domains. We're talking about the (.) level.
e.g. www.google.com.
That trailing dot is never used in a web browser, but it most certainly does exist.
ccTLDs are a great idea, but somewhere around 60% of the top million websites in the world are run off of .com domains; there's no guarantee that a country could block an entire gTLD or ccTLD and successfully limit all questionable content.
I have been wondering how ownership conflicts will work with GTLDs. If someone buy's "lol." and puts up "yahoo.lol.", how is that conflict resolved since "lol." is not managed by a "neutral" company but by the people that in fact own "lol."?
All new gTLDs are required to support the Uniform Dispute Resolution Policy (UDRP), the Uniform Rapid Suspension policy (URS), and the Trademark Clearing House. These policies are in differing stages of development, and in the case of the Trademark Clearing House are not even fully nailed down.
With that in mind, let us examine the flaws in the proposal at hand.
* 1. Lettered roots
This proposal puts the existing DNS root under a lettered virtual root above it, with implicit resolution to the local AIP. The existing DNS root locations are ALREADY indexed by letter, so this is a recipe for confusion. Even more importantly, this system _will not scale_: There are 26 possible letters, if drawing from the ASCII set only, which permanently restricts the number of autonomous zones. What happens then?
This could be resolved by using a unique suffix scheme that does not conflict with the existing or requested TLDs, but would make it that much harder to type an external DNS address. yahoo.com.extdomA for general use would be quite unfortunate.
* 2. Who hands out the AIP designations?
If every AIP must have a single unique designation, there must be an organization handing them out. The ICANN would be the obvious choice, but that brings us back around full circle.
* 3. Ownership conflicts
As rfc2826 points out [2], the internet is built on the assumption that domain names are unique. With multiple implicit zones, either the same entity must be able to control their domain within each or we will end up with conflicts. If yahoo.com resolves to the 'Yahoo' corporate entity in most AIDs, but is controlled by Baidu in one, can they claim it? If not, what about the user confusion that would entail?
Regardless of the answer to this question, I expect in an AID world everyone would start using external domains for the stronger guarantees they provide. So Yahoo would be permanently yahoo.com.A. Which is complicated by...
* 4. Blocking.
If AIPs start blocking resolution of specific external domains, what happens? Obviously China would like this, but for the internet at large, having siloed intranets would likely be a huge problem. Every time someone misconfigures BGP and one region of the internet cannot talk to another, things break. A shifting set of resolvable domains would likely cause exactly the same headaches, only they wouldn't go away with the next BGP update.
* 5. Proxying and scale.
The AIP DNS are required to proxy requests to external domains (3.2 from the draft). Presumably this is to facilitate blocking, but it would also impose significant load issues and key bottlenecks. Note that right now the only equivalent is the root DNS, and it only handles resolution for the TLDs. Something far larger would need to be set up to be able to handle the load of proxying all external requests.
Overall, this proposal has far too many foundational issues to be seriously considered. I am personally happy it was drafted - work to break the One True Root should be done in the open with all relevant parties involved. But this draft isn't going to cut it.
[1] http://en.wikipedia.org/wiki/Alternative_DNS_root [2] http://tools.ietf.org/html/rfc2826 (IAB Technical Comment on the Unique DNS Root)