ICANN/DNSO
DNSO Mailling lists archives

[ga-roots]


<<< Chronological Index >>>    <<< Thread Index >>>

[ga-roots] alternate roots considered harmful



Internet Engineering Task Force                              K. Crispin
Internet-Draft                                                 May 2001
Document: draft-crispin-alt-roots-tlds-00.txt
Expires: November 2001


                          Alt-Roots, Alt-TLDs

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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 root" and "alternate
   TLDs (Top Level Domains)", in an attempt to help clear up
   misunderstandings on their use in the Internet.

   For the past 6 years or so various organizations and individuals have
   implemented "alternate roots" to support their own Top Level Domains
   (TLDs).  Some have gone so far as to argue that alternate roots are
   good for the Internet, and actually enhance stability.  Such a
   position is seriously mistaken, and reflects a serious lack of
   understanding of technical realities involved.  The Domain Name
   System (DNS) is a complicated system that is commonly misunderstood,
   and this paper is an attempt to help clear up these
   misunderstandings.  It is complementary to the IETF's RFC 2826, "IAB
   Statement on the Unique DNS Root", which very clearly states the
   principles involved.





Crispin                  Expires: November 2001                 [Page 1]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


Background

   In this paper 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".  That is, as I use the term, an alternate root by
   definition includes "alternate TLDs (Top Level Domains)", and hence,
   alternate roots and alternate TLDs are really both characteristics of
   the same phenomenon.  Sometimes I use the term "multiple roots", or
   "multiple root regime" to indicate a hypothetical situation where
   several distinct alternate roots exist, and are seeing significant
   use. [Note that the current existing alternate roots, with the
   possible exception of new.net's activities, are not heavily used, and
   consequently our current situation probably does not constitute a
   "multiple root regime".]

        ICANN                 Alt                     Alt
         root                root(E)                 root(F)
          /|\                 /|\                     /|\
         / | \               / | \                   / | \
        /  |  \             /  |  \                 /  |  \
       /   |   \           /   |   \               /   |   \
      /    |    \         /    |    \             /    |    \
    .com............    .com.......  .biz(E)    .com.......  .biz(F)

   In the above diagram, there are three root systems, and all three of
   them support ".com", ".net", and the rest of the "legacy" Top Level
   Domains (TLDs).  But Alt-root(E) [English] and Alt-root(F) [French]
   support different versions of ".biz".  This situation (having the
   same name for two different things) is referred to as a "name
   conflict".  Note that since the DNS is a public system, the managers
   of .biz(E) and .biz(F) could take information from each other, and
   the two .biz's could share a great deal of information as well.

   If a root server provides exactly the same information as some other
   root server, then it is a "replica" of that server, and not an
   "alternate" to it.  This is just a semantic distinction, but it is an
   important one, because replication is a highly desirable thing that
   provides redundancy and reliability, whereas alternate roots/TLDs
   have quite the opposite effect.  Note that if two roots provide the
   same information at the TLD level, then the information must be the
   same throughout the tree.

   Since I believe that the negative characteristics of alternate roots
   are decisive, this document is essentially structured as one long
   reductio ad absurdum argument: frequently, I implicitly postulate
   that multiple roots exist and are in heavy use and that the Internet
   Corporation for Assigned Names and Numbers (ICANN) has somehow
   approved of them, and then show that the consequences are



Crispin                  Expires: November 2001                 [Page 2]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


   undesirable.  That is, I frequently postulate things that I believe
   will simply never happen.

