Network Working Group                                           T. Lemon
Internet-Draft                                             Nominum, Inc.
Intended status: Informational                                  R. Droms
Expires: March 20, 2017                                      Cisco, Inc.
                                                               W. Kumari
                                                                  Google
                                                      September 16, 2016


                  Special-Use Names Problem Statement
                         draft-tldr-sutld-ps-04

Abstract

   The Special-Use Domain Names registration policy in RFC 6761 has been
   shown through experience to present unanticipated challenges.  This
   memo presents a list, intended to be comprehensive, of the problems
   that have been identified.  In addition it reviews the history of
   Domain Names and summarizes current IETF publications and some
   publications from other standards organizations relating to special-
   use domain names.

   [ Ed note: John Levine suggested we use 'Domain Names' instead of
   'Internet Names'; this is the only change between -03 and -04.
   Please let us know which term you prefer. ]

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on March 20, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Lemon, et al.            Expires March 20, 2017                 [Page 1]


Internet-Draft          Special-Use Names Problem         September 2016


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problems associated with Special-Use Internet Names . . . . .   3
   4.  Existing Practice Regarding SUINs . . . . . . . . . . . . . .   6
     4.1.  Primary SUIN Documents  . . . . . . . . . . . . . . . . .   6
       4.1.1.  IAB Technical Comment on the Unique DNS Root  . . . .   6
       4.1.2.  Special-Use Domain Names  . . . . . . . . . . . . . .   7
       4.1.3.  MoU Concerning the Technical Work of the IANA . . . .   9
     4.2.  Secondary documents relating to the SUTLIN question . . .  10
       4.2.1.  Multicast DNS . . . . . . . . . . . . . . . . . . . .  10
       4.2.2.  The .onion Special-Use TLD  . . . . . . . . . . . . .  11
       4.2.3.  Locally Served DNS Zones  . . . . . . . . . . . . . .  11
       4.2.4.  Name Collision in the DNS . . . . . . . . . . . . . .  11
       4.2.5.  Discovery of the IPv6 Prefix Used for IPv6 Address
               Synthesis . . . . . . . . . . . . . . . . . . . . . .  12
       4.2.6.  Additional Reserved Top Level Domains . . . . . . . .  12
     4.3.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  12
   5.  History . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  14
   Appendix A.  Change Log.  . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   One of the key services required to use the Internet is name
   resolution.  Name resolution is the process of translating a human-
   readable symbolic name into some object or set of objects to which
   the name refers, most typically one or more IP addresses.  These
   names are often referred to as domain names.  When reading this
   document, care must be taken to not assume that the term Domain Name
   implies the particular protocol for resolving these names, the Domain
   Name System [RFC1034].  An excellent presentation on this topic can
   be found in Domain Names [I-D.lewis-domain-names].





Lemon, et al.            Expires March 20, 2017                 [Page 2]


Internet-Draft          Special-Use Names Problem         September 2016


   At the time of this writing, the IETF has recently been asked to
   allocate several new special-use top-level Domain Names.  In
   evaluating the process for additional special-use top-level Domain
   Names as documented in Special-Use Domain Names [RFC6761], the IETF
   encountered several different sorts of issues.  Because of this, the
   IETF has decided to investigate the problem and decide if and how the
   RFC 6761 process can be improved, or whether it should be deprecated.

   This document presents a list, believed to be complete, of the
   problems associated with the allocation of special-use names.  In
   support of the particular set of problems described here, the
   document also includes documentation of existing practice as it
   relates to the use of Domain Names, as well as a brief history of
   domain names, and finally to describe the set of problems that exist
   as reported by various IETF participants with experience in the
   various aspects of the problem.

