Network Working Group                                           T. Lemon
Internet-Draft                                             Nominum, Inc.
Intended status: Informational                                  R. Droms
Expires: August 3, September 14, 2017
                                                               W. Kumari
                                                                  Google
                                                        January 30,
                                                          March 13, 2017

               Special-Use Domain Names Problem Statement
                      draft-ietf-dnsop-sutld-ps-02
                      draft-ietf-dnsop-sutld-ps-03

Abstract

   The Special-Use Domain Names IANA registry policy defined 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 Special-
   Use Domain Names.

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 August 3, September 14, 2017.

Copyright Notice

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

   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 Domain Names . . . . . .   3   4
   4.  Existing Practice Regarding SUDNs . . . . . . . . . . Special-Use Domain Names  . . . .   7   9
     4.1.  Primary SUDN Special-Use Domain Name Documents . . . . . . . . . . . . . . . . .   7   9
       4.1.1.  IAB Technical Comment on the Unique DNS Root  . . . .   8   9
       4.1.2.  Special-Use Domain Names  . . . . . . . . . . . . . .   9  11
       4.1.3.  MoU Concerning the Technical Work of the IANA . . . .  10  12
       4.1.4.  Liaison Statement on Technical Use of Domain
               Names . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  Secondary documents relating to the SUTLDN Special-Use
           Domain Name question  . . .  11
       4.2.1.  Multicast DNS . . . . . . . . . . . . . . .  14
       4.2.1.  Multicast DNS . . . . . .  11
       4.2.2.  The .onion Special-Use TLD . . . . . . . . . . . . .  12 .  14
       4.2.2.  The .onion Special-Use Top-Level Domain Name  . . . .  14
       4.2.3.  Locally Served DNS Zones  . . . . . . . . . . . . . .  12  15
       4.2.4.  Name Collision in the DNS . . . . . . . . . . . . . .  13  15
       4.2.5.  SSAC Advisory on the Stability of the Domain
               Namespace . . . . . . . . . . . . . . . . . . . . . .  13  15
       4.2.6.  Discovery of the IPv6 Prefix Used for IPv6 Address
               Synthesis . . . . . . . . . . . . . . . . . . . . . .  13  16
       4.2.7.  Additional Reserved Top Level Domains . . . . . . . .  13
     4.3.  Summary  16
   5.  History . . . . . . . . . . . . . . . . . . . . . . . . .  14
   5.  History . .  17
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   7.  IANA considerations . . . . . .  14
   6. . . . . . . . . . . . . . . .  18
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  16
   7.  18
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  16  19
   Appendix A.  Change Log.  . . . . . . . . . . . . . . . . . . . .  19  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20  26

1.  Introduction

   One of the key services required to use the Internet is name
   resolution.  Name resolution is the process of translating a 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, use of
   the Domain Name System
   [RFC1034]. [RFC1034] for resolving these names.  An
   excellent presentation on this topic can be found in Domain Names
   [I-D.lewis-domain-names].

   Special-Use Domain Names [RFC6761] created an IANA registry for
   special-use
   Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding
   to the registry, and made some suggestions about how that policy those policies
   might be implemented.  Since the publication of RFC 6761, the IETF
   has been asked to designate several new special-use Special-Use Domain Names in
   this registry.  During the evaluation process for these special-use Special-Use
   Domain Names, 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,

   Based on current ICANN and IETF practice, including RFC 6761, there
   are several different types of names in the
   problems associated with the assignment of special-use names.  In
   support root of the particular set of problems described here, Domain
   Namespace:

   o  Reserved by the
   document also includes documentation of existing practice as it
   relates IETF for technical purposes

   o  Assigned by ICANN to the use of Domain Names, as well as a brief history of
   Domain Names, and finally to describe public DNS root; some names reserved by
      the set of problems IETF for technical purposes may appear in the Global DNS root
      for reasons pertaining to the operation of the DNS

   o  ICANN Reserved Names; names that exist may not be applied for as reported TLDs
      (see [SDO-ICANN-DAG], Section 2.2.1.2.1, Reserved Names,
      Section 2.2.1.4.1, Treatment of Country or Territory Names, et
      al.)

   o  Used by other organizations without following established
      processes

   o  Names that are unused and are available for assignment to one of
      the previous categories

   This document presents a list, believed to be complete, of the
   problems associated with the assignment of Special-Use Domain Names.
   In support of its analysis of the particular set of issues described
   here, the document also includes descriptions of existing practice as
   it relates to the use of domain names, a brief history of domain
   names, and some observations by various IETF participants with who have
   experience in the with various aspects of the problem. current situation.