Economics of Name Conflicts

   Name conflicts are generally considered a bad thing.  If company "A"
   uses Alt-Root(E), and company "B" uses Alt-root(F), then "A" and "B"
   will see different versions of .biz.  "A" may put its web page in
   .biz(E), and "B" may put its web page in .biz(F), and neither
   company will see the other's web site.  This may not matter much if
   .biz(E) only supports the English language, and .biz(F) only
   supports the French language, but in general one of the major values
   of the Web is it's universal visibility.

   It has been argued that economic forces will eliminate name conflicts
   in alternate TLDs, and that in time all root servers would converge
   to providing the same information.  This argument, however, is based
   on a very simplistic view of economic reality.  The core argument is
   presented by Karl Auerbach:

      As a general rule, customers of a root server system will act much
      like subscribers to a cable TV system -- they will want as many
      TLDs (or as many channels) as they can get.  This will drive the
      root server system operators to include as many viable TLDs as
      they can into their inventory.

      The net result of all the root system operators following this
      strategy will be that they all attempt to trump one another by
      each including more TLDs.  The end of this is that all root server
      operators will incorporate all viable TLDs.  The benefit of this
      is that the domain names of all people and organizations who have
      registrations in these TLDs will be essentially universally
      resolvable no matter which root server system us being used [1].

   A moments thought about the French/English versions of .biz discussed
   above should make it clear that there are a myriad of factors other
   than pure economics that have effect.  In fact, there has been much
   talk about different countries/linguistic groups forming their own
   TLDs and running them in alternate roots.  These efforts are
   apparently primarily motivated by political and cultural
   considerations, not economic.

   From a purely economic point of view, competing TLDs (and roots)
   would essentially be waging what Shapiro and Varian [2] call a
   "Standards War", where the competitors are seeking to get their
   version of the TLD to be considered as *the* standard.  And, as
   Shapiro and Varian note, there are many possible results of such a
   war -- the protracted battle over cellular phone standards, or HDTV



Crispin                  Expires: November 2001                 [Page 3]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


   standards, clearly indicate that competing standards can fight it
   out for a very long time.  And, as the English/French example above
   indicates, the regionalization that slows the convergence of cellular
   standards, for example, can easily be replicated in DNS.  [Note that
   it would be quite possible for large international companies to
   simply register in both versions of .biz, just as they currently
   register in many ccTLDs.]

   Moreover, Auerbach's belief that root server operators would tend to
   include all TLDs rests on the simplistic assumption that the
   interests of root server operators are distinct from the interests of
   TLD operators.  As the case of new.net illustrates, this is not
   necessarily so: clearly, new.net is not interested in supporting
   other versions of its own TLDs.

   In fact, if multiple roots were somehow blessed by ICANN there is no
   question but that other large and well financed companies could enter
   the market instantly -- Verisign, for example, could announce that it
   was supporting its own versions of some of new.net's TLDs, and quite
   possibly Verisign's reputation, expertise, and established
   distribution channels would quickly destroy whatever lead new.net
   might have, which (frequently the case in Standards Wars) lead to the
   demise of new.net.

   From an economics point of view, it would require enormous resources
   to overcome the network advantages (in the economics sense) enjoyed
   by the ICANN root.  But presuming that a multiple root regime could
   be established, there is no indication whatsoever that it would ever
   converge to a single root zone.  In purely economic terms it is just
   as likely that a multiple root environment lead to large scale and
   protracted name conflicts.

   Here are some concrete examples of possible results of name
   conflicts:

   I.  A business in England, with a web-site in .biz(E), is trying to
       expand their business to France.  The salesman calls the
       prospective client in France and in the conversation says "check
       our web site at xxx.biz for our prices".  However, the French
       company uses .biz(F), and can't access .biz(E).  The French
       company sends email to the English company, reporting the
       problem, but of course the email doesn't arrive.

  II.  A English "Road Warrior" tries to check his email from a
       cybercafe at a conference in France.  ("Road Warriors" are
       individuals that travel extensively, and use their laptops and
       the Internet to keep connected with their work.)  The operator of
       the cybercafe, being a patriot, uses .biz(F), so the Road Warrior