2.  Terminology

   For the sake of brevity this document uses a number of abbreviations.
   These are expanded here:

   Domain Name  A name which serves as input to a host's ordinary name
      resolution process, for example 'EXAMPLE.ORG'.

   SUDN  Special Use Domain Name

   SUTLDN  Special-Use Top-Level Domain Name

   IANA  Internet Assigned Numbers Authority

   ICANN  Internet Corporation for Assigned Names and Numbers

3.  Problems associated with Special-Use Internet Names

   This section presents a list of problems that have been identified
   with respect to the allocation of special-use names.  Solutions to
   these problems are out of scope.  Because of that, problems with
   solutions to these problems are also out of scope, and will be
   covered in a separate document.

   No assertion is made that any of these problems is more or less
   important than any other.  The point of this is simply to enumerate
   and briefly describe the problems that have been raised during
   discussions of the special-use name problem.  The degree of detail is
   intended to be sufficient that that participants in the discussion
   can agree that the problems they've raised have been adequately
   described, and no more.



Lemon, et al.            Expires March 20, 2017                 [Page 3]


Internet-Draft          Special-Use Names Problem         September 2016


   In addition, no assertion is made that all of these problems must be
   addressed; while each problem has one or more solutions, the
   solutions may in some cases be mutually contradictory, or may come
   with costs that do not justify the benefit that would be obtained
   from solving them.

   This is the list of problems:

   o  IETF and ICANN independently have remit to assign names out of the
      namespace that Domain Names represent; a formal coordination
      process does not exist.

   o  Although IETF and ICANN nominally have authority over this
      namespace, neither organization can enforce that authority over
      any third party who wants to just start using a subset of the
      namespace.  Reasons for doing this may include:

      *  Unaware that a process exists for allocating such names

      *  Intended use is covered by gTLD allocation, but no gTLD
         allocation is ongoing

      *  Intended use is covered by gTLD allocation, don't want to pay
         fee

      *  Intended use is covered by some IETF process, but don't want to
         follow process

      *  Intended use is covered by ICANN or IETF process, but expected
         outcome is refusal

   o  There is demand for more than one name resolution protocol for
      Domain Names, but Domain Names contain no metadata to indicate
      which protocol to use to resolve them.

   o  When a top-level name is used as a means either of marking the
      rest of a Domain Name for resolution using a protocol other than
      DNS, or is used for resolution of names with no global meaning,
      not all software that processes such names will understand the
      names' special meanings.  Consequently, any such use results in
      queries for those names being sent to authoritative servers.

   o  The RFC6761 process is sufficiently uncertain that some protocol
      developers have assumed they could not get a name assigned; the
      process of assigning the first new name following RFC 6761 took
      more than ten years from beginning to end: longer by a factor of
      ten than any other part of the protocol development process.
      Other uses of the process have proceeded more smoothly, but there



Lemon, et al.            Expires March 20, 2017                 [Page 4]


Internet-Draft          Special-Use Names Problem         September 2016


      is a reasonably justified perception that using this process is
      likely to be slow and difficult, with an uncertain outcome.

   o  There is strong resistance within the IETF to assigning names to
      things outside of the DNS, for a variety of reasons:

      *  Requires a mechanism for identifying which of a set of
         resolution processes is required in order to resolve a
         particular name.

      *  Assertion of authority: there is a sense that the namespace is
         "owned" by the IETF or by ICANN, and so, if a name is allocated
         outside of that process, the person or entity that allocated
         that name should suffer some consequence that would,
         presumably, deter future circumvention of the official process.

      *  More than one name resolution protocol is bad, in the sense
         that a single protocol is less complicated to implement and
         deploy.

      *  The semantics of alternative resolution protocols may differ
         from the DNS protocol; DNS has the concept of RRtypes; other
         protocols may not support RRtypes, or may support some entirely
         different data structuring mechanism.

      *  If there is an IETF process through which a name can be
         allocated at zero cost other than time, this process will be
         used as an alternative to allocating the name through ICANN.

      *  Some names that might be allocated would be sufficiently
         generic that other legitimate uses of those names would overlap
         with a proposed use, so that assigning the name would preclude
         some future, better use of it.

      *  If the IETF allocates a name that some third party or parties
         believes belongs to them in some way, the IETF could become
         embroiled in an expensive dispute with those parties.

   o  In cases where the IETF has made assignments through the RFC 6761
      process, technical mistakes have been made due either to
      insufficiently well-defined process or to a failure to follow the
      process that was defined in RFC 6761.

   o  In principal, the RFC 6761 process could be used to document the
      existence of domain names that are not safe to allocate, and
      provide information on how those names are used in practice.
      However, attempts to use RFC6761 to accomplish this
      [I-D.chapin-additional-reserved-tlds] have not been successful.