2.  Terminology

   For

   This document uses the sake of brevity terminology from RFC 7719 [RFC7719].  Other
   terms used in this document uses a number of abbreviations.
   These are expanded defined here:

   Domain Name  A name which serves  This document uses the term "Domain Name" as input to a name resolution
      process, for example 'EXAMPLE.ORG'. defined in
      section 2 of RFC 7719 [RFC7719].

   Domain Namespace  The set of all possible Domain Names.

   SUDN  Special Use

   Special-Use Domain Name

   SUTLDN  Special-Use Top-Level  A Domain Name listed in the Special-Use
      Domain Names registry.

   For the sake of brevity this document uses some abbreviations, which
   are expanded here:

   IANA  Internet Assigned Numbers Authority

   ICANN  Internet Corporation for Assigned Names and Numbers

   TLD  Top-Level Domain, as defined in in section 2 of RFC 7719
      [RFC7719]

   gTLD  Generic Top-Level Domain, as defined in in section 2 of RFC
      7719 [RFC7719]

3.  Problems associated with Special-Use Domain Names

   This section presents a list of problems that have been identified
   with respect to the assignment of special-use names. Special-Use Domain Names.
   Solutions to these problems problems, including their costs or tradeoffs, are
   out of scope for this document.  Because of that,
   problems with solutions to these problems are also out of scope for
   this document, and  They will be covered in a separate
   document.

   No assertion is made  New problems that any might be created in the process of these
   solving problems is more or less
   important than any other.  The point of described in this is simply document are also out of scope:
   these problems are expected to be addressed in the process of
   evaluating potential solutions.

   Special-Use Domain Names exist to solve a variety of problems.  This
   document has two goals: enumerate
   and briefly describe all of the problems that have been raised during
   discussions
   identified to which Special-Use Domain Names are a solution and
   enumerate all of the special-use name problem.  The degree of detail is
   intended to be sufficient that problems that participants have been raised in the discussion
   can agree that the process of
   trying to use RFC 6761 as it was intended.  As some of those problems they've raised have been adequately
   described, and
   may fall into both categories, this document makes no more.  These problems should not appear attempt to
   categorize the problems.

   There is a broad diversity of opinion about this set of problems.
   Not every
   reader to all be problems: we intend to cover any problem that any participant considers a problem, not just those problems that
   everyone agrees are problems.

   In addition, no assertion is made that all each of these problems must be
   addressed, or that, if we think they should be addressed, the IETF problems enumerated in
   this document is actually a problem.  This document takes no position
   on the organization with competence to address them.  While each problem
   has one or more solutions, relative validity of the solutions may in some cases be
   mutually contradictory, or may come with costs various problems that do not justify have been
   enumerated.  Its focused purposes are to enumerate those problems,
   provide the benefit that would be obtained from solving them. reader with context for thinking about them and provide a
   context for future discussion of solutions.

   This is the list of problems:

   o  There are several different types of names in the root of the
      Domain Namespace:

      *  Reserved by  No formal coordination process exists between the IETF for technical purposes

      *  Assigned by ICANN to the public DNS root

      * and ICANN Reserved Names; names that may not be applied for
      as a
         TLD (see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names )

      *  Commandeered for use by other organizations

      *  Not a member of any other category

   o  Both ICANN and the IETF have the authority and formal they follow their respective name assignment processes to
      assign names from the pool of unused names, but no formal
      coordination process exists. (see
      Section 4.1.3).  The lack of coordination complicates the
      management of the root of the Domain Namespace and may could lead to
      conflicts in name assignments [SDO-ICANN-SAC090].

   o  The term  There is no explicit scoping as to what can constitute a
      "technical use" in RFC 2860 [RFC2860] and what cannot, and there is considered by
      some also no
      consensus within the IETF as to be too inclusive. what this term means.

   o  The IETF and ICANN each have administrative authority over the
      Domain Namespace.  Not all developers of protocols on the internet agree that this
      authority over the entire Domain Namespace should reside solely
      with the IETF and ICANN.

   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.  Such parties may observe that the IETF has never
      asserted control or authority over what protocols are "allowed" on
      the internet, and that the principle of "permissionless
      innovation" suggests there should be a way for people to include
      new uses of domain names in new protocols and applications.

   o  Organizations do in fact sometimes commandeer use subsets of the
      namespace. Domain
      Namespace without following established processes.  Reasons a
      third party might do this include:

      *  Unaware that a process exists for assigning such names

      *  Intended use is covered by gTLD process, process [SDO-ICANN-DAG], but no
         gTLD process is ongoing

      *  Intended use is covered by gTLD process, don't but the third party
         doesn't want to pay a fee

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

      *  Intended use is covered by ICANN or IETF process, but expected third
         party expects that the outcome is will be refusal or non-action

      *  Unaware that a name intended to be used only locally may
         nevertheless leak

      *  Unaware that a name used locally with informal allocation may
         subsequently be allocated formally, creating operational
         problems

   o  There is demand for more than one name resolution protocol for
      Domain Names, but Names.  Domain Names contain no metadata to indicate which
      protocol to use to resolve them.  Domain name resolution APIs do
      not provide a way to specify which protocol to use.

   o  When a special-use Special-Use Domain Name is added to the special-use Special-Use Domain
      Names registry, not all software that processes such names will
      understand the special use of that name.  In many cases, name
      resolution software will use the Domain Name System for resolution
      of names not known to have a special use.  Consequently, any such
      use will result in queries for special-use names Special-Use Domain Names being sent
      to Domain Name System authoritative servers.  These queries may
      constitute an operational problem for operators of root zone
      authoritative name servers.  These queries may also inadvertently
      reveal private information through the contents of the query,
      which is a privacy consideration.

   o  The RFC6761 RFC 6761 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 ('.local') using the RFC
      6761 process 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 (largely because this ten years included time
      to develop the process as well as use it).  Other uses of the
      process have proceeded more smoothly, but there 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 Domain
      Names to resolution systems 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 Domain
         Namespace is "owned" by the IETF or by ICANN, and so, if a name
         is claimed outside of that process, the person or entity that
         claimed 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 TLD can be assigned
         at zero cost other than time, this process will be used as an
         alternative to purchasing the more costly process of getting the name
         registered through ICANN.

      *  A name might be assigned for a particular purpose when a more
         general use of the name would be more beneficial.

      *  If the IETF assigns 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  If there were no process for assigning names for technical use
      through the IETF, there is a concern that protocols that require
      such names would not be able to get them.

   o  In some cases where the IETF has made assignments through the RFC
      6761 process, technical mistakes have been made due either to
      misunderstandings as to the actual process that RFC 6761 specifies
      (e.g., treating the list of suggested considerations for assigning
      a name as a set of requirements all of which must be met), or to a
      failure to follow met).  In
      other cases, the process IETF has made de facto assignments of Special-Use
      Domain Names without following the RFC 6761 process.

   o  There are several Domain Name TLDs that was defined are in RFC 6761. use without due
      process for a variety of purposes [SDO-ICANN-COLL].  The status of
      these names need to be clarified and recorded to avoid future
      disputes about their use.

   o  In principle, the RFC 6761 process could be used to document the
      existence of Domain Names that are not safe to assign, and provide
      information on how those names are used in practice.  However,
      attempts to use RFC6761 RFC 6761 to accomplish this
      [I-D.chapin-additional-reserved-tlds] documentation have not
      been successful. successful (for example, see "Additional Reserved Top Level
      Domains [I-D.chapin-additional-reserved-tlds] and Section 4.2.7).
      One side effect of this the lack of documentation is that any
      mitigation effect on the root name servers or on privacy
      considerations has been missed.

   o  There are several  A Domain Name TLDs that have been commandeered
      without due process for a variety of purposes [SDO-ICANN-COLL].
      The status of these names need to can be clarified and recorded to
      avoid future disputes about their use. [ Ed note: We note that
      DNSOP has previously discussed some of these identified as either a DNS name by placing it
      in draft-chapin-
      additional-reserved-tlds-02, and decided not the DNS zone(s) or as a Special-Use Domain Name by adding it to adopt
      the draft -
      https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html
      .  The authors IANA registry.  Some names are not recommending that DNSOP revisit this,
      rather that is needs to be addressed in some venue. ]

   o  No mechanism exists both places; for adding example,
      some locally served zone names are in DNS zones and documented in
      the Special-Use Domain Names registry.  At present, the only way a name
      Domain Name can be added to the Special-Use Domain Name registry without
      claiming that the IETF is responsible for that name, nor
      is it
      possible to state a precedence for the name, e.g. "if ICANN
      delegates this name, ICANN's delegation takes precedence." IETF to take responsibility for the name and designate
      it for "technical use".  There are other potential uses for Domain
      Names that should be recorded in the registry, but for which the
      IETF should not take responsibility.

   o  The IETF may in some cases see the need to document that a name is
      in use without claiming that the use of the name is the IETF's use
      of the name.  No process mechanism exists for checking documents in the current registry to mark
      names in this way.

   o  There is no formal mechanism that ensures that we check to make
      sure they don't
      accidentally assign names (e.g. that a document being considered for publication does not
      unintentionally violate the IETF process for adding Special-Use
      Domain Names to the registry (e.g., RFC 7788). 7788 [RFC7788]).

   o  Use of the registry is inconsistent--some SUTLDN Special-Use Domain Name
      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
      assignment of special-use names. Special-Use Domain Names.

   o  It is generally assumed that protocols that need a special-use
      name Special-Use
      Domain Name need a mnemonic, single-label, human-readable special-use name.  This Special-
      Use Domain Name, for use in user interfaces such as command lines
      or URL entry fields.  While this assumption may is correct in some
      cases, it is likely not be warranted correct in all cases. cases; for example, in
      applications where the DNS name is never visible to a user.

   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.

   o  The problems we have stated here represent the current understanding use of DNSSEC with Special-Use Domain Names is an open issue.
      There is no consensus or guidance about how to use DNSSEC with
      various classes of Special-Use Domain Names.  Considerations in
      the authors use of DNSSEC with Special-Use Domain Names include:

      *  What class of Special-Use Domain Name is under consideration:
         non-DNS, locally served zone, other?

      *  Does the document as to Special-Use Domain Name require a delegation in the complete set of problems
         root zone; if so, should that have been identified during discussion by the working group on delegation be signed or not?  If
         there is no delegation, then this topic. will be treated by validating
         resolvers as a secure denial of existence for that zone.  This
         would not be appropriate for a name being resolved using the
         DNS protocol.

      *  A process would be required through which the IETF can cause a
         delegation in the root zone to be instantiated.

      *  What are the recommended practices for using DNS with the
         specific Special-Use Domain Name?

   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 SUDNs Special-Use Domain Names

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