Crispin                  Expires: November 2001                 [Page 4]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


       can't check his mail.

 III.  There is another issue with email -- intermediate servers are
       used to transport the mail.  So email delivery may fail because
       an intermediate server uses a different root system.  More
       insidiously, the path email takes through the network is not
       fixed, and a secondary path may be taken if there is a problem on
       the primary path.  So, sometimes the mail would be delivered, and
       sometimes the message would be returned with an error saying that
       the address did not exist.  And indeed, sometimes the email could
       be delivered, but to a different person than the intended one.

  IV.  The "intermediate node" problem mentioned above for email is far
       more common than people realize.  It can be illustrated by a
       common service on the Internet, "ping" pages.  A "ping" page is a
       web page that allows you to type in a domain name or network
       address, and the server will see if it can reach the specified
       site.  This can be very useful in network debugging -- site
       a.b.com is not reachable from your location, but you access a
       remote "ping" page, and discover that the site *is* reachable
       from an external site.  Of course, in our multiple root scenario,
       if you specify "a.b.biz", you really don't know if you are
       reaching the site you mean to reach.  Network engineers are
       comfortable with raw IP addresses, but sometimes you don't get
       the IP address -- you may just have a trouble ticket entry with a
       domain name in it.

   V.  Trouble tickets aren't that familiar, but online orders certainly
       are.  In almost all cases, the confirmation for the order is sent
       back via email, and consequently the online order form almost
       always asks you for your email address.  But if your email
       address is jax@xxx.biz, and the place where from which you order
       uses a different .biz, then you will never receive your
       confirmation.

  VI.  The above scenarios all express what we might call "inconsistency
       due to location" -- the result you get for a domain name lookup
       depends on the location in cyberspace from which you made the
       request.

       But when you think about it, "location in cyberspace" is almost
       meaningless -- two computers in the same room can have vastly
       different locations in cyberspace.  In fact, DNS largely defines
       what most of us mean by "location in cyberspace", and
       consequently, name conflicts undermine our most basic
       navigational tool.





Crispin                  Expires: November 2001                 [Page 5]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


 VII.  Finally, "inconsistencies due to location" are only a part of the
       problem.  Another very significant issue revolves around what we
       might call "inconsistencies due to timing".  This was hinted at
       above in the case where an intermediate mail transport server
       fails and another takes over -- where your mail goes depends on
       *when* it was sent, relative to the time of the server failure.
       In a multiple root regime, the pattern of DNS lookups over time,
       independent of any other factor, can cause you to get different
       results.  How this can happen is complicated, and will be
       explained in much greater detail below.  But this factor
       interacts with all the above scenarios, and adds an element of
       complete non-determinism.

Interlude on the Significance of Design Goals

   The above discussion of name conflicts underscores a fundamental
   point: DNS wasn't designed to deal with name conflicts.

   In fact, 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.

   Providing unique and stable names for millions of objects requires
   that there be millions of unique names available, and managing
   millions of unique names is a large job.  The most basic management
   task is "registration": the assignment of names to the objects that
   they name.  In practice, registration also involves the
   identification of an associated party who is responsible 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.






Crispin                  Expires: November 2001                 [Page 6]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


   It is important to realize, however, that while the names are
   structured (and the registration is distributed), the fundamental
   purpose of DNS is still to provide unique, stable names, and that the
   entire obscure and complex technical design of DNS supports this
   fundamental purpose.

   Now consider for a moment the design of a lawn-mower.

   Power lawn-mowers are devices that are designed to cut the grass in a
   lawn to a uniform height.  They typically have sharp spinning blades
   that rotate parallel to the ground, blades that spin fast enough so
   that the grass is cut, rather than pushed aside.

   All the decisions in the design of a lawn-mower are made with that
   particular task in mind, and over time the design has evolved to a
   high degree of complexity.  For example, the spinning blades also act
   as a fan, and the shape of the blade housing is carefully designed to
   confine the airflow produced by the blades.  The *intended*
   consequence of this design is for the airflow to carry the grass
   clippings up and into a collection bag.

   In an interesting case from product liability law, the plaintiff
   attempted to use his lawn mower as a hedge trimmer, and some of his
   fingers were cut off.  Thus, an *unintended* consequence of the
   design of the blade housing is that there isn't room for fingers
   between the blade housing and the blades.

   The defendant, the manufacturer of the mower, argued that the lawn-
   mower was perfectly safe when used as designed, that clearly a lawn
   mower is not designed to be used as a hedge trimmer, and that use of
   a product in a manner for which it is not designed is likely to cause
   all kinds of unanticipated problems.

   This example illustrates an important general principle: a design has
   high level goals, and design decisions are made to fit those high
   level goals.  Those design decisions may have unintended
   consequences, if the end product is used in a way not consistent with
   the original goals.  If the design is very complicated, with many
   internal decisions, it may be *very* difficult to predict the
   consequences of misuse of the end product.  Certainly the individual
   in question did not predict that his fingers would be amputated.

   As mentioned above, the fundamental goal of DNS is a single unified
   name space, and intrinsic to that design is the assumption that there
   is a single root zone.  DNS is a complicated protocol, and use of
   multiple root zones was not and is not a design goal of the DNS.
   Consequently, it is simply not possible to predict all the problems
   may result from use of multiple root zones.