Lemon, et al.            Expires March 20, 2017                 [Page 5]


Internet-Draft          Special-Use Names Problem         September 2016


   o  No process exists for checking documents to make sure they don't
      accidentally assign names (e.g.  RFC 7788).

   o  Use of the registry is inconsistent--some SUTLIN RFCs specify
      registry entries; some don't; some specify delegation, some don't.

   o  There exists no safe, non-process-violating mechanism for ad-hoc
      allocation of special-use names.

   o  RFC 6761 uses the term "Domain Name" to describe the thing for
      which special uses are registered.  This creates a great deal of
      confusion because some readers take "Domain Name" to imply the use
      of the DNS protocol.

   The problems we have stated here represent the current understanding
   of the authors of the document as to the complete set of problems
   that have been identified during discussion by the working group on
   this topic.  The remainder of this document provides additional
   context that will be needed for reasoning about these problems.

4.  Existing Practice Regarding SUINs

   There are three primary and numerous secondary documents to consider
   when thinking about the Special-Use Domain Names process.

4.1.  Primary SUIN Documents

   The primary documents are considered primary because they directly
   address the IETF's past thoughts on this topic in a general way, and
   also because they describe what the IETF does in practice.  Only one
   of these documents is an IETF consensus document.

4.1.1.  IAB Technical Comment on the Unique DNS Root

   This document [RFC2826] is not an IETF consensus document, and
   appears to have been written to address a different problem than the
   SUDN problem.  However, it speaks directly to several of the key
   issues that must be considered, and of course coming as it does from
   the IAB, it is rightly given with a great deal of authority despite
   not being an IETF consensus document.

   This document should be considered required reading for IETF
   participants who wish to express an informed opinion on the topic of
   SUDNs.  The main points that appear relevant to the specal use names
   problem are:

   o  The Internet requires a globally unique namespace




Lemon, et al.            Expires March 20, 2017                 [Page 6]


Internet-Draft          Special-Use Names Problem         September 2016


   o  Private networks may operate private namespaces, but still require
      that names in the public namespace be globally unique.

   o  The Domain Name System [RFC1035] is not the only protocol that may
      be used for resolving domain names.

   o  Users cannot be assumed to know how to distinguish between symbols
      that have local meaning and symbols that have global meaning.
      Users may therefore share symbols that incorporate domain names
      with no global meaning (for example, a URL of
      'http://mysite.example.corp', where 'example.corp' is a domain
      allocated privately and informally as described in
      [SDO-ICANN-COLL]).  Such symbols might refer to the object the
      user intends to share within that user's context, but either refer
      to some other object any recipient's context, or might not refer
      to any object at all in a recipient's context.  The effect of this
      is that the user's intended communication will not be able to be
      understood by the recipients of the communication.  This same
      problem can also occur simply because a single user copies a name
      from one context in which it has one meaning, into a different
      context in which it has a different meaning-- for example copying
      a '.onion' Domain Name out of a TOR browser, where it has meaning,
      and pasting this name into an ssh client that doesn't support
      connecting over TOR.  [TODO: Consider "labels" instead of
      "symbols".]

   To boil this down even further, we can take the following advice from
   this document:

   o  Domain names with unambiguous global meaning are preferable to
      domain names with local meaning which will be ambiguous.
      Nevertheless both globally-meaningful and locally-special names
      are in use and must be supported.

   o  At the time of the writing of this document the IAB was of the
      opinion that there might well be more than one name resolution
      protocol used to resolve domain names.