4.1.  Primary SUDN Documents

   The primary documents

   How names are considered primary because they directly
   address the IETF's past thoughts on this topic resolved is ambiguous, 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 sense that some names are
   Special-Use Domain names that require special handling, and some
   names can be resolved using the Unique DNS Root

   This document [RFC2826] protocol with no special
   handling.

   The assignment of Internet Names is not an under the sole control of any
   one organization.  IETF consensus document, and
   appears to have been written has authority in some cases, but only with
   respect to address a different problem than "technical uses."  ICANN at present is the
   SUDN problem.  However, it speaks directly to several designated
   administrator of the key
   issues that must be considered, and root zone, but generally not of course coming as it does from zones other than
   the IAB, it is rightly treated as having significant root zone.  And neither of these authorities can in any practical
   sense exclude the practice of ad-hoc use of names.  This 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.  It can also be done by authors of software who decide that
   a Special-Use Domain Name is the right way to indicate the use of an
   alternate resolution mechanism.

4.1.  Primary Special-Use Domain Name 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
   Special-Use Domain Name 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 treated as having
   significant 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.
   Special-Use Domain Names.  The main points that appear relevant to
   the special use names Special-Use Domain Names problem are:

   o  The Internet requires a globally unique namespace

   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
      symbolic references that have local meaning and references that
      have global meaning.  Users may therefore share references that
      incorporate Domain Names with no global meaning (for example, a
      URL of 'http://mysite.example.corp', where 'example.corp' is a
      domain used privately and informally as described in
      [SDO-ICANN-COLL]).

   o  Such references 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.

   o  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, Tor Browser [TOR],
      where it has meaning, and pasting this name into an ssh client
      that doesn't support connecting over TOR. the Tor network.

   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  RFC 6761 represents the current IETF consensus on
   designating and recording SUDNs. Special-Use Domain Names.  The IETF has
   experienced problems with the designation process described in RFC6761; RFC
   6761; these concerns motivate this document.  Again, familiarity with RFC6761
   RFC 6761 is a prerequisite for having an informed opinion on the
   topic of SUDNs. Special-Use Domain Names.

   RFC 6761 defines two aspects of SUDNs: Special-Use Domain Names: 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, (RFC 6761, 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 Special-Use Domain
   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 Special-Use Domain 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

   RFC 6761 provided the process whereby Multicast DNS [RFC6762]
   designated ".local" as a SUDN Special-Use Domain Name and included it in
   the Special-Use Domain 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. RFC 6761.  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: RFC 6761:

   o  A special-use name Special-Use Domain Name may be a name that should be resolved
      using the DNS protocol with no special handling.  An example of
      this is 'IN-
      ADDR.ARPA.' 'IN-ADDR.ARPA.' (which is an example of a Special-Use
      Domain Name that is not a TLD).

   o  A special-use name Special-Use Domain 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 Special-Use Domain Name may be a name that requires special
      handling in the stub resolver.  An example would be a special-use top-level
      name Special-Use
      Top-Level Domain 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
      IETF were to attempt to produce a new consensus document) is that
      all of these purposes for special-use names Special-Use Domain Names are valid.

   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

   RFC 6761 does not limit special-use names Special-Use Domain Names to TLDs.  However,
   at present, all special-use names Special-Use Domain 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, TLDs, or both.  That
   is, at present there exist no special-use names Special-Use Domain Names which require
   special handling by stub resolvers and which are not at the top level
   of the naming hierarchy.

   One point to take from this is that there is already a requirement in
   RFC6762
   RFC 6762 that when stub resolvers encounter the special label,
   '.LOCAL' at the top level of a domain name, they can only use the
   mDNS protocol be used for resolving that Domain Name.