Crispin                  Expires: November 2001                 [Page 7]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


   Moreover, DNS as currently deployed is an enormous system, and it
   provides infrastructure that is absolutely critical to the operation
   of the Internet.  Operations on such a large scale must be considered
   in a different light than operations on the small.  Hooking up tiny
   alternate root zones with essentially no traffic tells us very little
   about how such a system would work on a large scale -- peddling a
   tricycle around in a circle on a schoolyard doesn't give much useful
   information about how to operate a super-highway.

More Serious Problems

   With all the above as preliminary, we may now get to more complex and
   serious issues.  Alt-roots don't just have the potential for creating
   static name conflicts, they have the potential for creating far more
   serious instabilities in the name space.  Problems in this category
   are unfortunately complex to describe, and require a bit of
   explanation before diving off into the complicated stuff.

   Here's a diagram of our English/French example:

              Alt                     Alt
             root(E)                 root(F)
              /|\                     /|\
             / | \                   / | \
            /  |  \                 /  |  \
           /   |   \               /   |   \
          /    |    \             /    |    \
        .com.......  .biz(E)    .com.......  .biz(F)

   We presume that the English alternate root is located in London, and
   the French alternate root is located in Paris.  The users of each
   root system are located in their respective countries.  We assume
   that the two .biz's are well used, and further that there are
   overlaps in the name space -- "xxx.biz(E)" and "xxx.biz(F)", or
   perhaps large companies register the same name in each domain, and
   provide web-sites with different content for each country:
   "ibm.biz(E)" and "ibm.biz(F)".

   An almost universal assumption in this scenario is that users of
   alt-root(E) would resolve names from .biz(E), and that users of alt-
   root(F) would resolve names from .biz(F).  This assumption, however,
   is incorrect.  The two root systems share .com, .net, and the rest of
   the 240 or so "legacy" TLDs, and the DNS protocol, *by design*,
   passes information that allows leakage of other data between the two
   root systems.  Basically, after some period of time, users of either
   root system will potentially get information from the other one, on a
   totally unpredictable basis.  One day an English user may get the
   French xxx.biz, and on the next day he might get the English xxx.biz.



Crispin                  Expires: November 2001                 [Page 8]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


   The next section goes through a rather complete explanation.  It must
   be remembered, however, that this is only one of many possible
   scenarios.  Also, all these possible scenarios interact with the
   common name conflicts mentioned above.  And recall the man who lost
   his fingers: we can't know all the possible problems with multiple
   roots.

Detailed example

   As above, we have two root zones, each with its own version of a TLD.
   All other TLDs in these root zones are the same, including the in-
   addr.arpa zone. The two versions of .biz are ".biz(E)" and ".biz(F)".

   Suppose that each version of .biz has a well-known popular SLD, run
   by entrepreneurs unafraid of controversy, e.g., "sex".  So we have
   sex.biz(E) and sex.biz(F), in the subtrees from their respective root
   zones.  Since the "sex" name is very valuable as an SLD, it is quite
   reasonable to assume that someone would leap at the chance to
   register it wherever it became available.  We could also assume that
   the two versions of sex.biz would be in a fiercely competitive
   economic relationship.

   Suppose further that sex.biz(E) has IP address 1.2.3.4, and
   sex.biz(F) has IP address 4.3.2.1.  Assume that the inverse lookup is
   correctly configured in both cases.  (Normal DNS lookup maps a domain
   name to an Internet address -- looking up sex.biz would return
   1.2.3.4, in root(E). Inverse DNS lookup starts with the Internet
   address -- 1.2.3.4 -- and returns the associated domain name.)  This
   means that if one looks up the address 1.2.3.4 one will get
   "sex.biz", and if one looks up the address 4.3.2.1, one will also get
   "sex.biz".  Inverse addresses are maintained in DNS in a special SLD,
   "in-addr.arpa".  So far, we have a structure like this:

       .biz(E)         .biz(F)          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

                           Fig. 1

   This structure is maintained by DNS nameservers, which are also
   identified by DNS names and IP addresses.  It is a quite common
   convention for a nameserver for an SLD to have a name like
   "ns1.SLD.TLD".  In our example, then, it would be quite reasonable
   that a nameserver for sex.biz(E) would be "ns1.sex.biz(E)", and that