4.1.2.  Special-Use Domain Names

   The second important document is Special-Use Domain Names [RFC6761].
   RFC6761 represents the current IETF consensus on designating and
   recording SUDNs.  The IETF has experienced problems with the
   designation process described in RFC6761; these concerns motivate
   this document.  Again, familiarity with RFC6761 is a prerequisite for
   having an informed opinion on the topic of SUDNs.





Lemon, et al.            Expires March 20, 2017                 [Page 7]


Internet-Draft          Special-Use Names Problem         September 2016


   RFC 6761 defines two aspects of SUDNs: designating a domain name to
   have a special purpose and registering that special use in the
   Special-Use Domain Names registry.  The designation process is
   defined in a single sentence (RFC6761, section 4):

      If it is determined that special handling of a name is required in
      order to implement some desired new functionality, then an IETF
      "Standards Action" or "IESG Approval" specification [RFC5226] MUST
      be published describing the new functionality.

   This sentence implies that any designation of a special-use name is
   subject to the same open review and consensus process as used to
   produce and publish all other IETF specifications.

   The registration process is a purely mechanical process, in which the
   existence of the newly designated special use name is recorded, with
   a pointer to a section in the relevant specification document that
   defines the ways in which special handling is to be applied to the
   name.

   RFC6761 provided the process wherebyMulticast DNS [RFC6762]designated
   ".local" as a special-use name and included it in the Special-Use
   Names registry.  It itself also enumerated a set of names that had
   been previously used or defined to have special uses prior to the
   publication of RFC6761.  Since there had been no registry for these
   names prior to the publication of RFC 6761, the documents defining
   these names could not have added them to the registry.

   There are at least several important points to think of with respect
   to the RFC6761:

   o  A special-use name may be a name that should be resolved using the
      DNS protocol with no special handling.  An example of this is
      .ARPA.

   o  A special-use name may be a name that is resolved using the DNS
      protocol, requires no special handling in the stub resolver, but
      requires special handling in the recursive resolver.  An example
      of this would be "10.in-addr.arpa."

   o  A special-use name may be name that requires special handling in
      the stub resolver.  An example would be a special-use top-level
      name like '.local' which acts as a signal to indicate that the
      local stub resolver should use a non-DNS protocol for name
      resolution.

   o  The current IETF consensus (from a process perspective, not
      necessarily from the perspective of what would be consensus if the



Lemon, et al.            Expires March 20, 2017                 [Page 8]


Internet-Draft          Special-Use Names Problem         September 2016


      IETF were to attempt to produce a new consensus document) is that
      these purposes for special-use names are valid.  [TODO: "Both"
      implies that there are only two applications; the above bullet
      points outline 3...]

   The term "stub resolver" in this case does not mean "DNS protocol
   stub resolver."  The stub resolver is the entity within a particular
   software stack that takes a question about a Domain name and answers
   it.  One way a stub resolver can answer such a question is using the
   DNS protocol, but it is in the stub resolver, as we are using the
   term here, that the decision as to whether to use a protocol, and if
   so which protocol, or whether to use a local database of some sort,
   is made.

   RFC6761 does not limit special-use names to TLDs.  However, at
   present, all special-use names registered in the IANA Special-Use
   Domain Names registry [SDO-IANA-SUDR] are either intended to be
   resolved using the DNS protocol, or are top-level domains, or both.
   That is, at present there exist no special-use names which require
   special handling by stub resolvers and which are not at the top level
   of the naming hierarchy.

   This does mean, however, that at present, RFC6762 requires the use of
   a special label, '.LOCAL', to indicate to stub resolvers that
   mDNS[RFC6762] be used to resolve names under that label.

