[Background on alt roots: http://www.politechbot.com/p-01521.html] --- http://www.simon.higgs.com/net/draft-higgs-virtual-root-recent.txt Internet Engineering Task Force S. Higgs Internet-Draft May 2001 Category: Informational Expires: November 2001 Document: draft-higgs-virtual-root-00.txt Alternative Roots and the Virtual Inclusive Root Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This Internet Draft discusses the "alternate roots" and the "virtual inclusive root", in an attempt to help clear up misunderstandings on their use in the Internet. This document solves the problem of duplicate colliding top level domains by identifying the "virtual inclusive root", in compliance with the IAB's RFC 2826, "IAB Statement on the Unique DNS Root"[1]. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119[2]. Background For the past 6 years or so various organizations and individuals have implemented "alternate roots" to support their own Top Level Domains (TLD)s[3]. The origin of these alternative roots can be found in the rough consensus and running code behind Draft Postel[4] (which was subverted by the gTLD-MOU, which itself was terminated upon intervention by the U.S. Government). That ICANN (the replacement process set in place by the U.S. Government) has since failed to run with the ball has only caused more alternative roots to spring up. I define the term "alternate root" to mean "a DNS root zone connected to the Internet, but with contents that differ from the ICANN roots". An alternate root by definition includes "alternate top level domains (TLDs)". This is perfectly acceptable, and one example is RFC 2606 / BCP32[5] which shows how to create localized TLDs from the reserved TLD pool. Impact Of Alternative Roots In DNS The following examples show the impact to the DNS from a multiple root zone environment. It should be noted that each root zone, as a singular entity, is fully compliant with RFC2826. The problems described in RFC2826 surface when the user has no ability to determine which root zone is being used for a particular transaction. Each example also is marked as "STABILIZING" or "DESTABILIZING". This is an important concept to grasp. The primary fallacy that must be overcome is contained in the following set of statements: "If a non-ICANN root service mounts a new TLD without ICANN permission, this is defined to be destablizing." and "If ICANN corrects this situation by adding a conflicting TLD to the ICANN ROOT, this is defined to be stabilizing." There's no other way to say this: THE ABOVE STATEMENTS ARE WRONG! The fact is that there is no conflict and no harm to the internet until the 2nd version of a given TLD (the duplicate) is created. In order to remedy this, the correct statements are as follows: 1. If any root service mounts a new TLD which does not conflict with a pre-existing TLD, this SHOULD be defined as stabilizing. 2. If any root service mounts a new TLD which conflicts with a pre-exisitng TLD, this SHOULD be defined as destabilizing. Therefore, any new TLD which conflicts with a pre-existing TLD is destabilizing, no matter where it comes from. The following examples illustrate which is correct, and which is not correct: Example 1 (STABILIZING): ICANN Alt root root /|\ /|\ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ .com............ .com....... .biz Example 1 does not create any TLD conflicts. The Alternate Root, has been enhanced by the inclusion of the .biz TLD. Both roots use the legacy root, now maintained by the US Government (ICANN root), as the baseline. Example 2 (STABILIZING): ICANN Alt Alt root root(A) root(B) /|\ /|\ /|\ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ .com............ .com....... .biz(A) .com....... .biz(A) Example 2 does not create any TLD conflicts. Both Alternate Root A and Alternative Root B have been enhanced by the inclusion of the .biz(A) TLD. The important thing to note is that the same .biz TLD is supported by both Alternative Roots. All roots use the legacy root, now maintained by the US Government (ICANN root), as the baseline. Example 3 (DESTABILIZING): ICANN Alt Alt root root(A) root(B) /|\ /|\ /|\ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ .com............ .com....... .biz(A) .com....... .biz(B) Example 3 creates a TLD conflict. Both Alternate Root A and Alternative Root B have .biz TLDs, but these TLDs are not coordinated, or peered, and therefore duplicate zones may exist. Note that all roots use the legacy root, now maintained by the US Government (ICANN root), as the baseline. Example 4 (DESTABILIZING): ICANN Alt Alt root root(A) root(B) /|\ /|\ /|\ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ .com........biz(C) .com....... .biz(A) .com....... .biz(A) Example 4 creates a TLD conflict. Both Alternate Root A and Alternative Root B have been enhanced by the inclusion of the .biz(A) TLD. These .biz TLDs are coordinated (or peered) and are conflict free. Adding a different .biz(C) TLD to the ICANN root causes a conflict, and therefore duplicate zones may exist. Note that all roots use the legacy root, now maintained by the US Government (ICANN root), as the baseline. As you can see, this example causes a bigger (META) problem, in that it changes the supported baseline of TLDs that all the other roots are supposed to recognize. Alternate Roots do in fact exist. No one can prevent them from existing, because the selection of a root zone to point to is a voluntary act by DNS name server administrators and end-user client software. Name Conflicts Name conflicts are generally considered a bad thing. If company "A" uses the ICANN Root, and company "B" uses an Alternative Root, then "A" and "B" will see identical versions of all the TLDs that both roots support (such as .COM). Company "B" will also benefit from the additional TLDs visible from the Alternative Root. So far, so good. The problems arise when two roots do not support the same TLD manager for a given TLD. As identified in RFC1591: The designated manager must be equitable to all groups in the domain that request domain names. and Significantly interested parties in the domain should agree that the designated manager is the appropriate party. Obviously, if there is a disagreement, it is possible to create a duplicate TLD, in a different root, and managed by a different party. This will lead to the inevitable delegation of duplicate domain names (and thus create the name conflicts). Disagreements are caused by a number of factors. Lack of entry into a particular root zone is currently the primary cause of new root zones (the Alternative Roots) being created. So what happens when a duplicate domain name is created? Quite simply, a number of things in the DNS break. These breakages happen in all the root systems, including those roots that don't support either version of the conflicting TLD. The first visible sign will simply be the domain names resolving to different IP addresses depending on which root zone is being supported. Company "A" may put its web page in .biz(A), and Company "B" may put its web page in .biz(C). Internet users will only be able to reach Company "A" by using root zones supporting the .biz(A) TLD, and Company "B" by using root zones supporting the .biz(C) TLD. The second visible sign will be email failures. Internet users can send a message to a userat_private, but there can be two separate sets of recipient mail servers for example.biz depending on which root zone is used (.biz(A) or .biz(C)). To complicate this further, each intermediary mail server that the message is routed through, will only pass the message on to the .biz mail server from the root that it resolves. It's quite possible that a message sent within a particular root zone could "leak out" of that root zone via an intermediary server that supports a different root zone. Lastly, as soon as the email path finds a non-supporting mail server, the message is bounced. The third visible sign (see Example 5) is the most deadly. DNS nameserver (NS) record pollution. This is where the NS name records for a domain name are identical, but resolve to different IP addresses depending upon which root zone is queried. With the caching effect of the DNS, an NS record from one root zone may become cached in a nameserver from a different root zone. Any subsequent queries will point to the server for the domain name in the other root zone. Example 5: .biz(A) .biz(B) in-addr.arpa /|\ /|\ /|\ / | \ / | \ / | \ .. | .. .. | .. / | \ | | / .. 1.2.3.4->sex.biz sex->1.2.3.4 sex->4.3.2.1 / /|\ /|\ 4.3.2.1->sex.biz / | \ / | \ .. | .. .. | .. | | ns1->1.2.3.5 ns1->4.3.2.2 Eventually, these problems will become magnified as more duplicate domain names are created. To solve this, we create a meta level solution, called the "virtual inclusive root". Virtual Inclusive Root The above discussion of name conflicts underscores a fundamental point: DNS wasn't designed to deal with name conflicts. The fundamental design goal of the DNS is to provide unique and stable names for certain resources on the Internet. A "resource" may be, for example, an IP address (or, in some cases, a group of IP addresses), an email server, or a portion of the Domain Name Space itself. The resources are represented by objects in DNS; the fundamental service provided by the DNS is retrieval of an object, given the name for the object. The names provided by the DNS are structured in a hierarchical manner, which allows the management of the names to be distributed. Instead of a single gigantic name registry, the registration of names can be spread across many registries. The visible DNS hierarchy starts with what are called "Top Level Domains" (TLDs). The next level of the hierarchy is made up of "Second Level Domains" (SLDs), the level are "Third Level Domains" (3LDs), and so on. The familiar ".com" is a TLD, "example.com" is a SLD, "an.example.com" is a 3LD. "this.is.an.example.com" would be a domain name with 5 levels. So how do we do that if there is more that one root zone? The answer is the Virtual Inclusive Root. It's nothing more than applying RFC2826 to create a larger, virtual, root zone comprised of the sum of all the variations of local root zones. Example 6: ICANN Alt Alt root root(A) root(B) /|\ /|\ /|\ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ .com(A)... .net .com(A).... .biz .com(A).... .web From the above example (Example 6), the Virtual Inclusive Root would consist of the .COM, .NET, .BIZ, and .WEB TLDs (all roots support the same .COM TLD). The Virtual Inclusive Root can be considered the best view of consensus and co-operation for the DNS name space. Co-ordinating The Virtual Inclusive Root Obviously, conflicting TLDs cannot be supported in the Virtual Inclusive Root. The first basic rule of domain name registration is that the first eligible applicant to register a domain name receives the exclusive delegation of that domain name. This is traditionally known as "first come, first served" (FCFS). The second basic rule, as identified in the examples above, is that there is no harm done to internet until a duplicate top level domain is created. Users may not be able to resolve a domain name that exists in a top level domain from a different root zone. But this is no different to today, and does not break the DNS overall. Adding the TLD to the Virtual Inclusive Root solves this problem. The third basic rule is that there is no limit to the number of top level domains that can be put in the DNS. The DNS is recursive and the recent examples of several million domain names registered in .COM shows that this is possible. The reality is that the demand for TLDs is not that high. The main objection to the virtual inclusive root is that it really only raises the root zone up a level and that someone, somewhere, has the job of managing it. This is not true, as the ICANN root zone being a "single point of failure" on the Internet is the problem that the Alternative Roots have already solved. The Virtual Inclusive Root is the sum of the consensus between all root zones on the public internet. The methods for allowing DNS clients and resolvers to resolve Virtual Inclusive Root will be described in a different document. Other Considerations The United States Patent and Trademark Office has determined that top level domains are not trademarkable. This removes any possibility of "sunrise" claims or other trademark claims to top level domains. If ICANN "endorses" other roots, then it would of course coordinate its TLD selections with them, and there would be fewer, if any, name collisions. This is by far the most pain-free solution. If ICANN doesn't "endorse" other roots, then it will most likely create TLDs that conflict with ones publicly in use by Alternate Root servers (see Example 4 above). This sets precedents directly opposed to the IETF tradition of "rough consensus and running code". It allows the pioneer work of developers and entrepreneurs to be taken away at the whim of others. ICANN could also try to make it illegal to run an alternate root. This would involve regulating the configuration of every computer connected to the Internet, and defining what technology and service provider everyone had to use. It would be like a law dictating that everyone had to use the same government approved computer operating system to avoid "instability." The FCFS method of registration has recently been co-opted by ICANN for financial gain, by the registry/registrar community (there is a major kick-back in fees paid to ICANN by the registries and registrars) for the benefit of the intellectual property community (who are paid to secure domain names). The internet user community is the loser, paying several times over just to secure a single domain name. The Alternative Roots exist, at the behest of the internet user community, to bypass this kind of profiteering. Security Considerations This memo does not introduce any new security issues. This memo does not address DNSSec issues. Acknowledgments The author would like to thank Karl Auerbach, Scott Bradner, Milton Mueller, Brian Reid, Richard Sexton, and Einar Stefferud for their constructive comments. References 1 Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Postel, J., "The IANA's File of iTLD Requests", http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html 4 Postel, J., "New Registries and the Delegation of International Top Level Domains" http://www.newdom.com/archive/draft-postel-iana-itld-admin-02.txt 5 D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", BCP32, RFC 2606, June 1999 Author's Address Simon Higgs Higgs Communications P.O. Box 4519 Sunland, CA 91041-4519 Phone: 818-352-3208 Fax: 818-352-0030 Email: simonat_private ### ------------------------------------------------------------------------- POLITECH -- Declan McCullagh's politics and technology mailing list You may redistribute this message freely if you include this notice. To subscribe, visit http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ -------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Tue May 29 2001 - 07:59:22 PDT