summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8244.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8244.txt')
-rw-r--r--doc/rfc/rfc8244.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc8244.txt b/doc/rfc/rfc8244.txt
new file mode 100644
index 0000000..e3aec34
--- /dev/null
+++ b/doc/rfc/rfc8244.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) T. Lemon
+Request for Comments: 8244 Nominum, Inc.
+Category: Informational R. Droms
+ISSN: 2070-1721
+ W. Kumari
+ Google
+ October 2017
+
+
+ Special-Use Domain Names Problem Statement
+
+Abstract
+
+ The policy defined in RFC 6761 for IANA registrations in the
+ "Special-Use Domain Names" registry has been shown, through
+ experience, to present 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, it reviews the history of domain names and summarizes
+ current IETF publications and some publications from other
+ organizations relating to 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 document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of 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 candidate for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8244.
+
+
+
+
+
+
+
+
+
+
+Lemon, et al. Informational [Page 1]
+
+RFC 8244 Special-Use Domain Names Problem October 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
+ (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 . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Problems Associated with Special-Use Domain Names . . . . . . 4
+ 4. Existing Practice regarding Special-Use Domain Names . . . . 10
+ 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 . . . . . . . . . . . . . . 12
+ 4.1.3. MoU Concerning the Technical Work of 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 . . . . . . . . . . . . . . 15
+ 4.2. Secondary Documents Relating to the Special-Use Domain
+ Name Question . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 15
+ 4.2.2. The '.onion' Special-Use Top-Level Domain Name . . . 16
+ 4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 16
+ 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 17
+ 4.2.5. SSAC Advisory on the Stability of the Domain
+ Namespace . . . . . . . . . . . . . . . . . . . . . . 17
+ 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address
+ Synthesis . . . . . . . . . . . . . . . . . . . . . . 17
+ 4.2.7. Additional Reserved Top-Level Domains . . . . . . . . 18
+ 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
+ 8. Informative References . . . . . . . . . . . . . . . . . . . 20
+ Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
+
+
+
+
+
+
+Lemon, et al. Informational [Page 2]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+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 not to assume that the term 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
+ [DOMAIN-NAMES].
+
+ "Special-Use Domain Names" [RFC6761] created the "Special-Use Domain
+ Names" IANA registry [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 can be improved, or
+ whether it should be deprecated. The IETF 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 Names reserved by the IETF for technical purposes
+
+ o Names assigned by ICANN to the public DNS root; some names
+ reserved by the 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 may not be applied for as TLDs
+ (see "Reserved Names" and "Treatment of Country or Territory
+ Names" (Sections 2.2.1.2.1 and 2.2.1.4.1, respectively) of
+ [SDO-ICANN-DAG]).
+
+ o 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
+
+
+
+
+
+Lemon, et al. Informational [Page 3]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ This document presents a list, derived from a variety of sources,
+ including discussion in the IETF 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: This document uses the term "domain name" as defined in
+ Section 2 of RFC 7719 [RFC7719].
+
+ Domain Namespace: The set of all possible domain names.
+
+ Special-Use Domain Name: A domain name listed in the "Special-Use
+ Domain Names" registry [SDO-IANA-SUDR].
+
+ 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 Section 2 of RFC 7719
+ [RFC7719]
+
+ gTLD: Generic Top-Level Domain (see Section 2 of RFC 2352
+ [RFC2352])
+
+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 Domain Names.
+ Solutions to these problems, including their costs or trade-offs, are
+ out of scope for this 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.
+
+
+
+
+
+Lemon, et al. Informational [Page 4]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ 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. This document only
+ enumerates the problems, provides the reader with context for
+ thinking about them, and provides a context for future discussion of
+ solutions, regardless of whether such solutions may work for IETF,
+ ICANN, IANA, or some other group.
+
+ The list of problems is not presented in order of importance; numbers
+ are assigned so that each problem can easily be referenced by number,
+ not to 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; there is also no
+ consensus within the IETF as to what this term means.
+
+ 3. Not all developers of protocols on the 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, 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.
+
+
+
+
+
+Lemon, et al. Informational [Page 5]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ 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. Lack of knowledge that a process exists for assigning such
+ names.
+
+ 2. Intended use is covered by the gTLD process [SDO-ICANN-DAG],
+ but no gTLD process is ongoing.
+
+ 3. Intended use is covered by the gTLD process, but the third
+ party doesn't want to pay a fee.
+
+ 4. Intended use is covered by some IETF process, but the third
+ party doesn't want to follow the 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.
+
+ 6. Lack of knowledge that a name intended to be used only
+ locally may nevertheless leak.
+
+ 7. Lack of knowledge that a name used locally with informal
+ allocation may subsequently be allocated formally, creating
+ operational problems.
+
+ 6. There is demand for more than one name resolution protocol for
+ domain 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.
+
+ 7. When a Special-Use Domain Name is added to the "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 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.
+
+
+
+
+
+
+
+Lemon, et al. Informational [Page 6]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ 8. Some protocol developers have assumed that they could not
+ succeed in getting a name 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
+ 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 to resolution systems outside of the DNS, for a variety of
+ reasons:
+
+ 1. It requires a mechanism for identifying which 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, so, if a name
+ is claimed 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 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,
+ whereas other protocols may not support 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.
+
+
+
+
+
+
+Lemon, et al. Informational [Page 7]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ 7. If the IETF assigns a name that some third party or parties
+ 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, 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, 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 (see [RFC7050] and [RFC7788]).
+
+ 12. There are several Top-Level Domain 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 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 RFC 6761 to accomplish this
+ documentation have not been successful (for example, see
+ "Additional Reserved Top Level Domains" [RESERVED-TLDS] and
+ Section 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 can be identified as either a DNS name by placing
+ it in the DNS zone(s) or 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 Domain Names" registry. At
+ present, the only way a domain name can be added to the
+ "Special-Use Domain 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 that
+ should be recorded in the registry, but for which the IETF
+ should not take responsibility.
+
+ 15. In some cases, the IETF may 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.
+
+
+
+Lemon, et al. Informational [Page 8]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ 16. During any of the review stages of a 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 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
+ 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 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,
+ for example, in applications where the domain name is never
+ visible to a user.
+
+ 20. 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.
+
+ 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?
+
+
+
+Lemon, et al. Informational [Page 9]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ The above list represents the current understanding of the authors 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 related to these problems.
+
+4. Existing Practice 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 that require special 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". At present, ICANN is the
+ designated administrator of the root zone; but generally not of zones
+ other than the root zone. Neither of these authorities can, in any
+ practical sense, exclude the practice of 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
+
+ [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:
+
+
+
+Lemon, et al. Informational [Page 10]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ 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), 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. Therefore, users may 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 While such a reference in the user's context refers to the object
+ the user wishes to share, when the reference is used in a
+ different context, it could refer either to some different object
+ in the recipient's context or to no object at 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.
+
+ This same problem can also occur when 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], where
+ it has meaning, and pasting this name into an SSH client that
+ doesn't support connecting over the Tor network.
+
+ We can summarize the advice in this document as follows:
+
+ o Domain names with unambiguous global meaning are preferable to
+ domain names with local meaning that 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.
+
+
+
+
+
+Lemon, et al. Informational [Page 11]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+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 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 (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 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 provides the process whereby "Multicast DNS" [RFC6762]
+ designated '.local' as a Special-Use Domain Name and included it in
+ the "Special-Use Domain Names" registry. RFC 6761 also enumerates a
+ set of names that were previously used or defined to have special
+ uses prior to 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.
+
+ Several important points to think about with respect to RFC 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' (which is an example of a Special-Use
+ Domain Name that is not a TLD).
+
+
+
+
+
+
+
+Lemon, et al. Informational [Page 12]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ o A Special-Use Domain Name may be a name that is resolved using the
+ DNS protocol and that requires no special handling in the stub
+ resolver but that requires special handling in the recursive
+ resolver. An example of this would be '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', 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.
+
+ In this case, the term "stub resolver" 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; however, 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 a local database of some 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 "Special-
+ Use Domain Names" registry [SDO-IANA-SUDR] either are intended to be
+ resolved using the DNS protocol, are TLDs, or are both. That is, at
+ present there exist no Special-Use Domain Names 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' as the rightmost label of a domain name, it can only use the
+ Multicast DNS (mDNS) protocol to resolve that domain name.
+
+4.1.3. MoU Concerning the Technical Work of IANA
+
+ There exists a Memorandum of Understanding (MoU) [RFC2860] between
+ the IETF and ICANN that discusses how names and numbers will be
+ managed through IANA. This document is important to the discussion
+ of Special-Use Domain Names because, while it delegates authority for
+ managing the DNS Namespace generally to ICANN, it reserves to the
+ IETF the authority that is then formalized in RFC 6761. RFC 2860
+ specifically states:
+
+
+
+
+
+Lemon, et al. Informational [Page 13]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ 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.
+
+ The assignment of names in the DNS root zone, and the management of
+ the Domain Namespace, is by default 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 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
+
+ When the IETF received processing requests to add names to the
+ "Special-Use Domain Names" registry, as documented in [RESERVED-TLDS]
+ and [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 [SDO-IAB-ICANN-LS] to
+ ICANN to notify them of the review, affirm that the discussion would
+ be "open and transparent to participation by interested parties", and
+ explicitly invite members of the ICANN community to participate.
+
+
+
+
+
+
+
+
+
+
+
+Lemon, et al. Informational [Page 14]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+4.1.5. IAB Statement on the Registration of Special Use Names in the
+ ARPA Domain
+
+ As part of the process of resolving the controversy mentioned in
+ Section 4.2.7, the IAB issued a statement saying, in part:
+
+ There is currently no process defined with ICANN for special use
+ names to be delegated in the 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' as the 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 of RFC 6762; some notable milestones include the initial
+ proposal to replace AppleTalk's Name Binding Protocol (NBP) in July
+ 1997, the chartering of the Zeroconf 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], was first published in September
+ of 2001.
+
+
+
+Lemon, et al. Informational [Page 15]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ 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 Top-Level Domain Name
+
+ The '.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.
+
+ 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 at the time that the '.onion' project started
+ using the name; at the 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
+ 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". 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] and set a deadline after which no new
+ certificates for such names would be issued [SDO-CABF-DEADLINE].
+ Because the '.onion' domain was allocated unilaterally, this would
+ mean that certificates for subdomains of '.onion' could no longer
+ be issued.
+
+ The IETF's designation of '.onion' as a Special-Use Top-Level
+ Domain Name was needed to facilitate the development of a
+ certificate issuance process specific to '.onion' domain names
+ [SDO-CABF-BALLOT144].
+
+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],
+
+
+
+Lemon, et al. Informational [Page 16]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ "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 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). It shares the problem that such names
+ can be assumed neither to be unique across all contexts nor
+ functional for all Internet-connected hosts.
+
+4.2.4. Name Collision in the DNS
+
+ "Name Collision in the DNS" [SDO-ICANN-COLL] is a study that was
+ commissioned by ICANN 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 and were not reserved under
+ any RFC, but were also known to be (in the case of '.home') or
+ surmised to be (in the case of '.corp') in significant use for
+ Special-Use-type reasons (local scope DNS or other resolution
+ protocols altogether).
+
+4.2.5. SSAC Advisory on the Stability of the Domain Namespace
+
+ The ICANN Security and Stability Advisory Committee (SSAC)
+ [SDO-ICANN-SSAC] specification "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 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 of the IPv6 Prefix Used for IPv6 Address Synthesis"
+ [RFC7050] is an example of a document that successfully used the
+ process in RFC 6761 to designate '.ipv4only.arpa' as a 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 Domain Names" registry. This appears to have
+ happened because the document did not explicitly request the addition
+ of an entry for 'ipv4only.arpa' in the "Special-Use Domain Names"
+
+
+
+Lemon, et al. Informational [Page 17]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ registry. This is an illustration of one of the problems that we
+ have with the 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 Domains
+
+ "Additional Reserved Top Level 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 the aforementioned document failed to gain consensus to 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 exists that describes 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 Top-Level Domain Name '.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
+ Domain Name, RFC 7788 did not follow the process specified in RFC
+ 6761: it did not request that '.home' be added to the "Special-Use
+ Domain Names" registry. This was recognized as a mistake and
+ resulted in the posting of an errata report [Err4677]. Additionally,
+ '.home' is an example of an attempt to reuse a domain name that has
+ already been put into use for other purposes without following
+ established processes [SDO-ICANN-COLL], which further complicates the
+ situation. At the time RFC 8244 was written, the IETF was developing
+ a solution to this problem.
+
+5. History
+
+ A newcomer to the problem of resolving domain names may be under the
+ impression that the DNS sprang fully formed directly from Paul
+ Mockapetris' head (as was the birth of Athena in Greek Mythology).
+ This is not the case. At the time the IAB technical document was
+ written [RFC2826], memories would have been fresh of the evolutionary
+ process that led to 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)
+
+
+
+
+Lemon, et al. Informational [Page 18]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ [RFC959]. The inefficiency of this process is cited as a reason for
+ the development of the DNS [RFC882] [RFC883] in 1983.
+
+ However, the transition from HOSTS.TXT to the DNS was not smooth.
+ For example, Sun 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 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 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"
+ 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 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 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 Domain Name to segregate a
+ portion of the namespace for use with their system.
+
+
+
+
+Lemon, et al. Informational [Page 19]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+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 does not 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 the 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
+ L. Ryge, "Special-Use Domain Names of Peer-to-Peer
+ Systems", Work in Progress, draft-grothoff-iesg-special-
+ use-p2p-names-04, January 2015.
+
+ [PROBLEM-SPECIAL-NAMES]
+ Huston, G., Koch, P., Durand, A., and W. Kumari, "Problem
+ Statement for 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", Work in Progress, draft-chapin-additional-
+ reserved-tlds-02, March 2015.
+
+
+
+
+
+
+
+Lemon, et al. Informational [Page 20]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ [RFC882] Mockapetris, P., "Domain names: Concepts and facilities",
+ RFC 882, DOI 10.17487/RFC0882, November 1983,
+ <https://www.rfc-editor.org/info/rfc882>.
+
+ [RFC883] Mockapetris, P., "Domain names: Implementation
+ specification", RFC 883, DOI 10.17487/RFC0883, November
+ 1983, <https://www.rfc-editor.org/info/rfc883>.
+
+ [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",
+ STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
+ <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,
+ <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,
+ <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, <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,
+ <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,
+ <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, <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,
+ <https://www.rfc-editor.org/info/rfc2860>.
+
+
+
+
+
+
+Lemon, et al. Informational [Page 21]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
+ <https://www.rfc-editor.org/info/rfc4193>.
+
+ [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
+ RFC 6303, DOI 10.17487/RFC6303, July 2011,
+ <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, <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,
+ <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,
+ <https://www.rfc-editor.org/info/rfc6761>.
+
+ [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
+ DOI 10.17487/RFC6762, February 2013,
+ <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,
+ <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, <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, <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, <https://www.rfc-editor.org/info/rfc7788>.
+
+ [SDO-CABF] CA/Browser Forum, "CA/Browser Forum Home Page",
+ <https://cabforum.org>.
+
+
+
+
+
+
+Lemon, et al. Informational [Page 22]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ [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>.
+
+ [SDO-CABF-DEADLINE]
+ CA/Browser Forum, "SSL Certificates for Internal Server
+ Names", 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://cabforum.org/internal-names/>.
+
+ [SDO-IAB-ICANN-LS]
+ IETF, "Liaison Statement from the IAB to the ICANN Board
+ on Technical Use of Domain Names", September 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]
+ IANA, "Special-Use Domain Names", <http://www.iana.org/
+ assignments/special-use-domain-names>.
+
+ [SDO-ICANN-COLL]
+ Interisle Consulting Group, LLC, "Name Collision in the
+ DNS", Version 1.5, August 2013, <https://www.icann.org/
+ en/system/files/files/name-collision-02aug13-en.pdf>.
+
+ [SDO-ICANN-DAG]
+ 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>.
+
+
+
+
+Lemon, et al. Informational [Page 23]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+ [SDO-ICANN-SSAC]
+ ICANN, "Security and Stability Advisory Committee (SSAC)",
+ December 2016, <https://www.icann.org/groups/ssac>.
+
+ [TOR] Tor, "Tor - Anonymity Online",
+ <https://www.torproject.org>.
+
+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 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.
+
+ Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ
+ 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 Ed Lewis' excellent work on
+ what a "domain name" is [DOMAIN-NAMES].
+
+ We would also like to acknowledge the authors of
+ [PROBLEM-SPECIAL-NAMES], including Alain Durand, Geoff Huston, Peter
+ Koch, and Joe Abley, for their efforts to frame the issues and engage
+ the working group, as well as their contributions to the list of
+ issues from their document [PROBLEM-SPECIAL-NAMES].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lemon, et al. Informational [Page 24]
+
+RFC 8244 Special-Use Domain Names Problem October 2017
+
+
+Authors' Addresses
+
+ Ted Lemon
+ Nominum, Inc.
+ 800 Bridge Parkway
+ Redwood City, 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
+ United States of America
+
+ Email: warren@kumari.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lemon, et al. Informational [Page 25]
+