4.1.3.  MoU Concerning the Technical Work of the IANA

   There exists a Memorandum of Understanding[RFC2860] between the IETF
   and ICANN (Internet Corporation for Assigned Names and Numbers) which
   discusses how names and numbers will be managed through the IANA
   (Internet Assigned Numbers Authority).  This document is important to
   the discussion of SUDNs because, while it delegates authority for
   managing the Domain Name System Namespace generally to ICANN, it
   reserves to the IETF the authority that RFC 6761 formalizes:

      Note that (a) assignments of domain names for technical uses (such
      as domain names for inverse DNS lookup), (b) assignments of
      specialised address blocks (such as multicast or anycast blocks),
      and (c) experimental assignments are not considered to be policy
      issues, and shall remain subject to the provisions of this
      Section 4.

   The above text is an addendum to the following:

      Two particular assigned spaces present policy issues in addition
      to the technical considerations specified by the IETF: the




Lemon, et al.            Expires March 20, 2017                 [Page 9]


Internet-Draft          Special-Use Names Problem         September 2016


      assignment of domain names, and the assignment of IP address
      blocks.  These policy issues are outside the scope of this MOU.

   In general, then, the assignment of names in the DNS root zone, and
   the management of the DNS namespace, is a function that is performed
   by ICANN.  However, the MoU specifically exempts domain names
   assigned for technical use, and uses the example of 'IN-ADDR.ARPA'
   and 'IP6.ARPA' to illustrate.  Both of these names are in the RFC
   6761 registry.

   The point here is not to say what the implications of this statement
   in the MoU are, but rather to call the reader's attention to the
   existence of this statement.

4.2.  Secondary documents relating to the SUTLIN question

   In addition to these documents, there are several others with which
   participants in this discussion should be familiar.

4.2.1.  Multicast DNS

   Multicast DNS [RFC6762] defines the Multicast DNS protocol, which
   uses the '.LOCAL' SUTLDN.  Section 3 describes the semantics of
   "multicast DNS names."  It is of considerable historical importance
   to note that the -00 version of this document, an individual
   submission, was published in July of 2001.  This version contains
   substantially the same text in section 3, and was discussed in the
   DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51].  The
   first version of this document designated '.LOCAL.ARPA' as the
   special-use name.  This idea was strongly opposed by DNSEXT working
   group participants, and as a result the author eventually switched to
   using '.LOCAL'.

   The history of RFC 6762 is documented in substantial detail in
   Appendix H; some notable milestones include the initial proposal to
   replace Appletalk's NBP in July 1997, the chartering of the Zeroconf
   working group in September 1999, allocation of a multicast address
   for link-local name discovery in April of 2000.  A companion
   requirements document, eventually published as [RFC6760] was first
   published in September of 2001.

   The point of mentioning these dates is so that discussions involving
   the time when the '.LOCAL' domain was first deployed, and the context
   in which it was deployed, may be properly informed.







Lemon, et al.            Expires March 20, 2017                [Page 10]


Internet-Draft          Special-Use Names Problem         September 2016


4.2.2.  The .onion Special-Use TLD

   The .onion Special Use TLD [RFC7686] is important because it is the
   most recent IETF action on the topic of SUTLDNs; although it does not
   set new policy, the mere fact of its publication is worth thinking
   about.

   Two important points to consider about this document are that:

   o  The IETF gained consensus to publish it

   o  The situation was somewhat forced, both by the fact of its
      unilateral allocation by the TOR project without following the RFC
      6761 process, and because a deadline had been set by the CA/
      Browser Forum [SDO-CABF-INT] after which all .onion PKI
      certificates would expire and no new certificates would be issued,
      unless the .onion SUTLDN were to be recognized by the IETF.

