Network Working Group T. Lemon
Internet-Draft Nominum, Inc.
Intended status: Informational R. Droms
Expires: February 5, 2018
W. Kumari
Google
August 4, 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 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.

Status of This Memo

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

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

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 5, 2018.

Copyright Notice

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

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


Table of Contents

1. Introduction

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

Special-Use Domain Names created an IANA registry for Special-Use Domain Names, 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 RFC 6761 process can be improved, or whether it should be deprecated. The IETF DSNOP 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:

This document presents a list, derived from a variety of sources including discussion in the IETF dnsop WG, 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. 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.
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
gTLD
Generic Top-Level Domain (see section 2 of RFC 2352)

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 tradeoffs, are out of scope for this document. They 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 document are to enumerate those problems, provide the reader with context for thinking about them and provide a context for future discussion of solutions, regardless of whether such solutions may be work for IETF, ICANN, IANA or some other group.

This is the list of problems. This is not an ordered list, it is numbered merely to facilitate referencing specific problems:

  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.
  2. There is no explicit scoping as to what can constitute a "technical use" and what cannot, and 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 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.
  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 that a process exists for assigning such names
    2. Intended use is covered by gTLD process [SDO-ICANN-DAG], but no gTLD process is ongoing
    3. Intended use is covered by 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 ICANN or IETF process, but third party expects that the outcome will be refusal or non-action
    6. Unaware that a name intended to be used only locally may nevertheless leak
    7. Unaware 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.
  8. The RFC 6761 process is sufficiently uncertain that some protocol developers have assumed they could not get a name assigned; the process of assigning the first new name ('.local') using the RFC 6761 process took more than ten years from beginning to end: longer by a factor of ten than any other part of the protocol development process (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. 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, the person or entity that claimed that name should suffer some consequence that would, presumably, deter future circumvention of the official process.
    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; 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.
    7. If the IETF assigns a name that some third party or parties believes belongs to them in some way, the IETF could become embroiled in an expensive dispute with those parties.
  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 RFC 6761 process, 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 RFC 6761 process (see [RFC7050], [RFC7788]).
  12. There are several Domain Name TLDs 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 RFC 6761 process could be used to document the existence of Domain Names that are not safe to assign, and provide information on how those names are used in practice. However, attempts to use RFC 6761 to accomplish this documentation have not been successful (for example, see "Additional Reserved Top Level Domains [I-D.chapin-additional-reserved-tlds] and Section 4.2.7). 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 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 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. The IETF may in some cases see the need to document that a name is in use without claiming that the use of the name is the IETF's use of the name. No mechanism exists in the current registry to mark names in this way.
  16. There is no formal process during any of the review stages for a document in which a check is made to ensure that the document does not unintentionally violate 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 DNS 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, 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 the current understanding of the authors of the document as to the complete set of problems that have been identified during discussion by the working group on this topic. The remainder of this document provides additional context that will be needed for reasoning about these problems.

4. Existing Practice Regarding 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. IETF has authority in some cases, but only with respect to "technical uses." ICANN at present is the designated administrator of the root zone, but generally not of zones other than the root zone. 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

This document is not an IETF consensus document, and appears to have been written to address a different problem than the Special-Use Domain Name problem. However, it speaks directly to several of the key issues that must be considered, and, 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:

We can summarize the advice in this document as follows:

4.1.2. Special-Use Domain Names

The second important document is "Special-Use Domain Names". 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):

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 the process whereby Multicast DNS designated ".local" as a Special-Use Domain Name and included it in the Special-Use Domain Names registry. It itself also enumerated a set of names that had been previously used or defined to have special uses prior to the publication of RFC 6761. Since there had been no registry for these names prior to the publication of RFC 6761, the documents defining these names could not have added them to the registry.

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

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

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 Domain Names registry are either intended to be resolved using the DNS protocol, or are TLDs, or both. That is, at present there exist no Special-Use Domain Names which require special handling by stub resolvers and which are not at the top level of the naming hierarchy.

One point to take from this is that there is already a requirement in RFC 6762 that when a stub resolver encounters the special label, '.LOCAL' at the top level of a domain name, it can only use the mDNS protocol to resolve that Domain Name.

4.1.3. MoU Concerning the Technical Work of the IANA

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

The above text is an addendum to the following:

In general, then, the assignment of names in the DNS root zone, and the management of the DNS namespace, is a function that is performed by ICANN. However, the MoU specifically exempts domain names assigned for technical use, and uses the example of domains used for inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the Special-Use 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 Name registry, as documented in [I-D.chapin-additional-reserved-tlds] and [I-D.grothoff-iesg-special-use-p2p-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 ICANN 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.

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 this document, an individual submission, was published in July of 2001. This version contains substantially the same text in section 3, and was discussed in the DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51]. The first version of this document designated '.LOCAL.ARPA' as the Special-Use 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 NBP in July 1997, the chartering of the Zeroconf working group in September 1999, assignment of a multicast address for link-local name discovery in April of 2000. A companion requirements document, eventually published as [RFC6760] was first published in September of 2001.

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

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

The .onion Special-Use Top-Level Domain Name is important because it is the most recent IETF action on the topic of Special-Use Domain Names; although it does not set new policy, the mere fact of its publication is worth thinking about.

Two important points to consider about this document are that:

4.2.3. Locally Served DNS Zones

Locally Served DNS Zones 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, Unique Local IPv6 Unicast Addresses (in which this practice was first described) and IANA-Reserved IPv4 Prefix for Shared Address Space.

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 do require extensions or exceptions to the usual DNS resolution to enforce resolution in a local context rather than the global DNS context). But it shares the problem that such names cannot be assumed either to be unique or to be functional in all contexts for all Internet-connected hosts.