4.1.3.  MoU Concerning the Technical Work of the IANA

   There exists a Memorandum of Understanding[RFC2860] 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 Special-Use Domain Names 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
      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 domains used for
   inverse DNS lookup.  Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the
   special-use
   Special-Use Domain Names registry.

   Implicit in the MoU is the fact that the IETF and ICANN retain,
   between them, sole authority for assigning any names from the Domain
   Namespace.  Both the IETF and ICANN have internal processes for
   making such assignments.

   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.1.4.  Liaison Statement on Technical Use of Domain Names

   As a result of processing requests to add names to the Special-Use
   Domain Name registry, as documented in
   [I-D.chapin-additional-reserved-tlds] and
   [I-D.grothoff-iesg-special-use-p2p-names], the IAB initiated a review
   of the process defined in RFC 6761 for adding names to the registry.
   This review was identified as in the charter of the IETF DNSOP
   working group, and the review has been conducted in that working
   group.  The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of
   the review, affirmed that the discussion would be "open and
   transparent to participation by interested parties" and explicitly
   invited members of the ICANN community to participate.

   This document is a product of the IETF DNSOP working group review of
   the registry process in RFC 6761.

4.2.  Secondary documents relating to the SUTLDN Special-Use Domain Name
      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. Special-Use Top-Level Domain Name.  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. Special-Use Domain 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, assignment 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.