4.2.3.  Locally Served DNS Zones

   Locally Served DNS Zones [RFC6303] describes a particular use case
   for zones that exist by definition, and that are resolved using the
   DNS protocol, but that cannot have a global meaning, because the host
   IP addresses they reference are not unique.  This applies to a
   variety of addresses, including Private IPv4 addresses [RFC1918],
   Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice
   was first described) and IANA-Reserved IPv4 Prefix for Shared Address
   Space [RFC6598].

   This use case is distinct from the use-case for SUTLDNs like '.local'
   and '.onion' in that the names are resolved using the DNS protocol.
   But it shares the problem that such names cannot be assumed either to
   be unique or to be functional in all contexts for all Internet-
   connected hosts.

4.2.4.  Name Collision in the DNS

   Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by
   ICANN that attempts to characterize the potential risk to the
   Internet of adding global DNS delegations for names that were not
   previously delegated in the DNS, not reserved under any RFC, but also
   known to be (.local) or surmised to be (.corp) in significant use for
   special-use-type reasons (local scope DNS, or other resolution
   protocols altogether).







Lemon, et al.            Expires March 20, 2017                [Page 11]


Internet-Draft          Special-Use Names Problem         September 2016


4.2.5.  Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis

   Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
   [RFC7050] is an example of a document that successfully used the RFC
   6761 process to designate '.ipv4only.arpa' as a special-use name; in
   this case the process worked smoothly and without controversy.