Crispin                  Expires: November 2001                 [Page 9]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


   a nameserver for sex.biz(F) would be "ns1.sex.biz(F)".  The IP
   addresses for these machines might be 1.2.3.5 and 4.3.2.2,
   respectively.  Note that the name "ns1" is part of the .sex.biz
   subtree.  We now have the following diagram:


       .biz(E)         .biz(F)          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


                           Fig. 2

   I should stress that all of this (except for the multiple roots, of
   course) is completely standard, and that the conventional name "ns1"
   for a nameserver is *extremely* common.  Moreover, the nameservers
   for "sex.biz" will carry records for all the names in the sex.biz
   domain.

   One final bit of information is necessary to complete the scenario:
   the information stored for every domain name also includes references
   to the address of the name servers for that domain.

   The critical point is that the reply to DNS queries routinely return
   the name and address of the name servers involved.  That is, in our
   example, if one were to look up the address "4.3.2.1", one would get
   back "sex.biz", *and* that the nameserver for 1.2.3.4.in-addr.arpa
   was "ns1.sex.biz", *and* (most important) that the address of
   "ns1.sex.biz" was 4.3.2.2.

   This last bit of information is the source of the problem.  DNS has
   just returned the address of "ns1.sex.biz" as 4.3.2.2, and there is
   no indication of *which* sex.biz is involved.  The information will
   be cached on your local computer, and will be used whenever the
   computer needs to know the address of ns1.sex.biz.








Crispin                  Expires: November 2001                [Page 10]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


   Three further points:

   1) there are all kinds of automatic processes that do inverse lookups
      -- when a packet arrives at a computer, it is only identified by
      the IP address, and if it is desirable to to know the name of the
      machine that was the source of the packet (for logging purposes,
      say), an inverse query is necessary;

   2) inverse lookups aren't the only thing that can cause this to
      happen -- nameserver information is returned as part of many
      queries.

   3) The discussion has been greatly simplified from the real case.
      There are numerous conditions that affect when a cache entry is
      replaced -- timing, type of query, authoritative vs non-
      authoritative answers, software, software version, etc -- and
      there is no simple rule predicting what will happen.  (*) This
      non-deterministic behavior, of course, is just further
      instability.

   Note that in a competitive situation, the owners of the respective
   sex.biz domains could contrive their own scenarios to switch
   nameservers.  That is, the above scenario assumes accidental
   confusion, but there might very well be economic incentive to create
   deliberate confusion.

Conclusion

   There are a wide variety of situations associated with alternate TLDs
   that can cause instabilities; they are all fairly complex.  This is
   why they aren't much of an issue when there are only a few people
   using alternate TLDs.  But wide scale deployment of alternate
   roots/TLDs open up possibilities for destructive and subtle problems.

Security Considersations

   This memo does not introduce any new security issues, but it does
   attempt to clear up misunderstandings on the use of "alternate root"
   and "alternate TLDs" in the Internet.












Crispin                  Expires: November 2001                [Page 11]

Internet-Draft            Alt-Roots, Alt-TLDs                   May 2001


References

   [1] http://www.cavebear.com/cavebear/growl/issue_2.htm#multiple_roots

   [2] "Information Rules: a Strategic Guide to the Network Economy", by
       Carl Shapiro and Hal Varian, Harvard Business School Press, 1999

   [3] More recent versions of BIND have been more resistant to casual
       cache replacement.  It should be stressed that DNS is a *very*
       much more complicated protocol than it appears, and there are
       multiple implementations of DNS servers.  The above scenario
       works with widely deployed versions of current software, but may
       behave differently with different versions or less commonly used
       software.

Author's Address

   Kent Crispin

   EMail: kent@songbird.com































Crispin                  Expires: November 2001                [Page 12]


-- 
Kent Crispin                               "Be good, and you will be
kent@songbird.com                           lonesome." -- Mark Twain
--
This message was passed to you via the ga-roots@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-roots" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>