4.2.2.  The .onion Special-Use TLD Top-Level Domain Name

   The .onion Special Use TLD Special-Use Top-Level Domain Name [RFC7686] is important
   because it is the most recent IETF action on the topic of SUTLDNs; Special-Use
   Domain Names; 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 use by the TOR project 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
      Special-Use Top-Level Domain Name 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 Special-Use Domain
   Names like '.local' and '.onion' in that the names are resolved using
   the DNS protocol (but do require extensions or exceptions to the
   usual DNS resolution to enforce resolution in a local context rather
   than the global DNS context).  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 (.home) or surmised to be (.corp) in significant use for
   special-use-type
   Special-Use-type reasons (local scope DNS, or other resolution
   protocols altogether).

4.2.5.  SSAC Advisory on the Stability of the Domain Namespace

   This document

   SSAC Advisory on the Stability of the Domain Namespace
   [SDO-ICANN-SAC090] reports on some issues surrounding the conflicting
   uses, interested parties and processes related to the Domain
   Namespace.  The document recommends the development of collaborative
   processes among the various interested parties to coordinate their
   activities related to the Domain Namespace.

4.2.6.  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; Special-Use Domain
   Name; in this case the process worked smoothly and without
   controversy.

   Unfortunately, while the IETF process worked smoothly, in the sense
   that there was little controversy or delay in approving the new use,
   it did not work correctly: the name 'ipv4only.arpa' was never added
   to the special-use Special-Use Domain Names registry.  This appears to have
   happened because the IAB was able to simply add the name to the .ARPA
   zone, which the IAB administers.  This is an illustration of one of
   the problems that we have with the 6761 process: it is apparently
   fairly easy to miss the step of adding the name to the registry.