4.2.6.  Additional Reserved Top Level Domains

   Additional Reserved Top Level Domains
   [I-D.chapin-additional-reserved-tlds] is an example of a document
   that attempted to reserve several TLDs identified by ICANN as
   particularly at risk for collision as special-use domain names with
   no documented use.  This attempt failed.

   Although this document failed to gain consensus to publish, the need
   it was intended to fill still exists.  Unfortunately, although a fair
   amount is known about the use of these names, no document exists that
   documents how they are used, and why it would be a problem to
   allocate them.  Additionally, to the extent that the uses being made
   of these names are valid, no document exists indicating when it might
   make sense to use them, and when it would not make sense to use them
   (the simplest version of this document would of course say "never use
   them."  If that were the IETF consensus, that would be a good reason
   not to bother to publish the document.

4.3.  Summary

   The assignment of Internet Names is not under the sole control of any
   one organization.  ICANN has authority in many cases, and could be
   considered in some sense the default.  IETF has authority in other
   cases, but only with respect to protocol development.  And neither of
   these authorities can in any practical sense exclude the practice of
   ad-hoc allocation of names, which can be done by any entity that has
   control over one or more name servers or resolvers, in the context of
   any hosts and services that that entity operates.

5.  History

   Newcomers to the problem of resolving domain names may be under the
   mistaken impression that the DNS sprang, as in the Greek legend of
   Athena, directly from Paul Mockapetris' forehead.  This is not the
   case.  At the time of the writing of the IAB technical document,
   memories would have been fresh of the evolutionary process that led
   to the DNS' dominance as a protocol for domain name resolution.

   In fact, in the early days of the Internet, hostnames were resolved
   using a text file, HOSTS.TXT, which was maintained by a central



Lemon, et al.            Expires March 20, 2017                [Page 12]


Internet-Draft          Special-Use Names Problem         September 2016


   authority, the Network Information Center, and distributed to all
   hosts on the Internet using the File Transfer Protocol (FTP)
   [RFC0959].  The inefficiency of this process is cited as a reason for
   the development of the DNS [RFC0882] [RFC0883] in 1983.

   However, the transition from HOSTS.TXT to the DNS was not smooth.
   For example, Sun Microsystems's Network Information System
   [CORP-SUN-NIS], at the time known as Yellow Pages, was an active
   competitor to the DNS, although it failed to provide a complete
   solution to the global naming problem.

   Another example was NetBIOS Name Service, also known as WINS
   [RFC1002].  This protocol was used mostly by Microsoft Windows
   machines, but also by open source BSD and Linux operating systems to
   do name resolution using Microsoft's own name resolution protocol.

   Most modern operating systems can still use the '/etc/hosts' file for
   name resolution.  Many still have a name service switch that can be
   configured on the host to resolve some domains using NIS or WINS.
   Most have the capability to resolve names using mDNS by recognizing
   the special meaning of the '.local' SUTLDN.

   The Sun Microsystems model of having private domains within a
   corporate site, while supporting the global domain name system for
   off-site persisted even after the NIS protocol fell into disuse.
   Microsoft used to recommend that site administrators allocate a
   "private" top-level domain for internal use, and this practice was
   very much a part of the zeitgeist at the time.  This attitude is the
   root of the widespread practice of simply picking an unused top-level
   domain and using it for experimental purposes, which persists even at
   the time of writing of this memo.

   This history is being presented because discussions about special-use
   names in the IETF often come down to the question of why users of new
   name resolution protocols choose to use Domain names, rather than
   using some other naming concept that doesn't overlap with the
   namespace that, in modern times is, by default, resolved using the
   DNS.

   The answer is that as a consequence of this long history of resolving
   Domain Names, Domain Names appear in a large variety of contexts in
   user interfaces applications programming interfaces.  Any name that
   appears in such a context is a Domain Name.  What this means is that
   Domain Names have a highly privileged status in deployed software.
   Proposals to change that will be almost possible to get adopted in a
   useful or consistent way.  And since in most operating systems,
   mechanisms already exist for implementing special handling for some
   Domain Names, from a practical perspective the only way to achieve



Lemon, et al.            Expires March 20, 2017                [Page 13]


Internet-Draft          Special-Use Names Problem         September 2016


   the goals of any new name resolution protocol is through the use of
   special-use Domain Names.

6.  Contributors

   This document came about as a result of conversations that occurred
   in the lobby, the weekend before IETF 95.  Stuart Cheshire, Mark
   Andrews, David Conrad, Paul Ebersman and Aaron Falk all made helpful
   and insightful observations or patiently answered questions.  This
   should not be taken as an indication that any of these folks actually
   agree with what the document says, but their generosity with time and
   thought are appreciated in any case.

   Ralph started out as an innocent bystander, but discussion with him
   was the key motivating factor in the writing of this document, and he
   agreed to co-author it without too much arm-twisting.  Warren spent a
   lot of time working with me on this document after it was first
   published, and joined as an author in order to make sure that the
   work got finished; without him the -01 and -02 versions might not
   have happened.

   And this document owes a great deal to Ed Lewis' excellent work on
   what a "domain name" is [I-D.lewis-domain-names].

7.  Informative References

   [RFC0882]  Mockapetris, P., "Domain names: Concepts and facilities",
              RFC 882, DOI 10.17487/RFC0882, November 1983,
              <http://www.rfc-editor.org/info/rfc882>.

   [RFC0883]  Mockapetris, P., "Domain names: Implementation
              specification", RFC 883, DOI 10.17487/RFC0883, November
              1983, <http://www.rfc-editor.org/info/rfc883>.

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD
              9, RFC 959, DOI 10.17487/RFC0959, October 1985,
              <http://www.rfc-editor.org/info/rfc959>.

   [RFC1002]  NetBIOS Working Group in the Defense Advanced Research
              Projects Agency, Internet Activities Board, and End-to-End
              Services Task Force, "Protocol standard for a NetBIOS
              service on a TCP/UDP transport: Detailed specifications",
              STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987,
              <http://www.rfc-editor.org/info/rfc1002>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.



Lemon, et al.            Expires March 20, 2017                [Page 14]


Internet-Draft          Special-Use Names Problem         September 2016


   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <http://www.rfc-editor.org/info/rfc1918>.

   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
              Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
              2000, <http://www.rfc-editor.org/info/rfc2826>.

   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860, DOI
              10.17487/RFC2860, June 2000,
              <http://www.rfc-editor.org/info/rfc2860>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <http://www.rfc-editor.org/info/rfc4193>.

   [RFC6303]  Andrews, M., "Locally Served DNS Zones", BCP 163, RFC
              6303, DOI 10.17487/RFC6303, July 2011,
              <http://www.rfc-editor.org/info/rfc6303>.

   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
              Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
              2012, <http://www.rfc-editor.org/info/rfc6598>.

   [RFC6760]  Cheshire, S. and M. Krochmal, "Requirements for a Protocol
              to Replace the AppleTalk Name Binding Protocol (NBP)", RFC
              6760, DOI 10.17487/RFC6760, February 2013,
              <http://www.rfc-editor.org/info/rfc6760>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <http://www.rfc-editor.org/info/rfc6761>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <http://www.rfc-editor.org/info/rfc6762>.







Lemon, et al.            Expires March 20, 2017                [Page 15]


Internet-Draft          Special-Use Names Problem         September 2016


   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
              7050, DOI 10.17487/RFC7050, November 2013,
              <http://www.rfc-editor.org/info/rfc7050>.

   [RFC7686]  Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
              Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
              2015, <http://www.rfc-editor.org/info/rfc7686>.

   [I-D.chapin-additional-reserved-tlds]
              Chapin, L. and M. McFadden, "Additional Reserved Top Level
              Domains", draft-chapin-additional-reserved-tlds-02 (work
              in progress), March 2015.

   [I-D.lewis-domain-names]
              Lewis, E., "Domain Names", draft-lewis-domain-names-03
              (work in progress), June 2016.

   [SDO-CABF-INT]
              CA/Browser Forum, "Guidance on the Deprecation of Internal
              Server Names and Reserved IP Addresses", June 2012,
              <https://www.digicert.com/internal-names.htm>.

   [SDO-ICANN-COLL]
              Interisle Consulting Group, LLC, "Name Collisions in the
              DNS", August 2013,
              <https://www.icann.org/en/system/files/files/name-
              collision-02aug13-en.pdf>.

   [SDO-IANA-SUDR]
              Internet Assigned Numbers Authority, "Special-Use Domain
              Names registry", October 2015,
              <http://www.iana.org/assignments/special-use-domain-names/
              special-use-domain-names.xhtml>.

   [CORP-SUN-NIS]
              Sun Microsystems, "Large System and Network
              Administration", March 1990.

   [IETF-PRO-51]
              Internet Engineering Task Force, "Proceedings of the 51st
              IETF", August 2001,
              <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.








