FC: Alternate roots for domain names explained in IETF draft

From: Declan McCullagh (declanat_private)
Date: Tue May 29 2001 - 07:32:02 PDT

  • Next message: Declan McCullagh: "FC: Annoy.com republishes SSNs in article, Kirkland mirrors pop up"

    [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