4.2.7.  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 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
   delegate 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.

   RFC 7788 [RFC7788] defines the Domain Name TLD ".home" for use as the
   default name for name resolution relative to a home network context.
   Although, as defined in RFC 7788, ".home" is a special-use Special-Use Domain
   Name, RFC 7788 did not follow the process in RFC 6761 and request the
   addition of ".home" to the IANA Special-Use Domain Name registry.
   Additionally, ".home" is an example of an attempt to reuse a Domain
   Name that has already been commandeered put into use for other purposes
   [SDO-ICANN-COLL], without
   following established processes[SDO-ICANN-COLL], which further
   complicates the situation.  At the time this document was written,
   the IETF was developing a solution to this problem.

4.3.  Summary

   How names are resolved is ambiguous, in

5.  History

   Newcomers to the sense that some names are
   special-use names that require special handling, and some names can problem of resolving Domain Names may be resolved using the DNS protocol with no special handling.

   The assignment of Internet Names is not under the sole control of any
   one organization.  IETF has authority in some cases, but only with
   respect to "technical uses."  ICANN at present is the designated
   administrator of the root zone, but generally not of zones other than
   the root zone.  And neither of these authorities can in any practical
   sense exclude the practice of ad-hoc use of names.  This 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.  It can also be done by authors of software who decide that
   a special-use name is the right way to indicate the use of an
   alternate resolution mechanism.