Lemon, et al.            Expires March 20, 2017                [Page 16]


Internet-Draft          Special-Use Names Problem         September 2016


Appendix A.  Change Log.

   -03 to -04:

   o  Replaced 'Internet Names' with 'Domain Names' - suggestion by John
      Levine.

   -02 to -03:

   o  Readability fixes, small grammar updates.

   -01 to -02:

   o  Cleaned up the abstract.

   o  Fixed the case of Internet

   o  Reference to Ed Lewis' "domain names"

   o  Fleshed out the problems, primarily the coordination, collisions
      ones.

   -00 to -01:

   o  Large refactoring, basically a rewrite.  Incorporated comments,
      removed a bunch of unneeded text, etc.

Authors' Addresses

   Ted Lemon
   Nominum, Inc.
   800 Bridge Parkway
   Redwood City, California  94065
   United States of America

   Phone: +1 650 381 6000
   Email: ted.lemon@nominum.com


   Ralph Droms
   Cisco, Inc.

   Email: rdroms.ietf@gmail.com








Lemon, et al.            Expires March 20, 2017                [Page 17]


Internet-Draft          Special-Use Names Problem         September 2016


   Warren Kumari
   Google
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: warren@kumari.net












































Lemon, et al.            Expires March 20, 2017                [Page 18]