Network Working Group
Internet Engineering Task Force (IETF)                          T. Lemon
Internet-Draft
Request for Comments: 8244                                 Nominum, Inc.
Intended status:
Category: Informational                                         R. Droms
Expires: February 5, 2018
ISSN: 2070-1721
                                                               W. Kumari
                                                                  Google
                                                          August 4,
                                                            October 2017

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

Abstract

   The Special-Use Domain Names IANA registry policy defined in RFC 6761 for IANA registrations in the
   "Special-Use Domain Names" registry has been shown shown, through experience
   experience, to present unanticipated
   challenges. challenges that were not anticipated when RFC
   6761 was written.  This memo presents a list, intended to be
   comprehensive, of the problems that have since been identified.  In addition
   addition, it reviews the history of Domain Names domain names and summarizes
   current IETF publications and some publications from other
   organizations relating to Special-
   Use Special-Use Domain Names.

   This document should be considered required reading for IETF
   participants who wish to express an informed opinion on the topic of
   Special-Use Domain Names.

Status of This Memo

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

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

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

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a maximum candidate for any level of Internet
   Standard; see Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 February 5, 2018.
   https://www.rfc-editor.org/info/rfc8244.

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)
   (https://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 . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Problems associated Associated with Special-Use Domain Names . . . . . .   4
   4.  Existing Practice Regarding regarding Special-Use Domain Names  . . . .   9
     4.1.  Primary Special-Use Domain Name Documents . . . . . . . .  10
       4.1.1.  IAB Technical Comment on the Unique DNS Root  . . . .  10
       4.1.2.  Special-Use Domain Names  . . . . . . . . . . . . . .  11
       4.1.3.  MoU Concerning the Technical Work of the IANA . . . . . .  13
       4.1.4.  Liaison Statement on Technical Use of Domain Names  . . . . . . . . . .  14
       4.1.5.  IAB Statement on the Registration of Special Use
               Names in the ARPA Domain  . . . . . . . . . . . . . .  14
     4.2.  Secondary documents relating Documents Relating to the Special-Use Domain
           Name question Question . . . . . . . . . . . . . . . . . . . . . .  14
       4.2.1.  Multicast DNS . . . . . . . . . . . . . . . . . . . .  14  15
       4.2.2.  The .onion '.onion' Special-Use Top-Level Domain Name  . . . .  15
       4.2.3.  Locally Served DNS Zones  . . . . . . . . . . . . . .  16
       4.2.4.  Name Collision in the DNS . . . . . . . . . . . . . .  16
       4.2.5.  SSAC Advisory on the Stability of the Domain
               Namespace . . . . . . . . . . . . . . . . . . . . . .  16  17
       4.2.6.  Discovery of the IPv6 Prefix Used for IPv6 Address
               Synthesis . . . . . . . . . . . . . . . . . . . . . .  16  17
       4.2.7.  Additional Reserved Top Level Top-Level Domains . . . . . . . .  17
   5.  History . . . . . . . . . . . . . . . . . . . . . . . . . . .  17  18
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   7.  IANA considerations Considerations . . . . . . . . . . . . . . . . . . . . .  19
   8.  Contributors  . . . . .  Informative References  . . . . . . . . . . . . . . . . . . .  19
   9.  RFC Editor Considerations . .
   Contributors  . . . . . . . . . . . . . . . .  19
   10. Informative References . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . .  19
   Appendix A.  Change Log. . . . . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29  24

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. "domain names".  When reading this document, care must
   be taken to not to assume that the term Domain Name domain name implies the use of
   the Domain Name System [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].

   "Special-Use Domain Names Names" [RFC6761] created an the "Special-Use Domain
   Names" IANA registry for
   Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding to
   the registry, and made some suggestions about how those policies
   might be implemented.  Since the publication of RFC 6761, the IETF
   has been asked to designate several new Special-Use Domain Names in
   this registry.  During the evaluation process for these 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 process defined in RFC 6761 process can be improved, or
   whether it should be deprecated.  The IETF DSNOP working group DNSOP Working Group
   charter was extended to include conducting a review of the process
   for adding names to the registry that is defined in RFC 6761.  This
   document is a product of that review.

   Based on current ICANN and IETF practice, including RFC 6761, there
   are several different types of names in the root of the Domain
   Namespace:

   o  Reserved  Names reserved by the IETF for technical purposes

   o  Assigned  Names assigned by ICANN to the public DNS root; some names
      reserved by the IETF for technical purposes may appear in the Global
      global DNS root for reasons pertaining to the operation of the DNS

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

   o  Used  Names 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, derived from a variety of sources sources,
   including discussion in the IETF dnsop WG, DNSOP Working Group, of the problems
   associated with the assignment of Special-Use Domain Names.  The list
   is intended to be an unfiltered compilation of issues.  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 who have
   experience with various aspects of the current situation.

2.  Terminology

   This document uses the terminology from RFC 7719 [RFC7719].  Other
   terms used in this document are defined here:

   Domain Name Name:  This document uses the term "Domain Name" "domain name" as defined in
      section
      Section 2 of RFC 7719 [RFC7719].

   Domain Namespace Namespace:  The set of all possible Domain Names. domain names.

   Special-Use Domain Name Name:  A Domain Name domain name listed in the Special-Use "Special-Use
      Domain Names Names" registry [SDO-IANA-SUDR].

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

   IANA

   IANA:   Internet Assigned Numbers Authority

   ICANN

   ICANN:  Internet Corporation for Assigned Names and Numbers

   TLD

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

   gTLD

   gTLD:   Generic Top-Level Domain (see section Section 2 of RFC 2352
           [RFC2352])

3.  Problems associated 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 Domain Names.
   Solutions to these problems, including their costs or tradeoffs, trade-offs, are
   out of scope for this document.  They document and will be covered in a separate
   document.  New problems that might be created in the process of
   solving problems described in this 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 all of the problems that have been
   identified to which Special-Use Domain Names are a solution and
   enumerate all of the problems that have been raised in the process of
   trying to use RFC 6761 as it was intended.  As some of those problems
   may fall into both categories, this document makes no attempt to
   categorize the problems.

   There is a broad diversity of opinion about this set of problems.
   Not every participant agrees that each of the problems enumerated in
   this document is actually a problem.  This document takes no position
   on the relative validity of the various problems that have been
   enumerated, nor on the organization responsible for addressing each
   individual problem, if it is to be addressed.  The sole purposes of
   the  This document are to enumerate those only
   enumerates the problems, provide provides the reader with context for
   thinking about them them, and provide provides a context for future discussion of
   solutions, regardless of whether such solutions may be work for IETF,
   ICANN, IANA IANA, or some other group.

   This is the

   The list of problems.  This problems is not an ordered list, it is
   numbered merely presented in order of importance; numbers
   are assigned so that each problem can easily be referenced by number,
   not to facilitate referencing specific problems: indicate priority.  The list of problems is as follows:

   1.   Although the IETF and ICANN have a liaison relationship through
        which special-use allocations can be discussed, there exists no
        formal process for coordinating these allocations (see
        Section 4.1.3).  The lack of coordination complicates the
        management of the root of the Domain Namespace and could lead to
        conflicts in name assignments [SDO-ICANN-SAC090].

   2.   There is no explicit scoping as to what can constitute a
        "technical use" [RFC2860] and what cannot, and cannot; there is also no
        consensus within the IETF as to what this term means.

   3.   Not all developers of protocols on the internet Internet agree that
        authority over the entire Domain Namespace should reside solely
        with the IETF and ICANN.

   4.   Although the 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, 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.

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

        1.  Unaware  Lack of knowledge that a process exists for assigning such names
            names.

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

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

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

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

        6.  Unaware  Lack of knowledge that a name intended to be used only
            locally may nevertheless leak leak.

        7.  Unaware  Lack of knowledge that a name used locally with informal
            allocation may subsequently be allocated formally, creating
            operational
            problems problems.

   6.   There is demand for more than one name resolution protocol for
        domain names.  Domain Names.  Domain Names 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.

   7.   When a Special-Use Domain Name is added to the Special-Use "Special-Use
        Domain Names 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 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.

   8.   The RFC 6761 process is sufficiently uncertain that some   Some protocol developers have assumed that they could not get
        succeed in getting a name
        assigned; assigned through the IETF using the
        process defined in RFC 6761.  This is because when the IETF has
        attempted to follow the process defined in RFC 6761, it has been
        slow and uncertain.  For example, the process of assigning the
        first new name ('.local') using the process defined in 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 (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.

   9.   There is strong resistance within the IETF to assigning Domain
        Names domain
        names to resolution systems outside of the DNS, for a variety of
        reasons:

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

        2.  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, without following their processes, the person or
            entity that claimed that name should suffer some consequence
            that would, presumably, deter future circumvention of the
            official process. processes.

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

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

        5.  If there is an IETF process through which a TLD can be
            assigned at zero cost other than time, this process will be
            used as an alternative to the more costly process of getting
            the name registered through ICANN.

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

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

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

   11.  In some cases where the IETF has made assignments through the
        process defined in RFC 6761 process, 6761, technical mistakes have been made
        due 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 requirements, all of which must
        be met).  In other cases, the IETF has made de facto assignments
        of Special-Use Domain Names without following the process in RFC
        6761
        process (see [RFC7050], [RFC7050] and [RFC7788]).

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

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

   14.  A Domain Name domain name can be identified as either a DNS name by placing
        it in the DNS zone(s) or as a Special-Use Domain Name by adding it
        to the IANA registry.  Some names are in both places; for
        example, some locally served zone names are in DNS zones and
        documented in the Special-Use "Special-Use Domain Names Names" registry.  At
        present, the only way a Domain Name domain name can be added to the Special-
        Use
        "Special-Use Domain Name Name" registry is for the IETF to take
        responsibility for the name and designate it for "technical
        use".  There are other potential uses for Domain Names domain names that
        should be recorded in the registry, but for which the IETF
        should not take responsibility.

   15.  The  In some cases, 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 particular use of the name.  No mechanism exists in the
        current registry to mark names in this way.

   16.  There is no formal process during  During any of the review stages for of a
        document document, there is no
        formal process in which a check is made to ensure that the
        document does not unintentionally violate the IETF process for
        adding
        special-use domain names Special-Use Domain Names to the registry, as was the
        case, for example, in RFC 7788 [RFC7788].

   17.  Use of the registry is inconsistent -- some Special-Use Domain
        Name RFCs specifically add registry entries, some don't; some
        specify how and whether special-use name delegations should be
        done, some don't.

   18.  There exists no safe, non-process-violating mechanism for ad-hoc ad hoc
        assignment of Special-Use Domain Names.

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

   20.  RFC 6761 uses the term "Domain Name" "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" "domain name" to imply the
        use of the DNS protocol.

   21.  The 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 use of DNSSEC with Special-Use Domain
        Names include:

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

        2.  Does the Special-Use Domain Name require a delegation in the
            root zone; if so, should that delegation be signed or not?
            If there is no delegation, then this 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.

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

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

   The problems we have stated here represent above list represents 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 related to these problems.

4.  Existing Practice Regarding regarding Special-Use Domain Names

   There are three primary (see Section 4.1) and numerous secondary
   (Section 4.2) documents to consider when thinking about the Special-
   Use Domain Names process.

   How names are resolved is ambiguous, in the sense that some names are
   Special-Use Domain names Names that require special handling, handling and some names
   can 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.  The IETF has authority in some cases, but only
   with respect to "technical uses." uses".  At present, ICANN at present is the
   designated administrator of the root zone, zone; but generally not of zones
   other than the root zone.  Neither of these authorities can can, in any
   practical
   sense sense, exclude the practice of ad-hoc ad hoc use of names.
   Unauthorized use of domain names can be accomplished by any entity
   that has control over one or more name servers or resolvers, in the
   context of any hosts and services that entity operates.  It can also
   be accomplished 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.

4.1.1.  IAB Technical Comment on the Unique DNS Root

   This document

   [RFC2826] is not an IETF consensus document, and it 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, 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
   Special-Use Domain Names.  The main points that appear relevant to
   the Special-Use Domain Names problem are:

   o  The Internet requires a globally unique namespace: a namespace in
      which any given name refers to the same information (has the same
      meaning) no matter who requests that information and no matter
      from which specific name server they request it.

   o  Private networks may operate private namespaces, with names that
      have meanings only locally (within the private network) network), but they
      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  Therefore, users may therefore share references that
      incorporate Domain Names 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  While such a reference in the user's context refers to the object
      the user intends wishes to
      share within that user's share, when the reference is used in a
      different context, but either it could refer either to some other different object any
      in the recipient's context, context or might not refer to any no object at all in a recipient's context. all.  The effect of
      this reference escaping the context in which it is valid 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 when a single user copies a name
      from one context in which it has one meaning, meaning into a different
      context in which it has a different meaning -- for example example,
      copying a '.onion' Domain Name domain name out of a Tor Browser [TOR], where
      it has meaning, and pasting this name into an ssh SSH client that
      doesn't support connecting over the Tor network.

   We can summarize the advice in this document as follows:

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

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