5.  History

   Newcomers to the problem of resolving Domain Names may be under 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
   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. Special-Use Top Level Domain
   Name.

   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 use a "private"
   top-level domain
   TLD for internal use, and this practice was very much a part of the
   zeitgeist at the time (see section 5.1 of [SDO-ICANN-COLL] and
   Appendix G of [RFC6762]).  This attitude is at the root of the
   widespread practice of simply picking an unused top-
   level domain TLD 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 Special-Use
   Domain 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 using a wide variety of name resolution systems, Domain
   Names are required in a large variety of contexts in user interfaces
   and applications programming interfaces.  Any name that appears in
   such a context is a Domain Name.  So developers of new name
   resolution systems that must work in existing contexts actually have
   no choice: they must use a special-use Special-Use Domain Name to segregate a
   portion of the namespace for use with their system.

6.  Security Considerations

   This document mentions various security and privacy considerations in
   the text.  However, this document creates no new security or privacy
   concerns.

7.  IANA considerations

   This document has no actions for IANA.

8.  Contributors

   This document came about as a result of conversations that occurred
   in the conference hotel lobby, the weekend before IETF 95, when the
   original author, Ted Lemon, was trying to come up with a better
   problem statement.  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 us 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.

   This document also owes a great deal to Ed Lewis' excellent work on
   what a "Domain Name" is [I-D.lewis-domain-names].

7.

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

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

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

   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <http://www.rfc-editor.org/info/rfc7719>.

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <http://www.rfc-editor.org/info/rfc7788>.

   [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.grothoff-iesg-special-use-p2p-names]
              Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and
              L. Ryge, "Special-Use Domain Names of Peer-to-Peer
              Systems", draft-grothoff-iesg-special-use-p2p-names-04
              (work in progress), January 2015.

   [I-D.lewis-domain-names]
              Lewis, E., "Domain Names", draft-lewis-domain-names-04 draft-lewis-domain-names-05
              (work in progress), September 2016. February 2017.

   [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-ICANN-SAC090]
              ICANN Security and Stability Advisory Committee, "SSAC
              Advisory on the Stability of the Domain Namespace",
              December 2016,
              <https://www.icann.org/en/system/files/files/sac-
              090-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>.

   [SDO-ICANN-DAG]
              Internet Assigned Numbers Authority, "Special-Use Domain
              Names registry", October 2015,
              <https://newgtlds.icann.org/en/applicants/agb/guidebook-
              full-04jun12-en.pdf>.

   [SDO-IAB-ICANN-LS]
              Internet Architecture Board, "Liaison Statement from the
              IAB to the ICANN Board on Technical Use of Domain Names",
              September 2015, <https://datatracker.ietf.org/
              liaison/1351>.

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

   [TOR]      The Tor Project, "Tor", 2017,
              <https://www.torproject.org>.