4.2.4. Name Collision in the DNS

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

4.2.5. SSAC Advisory on the Stability of the Domain Namespace

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

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

Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis is an example of a document that successfully used the RFC 6761 process 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 Name registry. This is an illustration of one of the problems that we have with the 6761 process: it is apparently fairly easy to miss the step of adding the name to the registry.

4.2.7. Additional Reserved Top Level Domains

Additional Reserved Top Level Domains is an example of a document that attempted to reserve several TLDs identified by ICANN as particularly at risk for collision as Special-Use Domain Names with no documented use. This attempt failed.

Although this document failed to gain consensus to publish, the need it was intended to fill still exists. Unfortunately, although a fair amount is known about the use of these names, no RFC documents how they are used, and why it would be a problem to delegate them. Additionally, to the extent that the uses being made of these names are valid, no document exists indicating when it might make sense to use them, and when it would not make sense to use them.

RFC 7788 [RFC7788] defines the Domain Name TLD ".home" for use as the default name for name resolution relative to a home network context. Although, as defined in RFC 7788, ".home" is a Special-Use Domain Name, RFC 7788 did not follow the process specified in RFC 6761: it did not request that ".home" be added to the IANA Special-Use Domain Name registry. This was recognized as a mistake, and resulted in the publication of an errata, [ERRATA-4677]. 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 this document was written, the IETF was developing a solution to this problem.

5. History

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

In fact, in the early days of the Internet, hostnames were resolved using a text file, HOSTS.TXT, which was maintained by a central authority, the Network Information Center, and distributed to all hosts on the Internet using the File Transfer Protocol (FTP). The inefficiency of this process is cited as a reason for the development of the DNS [RFC0883] in 1983.

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

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

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

6. Security Considerations

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

7. IANA considerations

This document has no actions for IANA.

8. Contributors

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.

9. RFC Editor Considerations

The authors were unable to find dates 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.
[I-D.chapin-additional-reserved-tlds] Chapin, L. and M. McFadden, "Additional Reserved Top Level Domains", Internet-Draft 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", Internet-Draft draft-grothoff-iesg-special-use-p2p-names-04, January 2015.
[I-D.lewis-domain-names] Lewis, E., "Domain Names, A Case for Clarifying", Internet-Draft draft-lewis-domain-names-09, August 2017.
[IETF-PRO-51] Internet Engineering Task Force, "Proceedings of the 51st IETF", August 2001.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983.
[RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985.
[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.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.
[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.
[RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain Names", RFC 2352, DOI 10.17487/RFC2352, May 1998.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000.
[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.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011.
[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.
[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.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013.
[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.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015.
[RFC7719] Hoffman, P., Sullivan, A. and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015.
[RFC7788] Stenberg, M., Barth, S. and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016.
[SDO-CABF] CA/Browser Forum, "CA/Browser Forum", ??? ????.
[SDO-CABF-BALLOT144] CA/Browser Forum, "Ballot 144 - Validation Rules for .onion Names", February 2015.
[SDO-CABF-DEADLINE] CA/Browser Forum, "SSL Certificates for Internal Server Names", ??? ????.
[SDO-CABF-INT] CA/Browser Forum, "Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses", June 2012.
[SDO-IAB-ICANN-LS] Internet Architecture Board, "Liaison Statement from the IAB to the ICANN Board on Technical Use of Domain Names", September 2015.
[SDO-IANA-SUDR] Internet Assigned Numbers Authority, "Special-Use Domain Names registry", October 2015.
[SDO-ICANN-COLL] Interisle Consulting Group, LLC, "Name Collisions in the DNS", August 2013.
[SDO-ICANN-DAG] Internet Assigned Numbers Authority, "Special-Use Domain Names registry", October 2015.
[SDO-ICANN-SAC090] ICANN Security and Stability Advisory Committee, "SSAC Advisory on the Stability of the Domain Namespace", December 2016.
[SDO-ICANN-SSAC] ICANN Security and Stability Advisory Committee, "SSAC Advisory on the Stability of the Domain Namespace", December 2016.
[TOR] The Tor Project, "Tor", 2017.

Appendix A. Change Log.

-06 to -07:

-05 to -06:

-03 to -04:

-02 to -03 (in Github):

-01 to -02:

-00 to -01:

-04 to ietf-00

-03 to -04:

-02 to -03:

-01 to -02:

-00 to -01:

Authors' Addresses

Ted Lemon Nominum, Inc. 800 Bridge Parkway Redwood City, California 94065 United States of America Phone: +1 650 381 6000 EMail: ted.lemon@nominum.com
Ralph Droms EMail: rdroms.ietf@gmail.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA, 94043 US EMail: warren@kumari.net