4.1.2.  Special-Use Domain Names

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

   RFC 6761 defines two aspects of Special-Use Domain Names: designating
   a Domain Name domain name to have a special purpose and registering that special
   use in the Special-Use "Special-Use Domain Names Names" registry.  The designation
   process is defined in a single sentence (RFC 6761, section 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 requires that any designation of a 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 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.

   RFC 6761 provided provides the process whereby Multicast DNS "Multicast DNS" [RFC6762]
   designated ".local" '.local' as a Special-Use Domain Name and included it in
   the Special-Use "Special-Use Domain Names Names" registry.  It itself  RFC 6761 also enumerated enumerates a
   set of names that had been were previously used or defined to have special
   uses prior to the publication of RFC 6761. its publication.  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

   Several important points to think of about with respect to the RFC 6761: 6761 are:

   o  A 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 Domain Name may be a name that is resolved using the
      DNS protocol, protocol and that requires no special handling in the stub resolver,
      resolver but that requires special handling in the recursive
      resolver.  An example of this would be "10.in-addr.arpa." '10.in-addr.arpa.'.

   o  A 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 Domain Name like '.local' '.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 Domain Names are valid.

   The

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

   RFC 6761 does not limit Special-Use Domain Names to TLDs.  However,
   at present, all Special-Use Domain Names registered in the IANA
   Special-Use "Special-
   Use Domain Names Names" registry [SDO-IANA-SUDR] are either are intended to be
   resolved using the DNS protocol, or are TLDs, or are both.  That is, at
   present there exist no Special-Use Domain Names which that 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
   RFC 6762 that when a stub resolver encounters the special label,
   '.LOCAL' at
   'local' as the top level rightmost label of a domain name, it can only use the mDNS
   Multicast DNS (mDNS) protocol to resolve that Domain Name. domain name.

4.1.3.  MoU Concerning the Technical Work of the IANA

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

      Note that (a) assignments of Domain Names domain names for technical uses (such
      as Domain Names 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, domain names, and the assignment of IP address
      blocks.  These policy issues are outside the scope of this MOU.

   In general, then, the

   The assignment of names in the DNS root zone, and the management of
   the DNS namespace, Domain Namespace, is by default a function that is performed by
   ICANN.  However, the MoU specifically exempts domain names assigned
   for technical use, use and uses the example of domains used for inverse
   DNS lookup.  Both 'IN-ADDR.ARPA' 'in-addr.arpa' and 'IP6.ARPA' 'ip6.arpa' are in the
   Special-Use "Special-
   Use Domain Names 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

   When the IETF received processing requests to add names to the
   Special-Use
   "Special-Use Domain Name Names" registry, as documented in
   [I-D.chapin-additional-reserved-tlds] [RESERVED-TLDS]
   and
   [I-D.grothoff-iesg-special-use-p2p-names], [P2P-DOMAIN-NAMES], the IETF chartered a review of the process
   defined in RFC 6761 for adding names to the registry (as explained
   earlier).  The IETF sent a Liaison Statement liaison statement [SDO-IAB-ICANN-LS] to
   ICANN to notify ICANN them of the review, affirm that the discussion would
   be "open and transparent to participation by interested parties" parties", and
   explicitly invite members of the ICANN community to participate.

4.2.  Secondary documents relating to

4.1.5.  IAB Statement on the Special-Use Domain Name
      question

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

4.2.1.  Multicast DNS

   Multicast DNS [RFC6762] defines the Multicast DNS protocol, which
   uses the '.LOCAL' Special-Use Top-Level
        ARPA Domain Name.  Section 3
   describes the semantics of "multicast DNS names."  It is

   As part of
   considerable historical importance to note that the -00 version process of
   this document, an individual submission, was published resolving the controversy mentioned in July of
   2001.  This version contains substantially
   Section 4.2.7, the same text IAB issued a statement saying, in section
   3, and was discussed part:

   There is currently no process defined with ICANN for special use
   names to be delegated in the DNSEXT working group at IETF 51 in August
   of 2001[IETF-PRO-51].  The first version of root zone; it has seemed likely to take
   significant effort to create one.  The IAB has noted that .arpa can
   be used "for technical infrastructure established by IETF standards"
   [SDO-IAB-SUDN-REG].

   Given the lack of an established process with ICANN, IETF documents
   cannot reserve names in the root of the DNS namespace if those names
   are to be delegated (that is, used by the DNS protocol).  It would be
   possible to work with ICANN to develop a process for such
   delegations, but the success of that joint work, and the amount of
   time it would take, would still be uncertain.

4.2.  Secondary Documents Relating to the 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' 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
   the document that eventually became RFC 6762, an individual
   submission, was published in July of 2001.  The version posted at
   that time contains substantially the same text in Section 3 as RFC
   6762 did when published and was discussed in the DNSEXT Working Group
   at IETF 51 in August of 2001 [IETF-PRO-51].  The July 2001 draft
   designated
   '.LOCAL.ARPA' '.local.arpa' as the Special-Use Domain Name.  This idea
   was strongly opposed by DNSEXT working group Working Group participants, and as a result
   result, the author eventually switched to using '.LOCAL'. '.local'.

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

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

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

   The .onion '.onion' Special-Use Top-Level Domain Name [RFC7686] is important
   because it is the most recent IETF action on the topic of Special-Use
   Domain Names; although it does not set a 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 it.

   o  Devising a resolution to the situation was constrained by at least
      two factors.  First, there was no process for allocating special-
      use domain names Special-
      Use Domain Names at the time that the .onion '.onion' project started
      using the name, and since name; at the time time, and since the scope of use of the
      name was expected to be very constrained, the developers chose to
      allocate it unilaterally rather than asking the IETF or some other SDO
      Standards Development Organization (SDO) to create a new process.

      Second, for some time, the CA/Browser Forum [SDO-CABF] had been
      issuing certificates for what they referred to as "internal
      names."
      names".  Internal names are names allocated unilaterally for use
      in site-specific contexts.  Issuing certificates for such names
      came to be considered problematic, since no formal process for
      testing the validity of such names existed.  Consequently, the CA/
      Browser Forum decided to phase out the use of such names in
      certificates [SDO-CABF-INT], [SDO-CABF-INT] and set a deadline after which no new
      certificates for such names would be issued [SDO-CABF-DEADLINE].
      Because the .onion '.onion' domain was allocated unilaterally, this would
      mean that certificates for subdomains of .onion '.onion' could no longer
      be issued.

      The IETF's designation of .onion '.onion' as a Special-Use Top-Level
      Domain Name was needed to facilitate the development of a
      certificate issuance process specific to .onion '.onion' domain names
      [SDO-CABF-BALLOT144].

4.2.3.  Locally Served DNS Zones

   Locally

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

   This use case is distinct from the use-case use case for Special-Use Domain
   Names like '.local' and '.onion' in that the names are resolved using
   the DNS protocol (but they 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  It shares the problem that such names cannot
   can be assumed either neither to be unique or to be functional in across all contexts nor
   functional for all Internet-connected hosts.

4.2.4.  Name Collision in the DNS

   Name

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

4.2.5.  SSAC Advisory on the Stability of the Domain Namespace

   The ICANN SSAC ([SDO-ICANN-SSAC]) Security and Stability Advisory Committee (SSAC)
   [SDO-ICANN-SSAC] specification "SSAC Advisory on the Stability of the
   Domain
   Namespace Namespace" [SDO-ICANN-SAC090] reports on some issues
   surrounding the conflicting uses, interested parties parties, and processes
   related to the Domain Namespace.  The document specification 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

   "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis Synthesis"
   [RFC7050] is an example of a document that successfully used the
   process in RFC 6761 process to designate '.ipv4only.arpa' as a Special-Use
   Domain Name; in this case 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" 'ipv4only.arpa' was never added
   to the Special-Use "Special-Use Domain Names Names" registry.  This appears to have
   happened because the document did not explicitly request the addition
   of an entry for "ipv4only.arpa" 'ipv4only.arpa' in the Special-Use "Special-Use Domain Name Names"
   registry.  This is an illustration of one of the problems that we
   have with the 6761 process: process in RFC 6761: it is apparently fairly easy to
   miss the step of adding the name to the registry.

4.2.7.  Additional Reserved Top Level Top-Level Domains

   Additional

   "Additional Reserved Top Level Domains
   [I-D.chapin-additional-reserved-tlds] Domains" [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 the aforementioned document failed to gain consensus to publish, be
   published, the need it was intended to fill still exists.
   Unfortunately, although a fair amount is known about the use of these
   names, no RFC documents exists that describes how they are used, 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, them and when it would not
   make sense to use them.

   RFC 7788 [RFC7788] defines the Top-Level Domain Name TLD ".home" '.home' for use
   as the default name for name resolution relative to a home network
   context.  Although, as defined in RFC 7788, ".home" '.home' is a Special-Use
   Domain Name, RFC 7788 did not follow the process specified in RFC
   6761: it did not request that ".home" '.home' be added to the IANA Special-Use "Special-Use
   Domain
   Name Names" registry.  This was recognized as a mistake, mistake and
   resulted in the
   publication posting of an errata, [ERRATA-4677]. errata report [Err4677].  Additionally, ".home"
   '.home' is an example of an attempt to reuse a Domain Name domain name that has
   already been put into use for other purposes without following
   established
   processes[SDO-ICANN-COLL], processes [SDO-ICANN-COLL], which further complicates the
   situation.  At the time this document [RFCXXXX] was written, the IETF was
   developing a solution to this problem.

5.  History

   Newcomers

   A newcomer to the problem of resolving Domain Names domain names may be under the
   mistaken
   impression that the DNS sprang, as in the Greek legend of
   Athena, sprang fully formed directly from Paul
   Mockapetris' forehead. head (as was the birth of Athena in Greek Mythology).
   This is not the case.  At the time of the writing of the IAB technical document
   ([RFC2826]), was
   written [RFC2826], memories would have been fresh of the evolutionary
   process that led to the DNS' dominance as a protocol for Domain Name 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 Microsystems' Network Information System (NIS)
   [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 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 the NIS or WINS.
   Most have the capability to resolve names using mDNS by recognizing
   the special meaning of the '.local' Special-Use Top Level Top-Level Domain
   Name.

   The Sun Microsystems model of having private domains within a
   corporate site, while supporting the global Domain Name system System for
   off-site, persisted even after the NIS protocol fell into disuse.

   Microsoft used to recommend that site administrators use a "private"
   TLD for internal use, and this practice was very much a part of the
   zeitgeist at the time (see section 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 apparently-unused apparently unused 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
   Domain Names in the IETF often come down to the question of why users
   of new name resolution protocols choose to use Domain Names, 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 using a wide variety of name resolution systems, Domain
   Names 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 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 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 Considerations

   This document has no actions for IANA.

8.  Contributors

   Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron
   Falk and Suzanne Woolf all made helpful and insightful observations
   or patiently answered questions.  This should does not be taken as an
   indication that require any IANA actions.

8.  Informative References

   [CORP-SUN-NIS]
              Wikipedia, "Network Information Service", August 2017,
              <https://en.wikipedia.org/wiki/
              Network_Information_Service>.

   [DOMAIN-NAMES]
              Lewis, E., "Domain Names, A Case for Clarifying", Work in
              Progress, draft-lewis-domain-names-09, August 2017.

   [Err4677]  RFC Errata, "Erratum ID 4677", RFC 7788,
              <https://www.rfc-editor.org/errata/eid4677>.

   [IETF-PRO-51]
              IETF, "Proceedings of these folks actually agree with what the
   document says, but their generosity with time 51st IETF Meeting", August 2001,
              <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.

   [P2P-DOMAIN-NAMES]
              Grothoff, C., Wachs, M., Wolf, H., Ed., Appelbaum, J., and thought are
   appreciated
              L. Ryge, "Special-Use Domain Names of Peer-to-Peer
              Systems", Work in any case.

   Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ
   Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr
   Spacek and others provided significant review Progress, draft-grothoff-iesg-special-
              use-p2p-names-04, January 2015.

   [PROBLEM-SPECIAL-NAMES]
              Huston, G., Koch, P., Durand, A., and / or useful
   comments.

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

9.  RFC Editor Considerations

   The authors were unable to find dates W. Kumari, "Problem
              Statement for references
   [SDO-CABF-DEADLINE] and [SDO-CABF].  Please fix up those references
   as appropriate (and remove this section before publication).

10.  Informative References

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

   [ERRATA-4677]
              Internet Architecture Board, "Errata ID: 4677 (RFC7788)",
              April 2016, <https://www.rfc-editor.org/errata/eid4677>.

   [I-D.chapin-additional-reserved-tlds] the Reservation of Special-Use Domain Names
              using RFC6761", Work in Progress, draft-adpkja-dnsop-
              special-names-problem-06, September 2016.

   [RESERVED-TLDS]
              Chapin, L. and M. McFadden, "Additional Reserved Top Level
              Domains", draft-chapin-additional-reserved-tlds-02 (work Work in progress), Progress, draft-chapin-additional-
              reserved-tlds-02, 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, A Case for Clarifying", draft-
              lewis-domain-names-09 (work in progress), August 2017.

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

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

   [RFC2352]  Vaughan, O., "A Convention For Using Legal Names as Domain
              Names", RFC 2352, DOI 10.17487/RFC2352, May 1998,
              <http://www.rfc-editor.org/info/rfc2352>.
              <https://www.rfc-editor.org/info/rfc2352>.

   [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>. <https://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>.
              <https://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>.
              <https://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>.
              <https://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>. <https://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>.
              <https://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>.
              <https://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>.
              <https://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>.
              <https://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>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc7788>.

   [SDO-CABF]
              CA/Browser Forum, "CA/Browser Forum", ??? ????, Forum Home Page",
              <https://cabforum.org>.

   [SDO-CABF-BALLOT144]
              CA/Browser Forum, "Ballot 144 - Validation Rules for
              .onion Names", February 2015,
              <https://cabforum.org/2015/02/18/ballot-144-validation-
              rules-dot-onion-names>.
              <https://cabforum.org/2015/02/18/
              ballot-144-validation-rules-dot-onion-names>.

   [SDO-CABF-DEADLINE]
              CA/Browser Forum, "SSL Certificates for Internal Server
              Names", ??? ????, <https://www.digicert.com/internal-
              names.htm>. January 2013,
              <https://www.digicert.com/internal-names.htm>.

   [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>.
              <https://cabforum.org/internal-names/>.

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

   [SDO-IAB-SUDN-REG]
              IAB, "Internet Architecture Board statement on the
              registration of special use names in the ARPA domain",
              March 2017, <https://www.iab.org/documents/
              correspondence-reports-documents/2017-2/iab-statement-on-
              the-registration-of-special-use-names-in-the-arpa-
              domain/>.

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

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

   [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>.
              ICANN, "gTLD Applicant Guidebook", Version 2012-06-04,
              June 2012, <https://newgtlds.icann.org/en/applicants/agb/
              guidebook-full-04jun12-en.pdf>.

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

   [SDO-ICANN-SSAC]
              ICANN Security
              ICANN, "Security and Stability Advisory Committee, "SSAC
              Advisory on the Stability of the Domain Namespace", Committee (SSAC)",
              December 2016, <https://www.icann.org/groups/ssac>.

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

Appendix A.  Change Log.

   -06 to -07:

   o  Issue #88: Bulleted list

Contributors

   Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron
   Falk, and Suzanne Woolf all made helpful and insightful observations
   or patiently answered questions.  This should be numbered, not unordered -
      Updated the list of problems to be numbered, instead taken as an
   indication that any of unordered.
      This is to allow future documents to refer to specific issues.

   o  Misc: Removed duplicate word ("that that" -> "that")

   o  Backfilled the "Change Log" to reflect the issues addressed
      between Version -05 and -06.

   -05 to -06:

   o  Issue #87: Section 4.2.2: expand "certs" to "certificates"

   o  Issue #86: Stephane Bortzmeyer: lying DNS resolvers

   o  Issue #85: Stephane Bortzmeyer: unilateral use
   o  Issue #84: Stephane Bortzmeyer: Use of the registry is
      inconsistent

   o  Issue #83: Stephane Bortzmeyer: IETF-ICANN have a liaison
      relationship

   o  Issue #82: Bob Harold: extra "be used"

   o  Issue #81: Editorial changes from Benoit Claise AD review

   o  Issue #80: Section 3 - Clarify citation of SDO-ICANN-COLL

   o  Issue #79: Update reference to "Special-Use Domain Names registry"
      (?)

   o  Issue #78: Section 4.2.7 - add citation of Errata correcting use
      of ".home" in RFC 7788

   o  Issue #77: Section 2 - correct citation of definition of gTLD

   o  Issue #76: Section 3 - clarify that problems are listed regardless
      of validity or ownership,

   o  Issue #74, #75: Meaning versus binding (Andrew McConachie),
      global/local (Andrew McConachie)

   o  Issue #73: Editorial improvements, Section 4.2.7

   -03 to -04:

   o  Issue #72: Corrected original text to reflect that RFC 7050
      neglected to request an SUDN registry entry for "ipv4only.arpa",
      but any inference about the cause for the oversight would be
      speculation.

   o  Issue #69: Edited Joel's suggested text.

   o  Issue #67: Minor change to Joel's suggested text.

   o  Issue #66: Edited second text update suggested by Joel and
      reverted third change back to the original text.

   o  Issue #64: Minor changes to text suggested by Joel.

   o  Issue #61: Minor edit based on authors' consensus in response to
      Joel's comment.

   o  Addressed Joel / Benoit's AD comments.  See GH issues
   -02 to -03 (in Github):

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

   o  Issue #60: Add new section "6.  Summary" -- Petr Spacek
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/60

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

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

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

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

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

   o  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

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

   o  Issue #51: Clarification in Introduction -- John Dickinson
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/51

   o  Issue #49: Should cite https://datatracker.ietf.org/liaison/1351
      -- George Michaelson https://github.com/Abhayakara/draft-tldr-
      sutld-ps/issues/49

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

   o  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
   o  Issue #47: 4.3 should be made more prominent -- George Michaelson
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/47

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

   o  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

   o  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

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

   o  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

   o  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

   o  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

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

   o  Issue #6: Without a process, we just have chaos -- Stuart Cheshire
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/6

   o  Issue #32: Have assignments through RFC 6761 really had "technical
      mistakes"? -- Suzanne Wolff https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/32

   o  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
   o  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

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

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

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

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

   o  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

   o  Issue #18: Cite definition of RFC 7719 folks actually agree with what the
   document says, but their generosity with time and domain names draft thought are
   appreciated in
      definition of "domain name" -- Suzanne Wolff
      https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/18

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

   o  Issue #46: Reformat citation of RFC 2860 -- any case.

   Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ Housley
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/46)

   o  Issue #44: Clean up reference
   Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr
   Spacek, and others provided significant review and/or useful
   comments.

   This document also owes a great deal to SDO-ICANN-DAG in first bullet in
      section 3 -- Russ Housley (https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/44)

   o  Issue #42: Add reference Ed Lewis' excellent work on
   what a "domain name" is [DOMAIN-NAMES].

   We would also like to SDO-ICANN-SAC090 in section 4.2.5 --
      Russ Housley (https://github.com/Abhayakara/draft-tldr-sutld-ps/
      issues/42)

   o  Issue #30: Leaked queries aren't an operational problem in
      practice -- Suzanne Wolf (https://github.com/Abhayakara/draft-
      tldr-sutld-ps/issues/30)

   o  Address some of acknowledge the simpler issues, including:

   o  Issue #13: Spelling of Tor -- Jeremy Rand
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/13)
   o  Issue #14: Change SDO to "organizations" -- Suzanne Woolf
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14)

   o  Issue #16: Match number authors of "policies"
   [PROBLEM-SPECIAL-NAMES], including Alain Durand, Geoff Huston, Peter
   Koch, and "that policy" -- Suzanne
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/16)

   o  Issue #17: Clarify sentence beginning with "In support of Joe Abley, for their efforts to frame the
      particular set of problems described here...." -- Suzanne.
      (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14)

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

   -01 to -02:

   o  Language cleanup from Ted.

   -00 to -01:

   o  Improved engage
   the terminology.

   o  Included reference to SAC090.

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

   o  Improved background.

   o  Noted that semantics may differ between resolution contexts.

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

   o  Readability fixes.

   -04 to ietf-00

   o  Document adopted by WG.

   o  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 working group, as well as their contributions to -02:

   o  Cleaned up the abstract.

   o  Fixed the case list 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.
   issues from their document [PROBLEM-SPECIAL-NAMES].

Authors' Addresses

   Ted Lemon
   Nominum, Inc.
   800 Bridge Parkway
   Redwood City, California CA  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
   United States of America

   Email: warren@kumari.net