Appendix A.  Change Log.

   -02 to -03 (in Github):

      Passes idnits except for errors resulting from a reference to an
      RFC 2119 keyword and a citation of RFC 5226 with no matching
      reference in quoted text at line 493.

      Issue #57: Document needs an "Security Considerations" section
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/57

      Numerous editorial changes for consistency; e.g. use "Special-Use
      Domain Names" throughout.

      Issue #58: Document needs an "IANA Considerations" section
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/58

      Issue #39: Overlapping bullets in Section 3, with proposed
      restructuring -- Russ Housley https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/39

      Issue #55: Editorial improvement to Section 3 (4) -- John
      Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/
      issues/55

      Issue #34: Separate two problems in paragraph that begins "No
      mechanism exists for adding a name to the registry...." (2 issues)
      -- Suzanne Woolf https://github.com/Abhayakara/draft-tldr-sutld-
      ps/issues/34

      Issue #52: Editorial improvement to Section 3 (1) -- John
      Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/
      issues/52

      Issue #51: Clarification in Introduction -- John Dickinson
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/51
      Issue #49: Should cite https://datatracker.ietf.org/liaison/1351
      -- George Michaelson https://github.com/Abhayakara/draft-tldr-
      sutld-ps/issues/49

      Issue #50: IETF precedence in Special-Use names registry -- Ted
      Lemon https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/50

      Issue #48: 4.1.2 cites sub-domains of .ARPA arguing for special
      use TLD -- George Michaelson https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/48

      Issue #47: 4.3 should be made more prominent -- George Michaelson
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/47

      Issue #43: Spell out SUDN and SUTLDN rather than use acronyms --
      Russ Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/
      issues/43

      Issue #41: Reword bullet in Section 3 regarding Domain Name TLDs
      that have been commandeered, as reported in SDO-ICANN-COLL -- Russ
      Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/
      issues/41

      Issue #40: Note that time to publish spec for .local included
      inventing SUDN registry -- Russ Housley
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/41

      Issue #37: Title should be "Special-Use Domain Names Problem
      Statement" -- Russ Housley https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/37

      Issue #36: Expand on desire for Special-Use names to be human-
      readable -- Suzanne Woolf https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/36

      Issue #35: Clarify "No process exists [...]" to include both IETF
      process and other process -- Suzanne Woolf
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/35

      Issue #31: Add justification for concern about IETF's ability to
      assign names for technical use -- Suzanne Woolf
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/31

      Issue #12: Add DNSSEC to text -- John Levine
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/12

      Issue #6: Without a process, we just have chaos -- Stuart Cheshire
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/6
      Issue #32: Have assignments through RFC 6761 really had "technical
      mistakes"? -- Suzanne Wolff https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/32

      Issue #29: Add a reason to bypass external process: expectation
      for use of new name to be restricted to local scope -- Suzanne
      Wolff https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/29

      Issue #27: Is "technical use" really ambiguous; too inclusive for
      some people and too limited for others -- Suzanne Wolff
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/27

      Issue #24: Replacement for "commandeer" (2 issues)-- Suzanne Wolff
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/24

      Issue #22: Clarify importance of the "root of the Domain
      Namespace" -- Suzanne Wolff https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/22

      Issue #21: Section 3 - clarify paragraphs 2 and 3 -- Suzanne Wolff
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/21

      Issue #20: Section 3: Clarify sentences beginning "Solutions to
      these problems..." -- Suzanne Wolff https://github.com/Abhayakara/
      draft-tldr-sutld-ps/issues/20

      Issue #19: Define "default" or "assumed" use of domain names to be
      within DNS -- Suzanne Wolff https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/19

      Issue #18: Cite definition of RFC 7719 and domain names draft in
      definition of "domain name" -- Suzanne Wolff
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/18

      Issue #45: Correct usages of Tor Browser and Tor -- Russ Housley
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/45)

      Issue #46: Reformat citation of RFC 2860 -- Russ Housley
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/46)

      Issue #44: Clean up reference to SDO-ICANN-DAG in first bullet in
      section 3 -- Russ Housley (https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/44)

      Issue #42: Add reference to SDO-ICANN-SAC090 in section 4.2.5 --
      Russ Housley (https://github.com/Abhayakara/draft-tldr-sutld-ps/
      issues/42)
      Issue #30: Leaked queries aren't an operational problem in
      practice -- Suzanne Wolf (https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/30)

      Address some of the simpler issues, including:

      Issue #13: Spelling of Tor -- Jeremy Rand
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/13)

      Issue #14: Change SDO to "organizations" -- Suzanne Woolf
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14)

      Issue #16: Match number of "policies" and "that policy" -- Suzanne
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/16)

      Issue #17: Clarify sentence beginning with "In support of the
      particular set of problems described here...." -- Suzanne.
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14)

      Issue #23: Match number of "names" and "a TLD" -- Suzanne.
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/23)

   -01 to -02:

      Language cleanup from Ted.

   -00 to -01:

      Improved the terminology.

      Included reference to SAC090.

      Added ICANN Reserved Names (e.g .icann, .iesg, .arin) to types of
      names.

      Improved background.

      Noted that semantics may differ between resolution contexts.

      Pointer to .home / .corp / .mail, other "toxic" names

      Readability fixes.

   -04 to ietf-00

      Document adopted by WG.

      Significant changes from CfA integrated, please refer to diff.

   -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

   Email: rdroms.ietf@gmail.com
   Warren Kumari
   Google
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: warren@kumari.net