draft-ietf-dnsop-sutld-ps-08.txt   rfc8244.txt 
Network Working Group T. Lemon Internet Engineering Task Force (IETF) T. Lemon
Internet-Draft Nominum, Inc. Request for Comments: 8244 Nominum, Inc.
Intended status: Informational R. Droms Category: Informational R. Droms
Expires: February 5, 2018 ISSN: 2070-1721
W. Kumari W. Kumari
Google Google
August 4, 2017 October 2017
Special-Use Domain Names Problem Statement Special-Use Domain Names Problem Statement
draft-ietf-dnsop-sutld-ps-08
Abstract Abstract
The Special-Use Domain Names IANA registry policy defined in RFC 6761 The policy defined in RFC 6761 for IANA registrations in the
has been shown through experience to present unanticipated "Special-Use Domain Names" registry has been shown, through
challenges. This memo presents a list, intended to be comprehensive, experience, to present challenges that were not anticipated when RFC
of the problems that have been identified. In addition it reviews 6761 was written. This memo presents a list, intended to be
the history of Domain Names and summarizes current IETF publications comprehensive, of the problems that have since been identified. In
and some publications from other organizations relating to Special- addition, it reviews the history of domain names and summarizes
Use Domain Names. current IETF publications and some publications from other
organizations relating to Special-Use Domain Names.
Status of This Memo 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.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on February 5, 2018. 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.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problems associated with Special-Use Domain Names . . . . . . 4 3. Problems Associated with Special-Use Domain Names . . . . . . 4
4. Existing Practice Regarding Special-Use Domain Names . . . . 9 4. Existing Practice regarding Special-Use Domain Names . . . . 10
4.1. Primary Special-Use Domain Name Documents . . . . . . . . 10 4.1. Primary Special-Use Domain Name Documents . . . . . . . . 10
4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 10 4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 10
4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 11 4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 12
4.1.3. MoU Concerning the Technical Work of the IANA . . . . 13 4.1.3. MoU Concerning the Technical Work of IANA . . . . . . 13
4.1.4. Liaison Statement on Technical Use of Domain 4.1.4. Liaison Statement on Technical Use of Domain Names . 14
Names . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.5. IAB Statement on the Registration of Special Use
4.2. Secondary documents relating to the Special-Use Names in the ARPA Domain . . . . . . . . . . . . . . 15
Domain Name question . . . . . . . . . . . . . . . . . . 14 4.2. Secondary Documents Relating to the Special-Use Domain
4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 14 Name Question . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. The .onion Special-Use Top-Level Domain Name . . . . 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.3. Locally Served DNS Zones . . . . . . . . . . . . . . 16
4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 16 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 17
4.2.5. SSAC Advisory on the Stability of the Domain 4.2.5. SSAC Advisory on the Stability of the Domain
Namespace . . . . . . . . . . . . . . . . . . . . . . 16 Namespace . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address
Synthesis . . . . . . . . . . . . . . . . . . . . . . 16 Synthesis . . . . . . . . . . . . . . . . . . . . . . 17
4.2.7. Additional Reserved Top Level Domains . . . . . . . . 17 4.2.7. Additional Reserved Top-Level Domains . . . . . . . . 18
5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Informative References . . . . . . . . . . . . . . . . . . . 20
9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 19 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
One of the key services required to use the Internet is name One of the key services required to use the Internet is name
resolution. Name resolution is the process of translating a symbolic resolution. Name resolution is the process of translating a symbolic
name into some object or set of objects to which the name refers, name into some object or set of objects to which the name refers,
most typically one or more IP addresses. These names are often most typically one or more IP addresses. These names are often
referred to as Domain Names. When reading this document, care must 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 be taken not to assume that the term domain name implies the use of
the Domain Name System [RFC1034] for resolving these names. An the Domain Name System [RFC1034] for resolving these names. An
excellent presentation on this topic can be found in Domain Names excellent presentation on this topic can be found in Domain Names
[I-D.lewis-domain-names]. [DOMAIN-NAMES].
Special-Use Domain Names [RFC6761] created an IANA registry for "Special-Use Domain Names" [RFC6761] created the "Special-Use Domain
Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding Names" IANA registry [SDO-IANA-SUDR], defined policies for adding to
to the registry, and made some suggestions about how those policies the registry, and made some suggestions about how those policies
might be implemented. Since the publication of RFC 6761, the IETF might be implemented. Since the publication of RFC 6761, the IETF
has been asked to designate several new Special-Use Domain Names in has been asked to designate several new Special-Use Domain Names in
this registry. During the evaluation process for these Special-Use this registry. During the evaluation process for these Special-Use
Domain Names, the IETF encountered several different sorts of issues. Domain Names, the IETF encountered several different sorts of issues.
Because of this, the IETF has decided to investigate the problem and 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 decide if and how the process defined in RFC 6761 can be improved, or
should be deprecated. The IETF DSNOP working group charter was whether it should be deprecated. The IETF DNSOP Working Group
extended to include conducting a review of the process for adding charter was extended to include conducting a review of the process
names to the registry that is defined in RFC 6761. This document is for adding names to the registry that is defined in RFC 6761. This
a product of that review. document is a product of that review.
Based on current ICANN and IETF practice, including RFC 6761, there Based on current ICANN and IETF practice, including RFC 6761, there
are several different types of names in the root of the Domain are several different types of names in the root of the Domain
Namespace: Namespace:
o Reserved by the IETF for technical purposes o Names reserved by the IETF for technical purposes
o Assigned by ICANN to the public DNS root; some names reserved by o Names assigned by ICANN to the public DNS root; some names
the IETF for technical purposes may appear in the Global DNS root reserved by the IETF for technical purposes may appear in the
for reasons pertaining to the operation of the DNS 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 o ICANN Reserved Names; names that may not be applied for as TLDs
(see [SDO-ICANN-DAG], Section 2.2.1.2.1, Reserved Names, (see "Reserved Names" and "Treatment of Country or Territory
Section 2.2.1.4.1, Treatment of Country or Territory Names, et Names" (Sections 2.2.1.2.1 and 2.2.1.4.1, respectively) of
al.) [SDO-ICANN-DAG]).
o Used by other organizations without following established o Names used by other organizations without following established
processes processes
o Names that are unused and are available for assignment to one of o Names that are unused and are available for assignment to one of
the previous categories the previous categories
This document presents a list, derived from a variety of sources This document presents a list, derived from a variety of sources,
including discussion in the IETF dnsop WG, of the problems associated including discussion in the IETF DNSOP Working Group, of the problems
with the assignment of Special-Use Domain Names. The list is associated with the assignment of Special-Use Domain Names. The list
intended to be an unfiltered compilation of issues. In support of is intended to be an unfiltered compilation of issues. In support of
its analysis of the particular set of issues described here, the its analysis of the particular set of issues described here, the
document also includes descriptions of existing practice as it document also includes descriptions of existing practice as it
relates to the use of domain names, a brief history of domain names, relates to the use of domain names, a brief history of domain names,
and some observations by various IETF participants who have and some observations by various IETF participants who have
experience with various aspects of the current situation. experience with various aspects of the current situation.
2. Terminology 2. Terminology
This document uses the terminology from RFC 7719 [RFC7719]. Other This document uses the terminology from RFC 7719 [RFC7719]. Other
terms used in this document are defined here: terms used in this document are defined here:
Domain Name This document uses the term "Domain Name" as defined in Domain Name: This document uses the term "domain name" as defined in
section 2 of RFC 7719 [RFC7719]. Section 2 of RFC 7719 [RFC7719].
Domain Namespace The set of all possible Domain Names. Domain Namespace: The set of all possible domain names.
Special-Use Domain Name A Domain Name listed in the Special-Use Special-Use Domain Name: A domain name listed in the "Special-Use
Domain Names registry [SDO-IANA-SUDR]. Domain Names" registry [SDO-IANA-SUDR].
For the sake of brevity this document uses some abbreviations, which For the sake of brevity, this document uses some abbreviations, which
are expanded here: are expanded here:
IANA Internet Assigned Numbers Authority IANA: Internet Assigned Numbers Authority
ICANN Internet Corporation for Assigned Names and Numbers ICANN: Internet Corporation for Assigned Names and Numbers
TLD Top-Level Domain, as defined in section 2 of RFC 7719 [RFC7719] 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]) gTLD: Generic Top-Level Domain (see Section 2 of RFC 2352
[RFC2352])
3. Problems associated with Special-Use Domain Names 3. Problems Associated with Special-Use Domain Names
This section presents a list of problems that have been identified This section presents a list of problems that have been identified
with respect to the assignment of Special-Use Domain Names. with respect to the assignment of Special-Use Domain Names.
Solutions to these problems, including their costs or tradeoffs, are Solutions to these problems, including their costs or trade-offs, are
out of scope for this document. They will be covered in a separate out of scope for this document and will be covered in a separate
document. New problems that might be created in the process of document. New problems that might be created in the process of
solving problems described in this document are also out of scope: solving problems described in this document are also out of scope:
these problems are expected to be addressed in the process of these problems are expected to be addressed in the process of
evaluating potential solutions. evaluating potential solutions.
Special-Use Domain Names exist to solve a variety of problems. This Special-Use Domain Names exist to solve a variety of problems. This
document has two goals: enumerate all of the problems that have been document has two goals: enumerate all of the problems that have been
identified to which Special-Use Domain Names are a solution and identified to which Special-Use Domain Names are a solution and
enumerate all of the problems that have been raised in the process of 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 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 may fall into both categories, this document makes no attempt to
categorize the problems. categorize the problems.
There is a broad diversity of opinion about this set of problems. There is a broad diversity of opinion about this set of problems.
Not every participant agrees that each of the problems enumerated in Not every participant agrees that each of the problems enumerated in
this document is actually a problem. This document takes no position this document is actually a problem. This document takes no position
on the relative validity of the various problems that have been on the relative validity of the various problems that have been
enumerated, nor on the organization responsible for addressing each enumerated, nor on the organization responsible for addressing each
individual problem, if it is to be addressed. The sole purposes of individual problem, if it is to be addressed. This document only
the document are to enumerate those problems, provide the reader with enumerates the problems, provides the reader with context for
context for thinking about them and provide a context for future thinking about them, and provides a context for future discussion of
discussion of solutions, regardless of whether such solutions may be solutions, regardless of whether such solutions may work for IETF,
work for IETF, ICANN, IANA or some other group. ICANN, IANA, or some other group.
This is the list of problems. This is not an ordered list, it is The list of problems is not presented in order of importance; numbers
numbered merely to facilitate referencing specific problems: 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 1. Although the IETF and ICANN have a liaison relationship through
which special-use allocations can be discussed, there exists no which special-use allocations can be discussed, there exists no
formal process for coordinating these allocations (see formal process for coordinating these allocations (see
Section 4.1.3). The lack of coordination complicates the Section 4.1.3). The lack of coordination complicates the
management of the root of the Domain Namespace and could lead to management of the root of the Domain Namespace and could lead to
conflicts in name assignments [SDO-ICANN-SAC090]. conflicts in name assignments [SDO-ICANN-SAC090].
2. There is no explicit scoping as to what can constitute a 2. There is no explicit scoping as to what can constitute a
"technical use" [RFC2860] and what cannot, and there is also no "technical use" [RFC2860] and what cannot; there is also no
consensus within the IETF as to what this term means. consensus within the IETF as to what this term means.
3. Not all developers of protocols on the internet agree that 3. Not all developers of protocols on the Internet agree that
authority over the entire Domain Namespace should reside solely authority over the entire Domain Namespace should reside solely
with the IETF and ICANN. with the IETF and ICANN.
4. Although IETF and ICANN nominally have authority over this 4. Although the IETF and ICANN nominally have authority over this
namespace, neither organization can enforce that authority over namespace, neither organization can enforce that authority over
any third party who wants to just start using a subset of the any third party who wants to just start using a subset of the
namespace. Such parties may observe that the IETF has never namespace. Such parties may observe that the IETF has never
asserted control or authority over what protocols are "allowed" asserted control or authority over what protocols are "allowed"
on the internet, and that the principle of "permissionless on the Internet, and that the principle of "permissionless
innovation" suggests there should be a way for people to include innovation" suggests there should be a way for people to include
new uses of domain names in new protocols and applications. new uses of domain names in new protocols and applications.
5. Organizations do in fact sometimes use subsets of the Domain 5. Organizations do in fact sometimes use subsets of the Domain
Namespace without following established processes. Reasons a Namespace without following established processes. Reasons a
third party might do this include: third party might do this include:
1. Unaware that a process exists for assigning such names 1. Lack of knowledge that a process exists for assigning such
names.
2. Intended use is covered by gTLD process [SDO-ICANN-DAG], but 2. Intended use is covered by the gTLD process [SDO-ICANN-DAG],
no gTLD process is ongoing but no gTLD process is ongoing.
3. Intended use is covered by gTLD process, but the third party 3. Intended use is covered by the gTLD process, but the third
doesn't want to pay a fee party doesn't want to pay a fee.
4. Intended use is covered by some IETF process, but the third 4. Intended use is covered by some IETF process, but the third
party doesn't want to follow the process party doesn't want to follow the process.
5. Intended use is covered by ICANN or IETF process, but third 5. Intended use is covered by an ICANN or IETF process, but the
party expects that the outcome will be refusal or non-action third party expects that the outcome will be refusal or non-
action.
6. Unaware that a name intended to be used only locally may 6. Lack of knowledge that a name intended to be used only
nevertheless leak locally may nevertheless leak.
7. Unaware that a name used locally with informal allocation 7. Lack of knowledge that a name used locally with informal
may subsequently be allocated formally, creating operational allocation may subsequently be allocated formally, creating
problems operational problems.
6. There is demand for more than one name resolution protocol for 6. There is demand for more than one name resolution protocol for
Domain Names. Domain Names contain no metadata to indicate domain names. Domain names contain no metadata to indicate
which protocol to use to resolve them. Domain name resolution which protocol to use to resolve them. Domain name resolution
APIs do not provide a way to specify which protocol to use. 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 7. When a Special-Use Domain Name is added to the "Special-Use
Domain Names registry, not all software that processes such Domain Names" registry, not all software that processes such
names will understand the special use of that name. In many names will understand the special use of that name. In many
cases, name resolution software will use the Domain Name System cases, name resolution software will use the Domain Name System
for resolution of names not known to have a special use. for resolution of names not known to have a special use.
Consequently, any such use will result in queries for Special- Consequently, any such use will result in queries for Special-
Use Domain Names being sent to Domain Name System authoritative Use Domain Names being sent to Domain Name System authoritative
servers. These queries may constitute an operational problem servers. These queries may constitute an operational problem
for operators of root zone authoritative name servers. These for operators of root zone authoritative name servers. These
queries may also inadvertently reveal private information queries may also inadvertently reveal private information
through the contents of the query, which is a privacy through the contents of the query, which is a privacy
consideration. consideration.
8. The RFC 6761 process is sufficiently uncertain that some 8. Some protocol developers have assumed that they could not
protocol developers have assumed they could not get a name succeed in getting a name assigned through the IETF using the
assigned; the process of assigning the first new name ('.local') process defined in RFC 6761. This is because when the IETF has
using the RFC 6761 process took more than ten years from attempted to follow the process defined in RFC 6761, it has been
beginning to end: longer by a factor of ten than any other part slow and uncertain. For example, the process of assigning the
of the protocol development process (largely because this ten first new name ('.local') using the process defined in RFC 6761
years included time to develop the process as well as use it). took more than ten years from beginning to end: longer by a
Other uses of the process have proceeded more smoothly, but factor of ten than any other part of the protocol development
there is a reasonably justified perception that using this process (largely because this ten years included time to develop
process is likely to be slow and difficult, with an uncertain the process as well as use it). Other uses of the process have
outcome. 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 9. There is strong resistance within the IETF to assigning domain
Names to resolution systems outside of the DNS, for a variety of names to resolution systems outside of the DNS, for a variety of
reasons: reasons:
1. Requires a mechanism for identifying which of a set of 1. It requires a mechanism for identifying which set of
resolution processes is required in order to resolve a resolution processes is required in order to resolve a
particular name. particular name.
2. Assertion of authority: there is a sense that the Domain 2. Assertion of authority: there is a sense that the Domain
Namespace is "owned" by the IETF or by ICANN, and so, if a Namespace is "owned" by the IETF or by ICANN, so, if a name
name is claimed outside of that process, the person or is claimed without following their processes, the person or
entity that claimed that name should suffer some consequence entity that claimed that name should suffer some consequence
that would, presumably, deter future circumvention of the that would, presumably, deter future circumvention of the
official process. official processes.
3. More than one name resolution protocol is bad, in the sense 3. More than one name resolution protocol is bad, in the sense
that a single protocol is less complicated to implement and that a single protocol is less complicated to implement and
deploy. deploy.
4. The semantics of alternative resolution protocols may differ 4. The semantics of alternative resolution protocols may differ
from the DNS protocol; DNS has the concept of RRtypes; other from the DNS protocol; DNS has the concept of RRtypes,
protocols may not support RRtypes, or may support some whereas other protocols may not support RRtypes or may
entirely different data structuring mechanism. support some entirely different data structuring mechanism.
5. If there is an IETF process through which a TLD can be 5. If there is an IETF process through which a TLD can be
assigned at zero cost other than time, this process will be assigned at zero cost other than time, this process will be
used as an alternative to the more costly process of getting used as an alternative to the more costly process of getting
the name registered through ICANN. the name registered through ICANN.
6. A name might be assigned for a particular purpose when a 6. A name might be assigned for a particular purpose when a
more general use of the name would be more beneficial. more general use of the name would be more beneficial.
7. If the IETF assigns a name that some third party or parties 7. If the IETF assigns a name that some third party or parties
believes belongs to them in some way, the IETF could become believe belongs to them in some way, the IETF could become
embroiled in an expensive dispute with those parties. embroiled in an expensive dispute with those parties.
10. If there were no process for assigning names for technical use 10. If there were no process for assigning names for technical use
through the IETF, there is a concern that protocols that require through the IETF, there is a concern that protocols that require
such names would not be able to get them. such names would not be able to get them.
11. In some cases where the IETF has made assignments through the 11. In some cases where the IETF has made assignments through the
RFC 6761 process, technical mistakes have been made due to process defined in RFC 6761, technical mistakes have been made
misunderstandings as to the actual process that RFC 6761 due to misunderstandings as to the actual process that RFC 6761
specifies (e.g., treating the list of suggested considerations specifies (e.g., treating the list of suggested considerations
for assigning a name as a set of requirements all of which must 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 be met). In other cases, the IETF has made de facto assignments
of Special-Use Domain Names without following the RFC 6761 of Special-Use Domain Names without following the process in RFC
process (see [RFC7050], [RFC7788]). 6761 (see [RFC7050] and [RFC7788]).
12. There are several Domain Name TLDs that are in use without due 12. There are several Top-Level Domain Names that are in use without
process for a variety of purposes. The status of these names due process for a variety of purposes. The status of these
need to be clarified and recorded to avoid future disputes about names need to be clarified and recorded to avoid future disputes
their use [SDO-ICANN-COLL]. about their use [SDO-ICANN-COLL].
13. In principle, the RFC 6761 process could be used to document the 13. In principle, the process defined in RFC 6761 could be used to
existence of Domain Names that are not safe to assign, and document the existence of domain names that are not safe to
provide information on how those names are used in practice. assign and provide information on how those names are used in
However, attempts to use RFC 6761 to accomplish this practice. However, attempts to use RFC 6761 to accomplish this
documentation have not been successful (for example, see documentation have not been successful (for example, see
"Additional Reserved Top Level Domains "Additional Reserved Top Level Domains" [RESERVED-TLDS] and
[I-D.chapin-additional-reserved-tlds] and Section 4.2.7). One Section 4.2.7 of this document). One side effect of the lack of
side effect of the lack of documentation is that any mitigation documentation is that any mitigation effect on the root name
effect on the root name servers or on privacy considerations has servers or on privacy considerations has been missed.
been missed.
14. A Domain Name can be identified as either a DNS name by placing 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 in the DNS zone(s) or a Special-Use Domain Name by adding it
it to the IANA registry. Some names are in both places; for to the IANA registry. Some names are in both places; for
example, some locally served zone names are in DNS zones and example, some locally served zone names are in DNS zones and
documented in the Special-Use Domain Names registry. At documented in the "Special-Use Domain Names" registry. At
present, the only way a Domain Name can be added to the Special- present, the only way a domain name can be added to the
Use Domain Name registry is for the IETF to take responsibility "Special-Use Domain Name" registry is for the IETF to take
for the name and designate it for "technical use". There are responsibility for the name and designate it for "technical
other potential uses for Domain Names that should be recorded in use". There are other potential uses for domain names that
the registry, but for which the IETF should not take should be recorded in the registry, but for which the IETF
responsibility. should not take responsibility.
15. The IETF may in some cases see the need to document that a name 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 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 IETF's particular use of the name. No mechanism exists in the
registry to mark names in this way. current registry to mark names in this way.
16. There is no formal process during any of the review stages for a 16. During any of the review stages of a document, there is no
document in which a check is made to ensure that the document formal process in which a check is made to ensure that the
does not unintentionally violate IETF process for adding document does not unintentionally violate the IETF process for
special-use domain names to the registry, as was the case, for adding Special-Use Domain Names to the registry, as was the
example, in RFC 7788 [RFC7788]. case, for example, in RFC 7788 [RFC7788].
17. Use of the registry is inconsistent -- some Special-Use Domain 17. Use of the registry is inconsistent -- some Special-Use Domain
Name RFCs specifically add registry entries, some don't; some Name RFCs specifically add registry entries, some don't; some
specify how and whether special-use name delegations should be specify how and whether special-use name delegations should be
done, some don't. done, some don't.
18. There exists no safe, non-process-violating mechanism for ad-hoc 18. There exists no safe, non-process-violating mechanism for ad hoc
assignment of Special-Use Domain Names. assignment of Special-Use Domain Names.
19. It is generally assumed that protocols that need a Special-Use 19. It is generally assumed that protocols that need a Special-Use
Domain Name need a mnemonic, single-label, human-readable Domain Name need a mnemonic, single-label, human-readable
Special-Use Domain Name, for use in user interfaces such as Special-Use Domain Name for use in user interfaces such as
command lines or URL entry fields. While this assumption is command lines or URL entry fields. While this assumption is
correct in some cases, it is likely not correct in all cases; correct in some cases, it is likely not correct in all cases,
for example, in applications where the DNS name is never visible for example, in applications where the domain name is never
to a user. visible to a user.
20. RFC 6761 uses the term "Domain Name" to describe the thing for 20. RFC 6761 uses the term "domain name" to describe the thing for
which special uses are registered. This creates a great deal of which special uses are registered. This creates a great deal of
confusion because some readers take "Domain Name" to imply the confusion because some readers take "domain name" to imply the
use of the DNS protocol. use of the DNS protocol.
21. The use of DNSSEC with Special-Use Domain Names is an open 21. The use of DNSSEC with Special-Use Domain Names is an open
issue. There is no consensus or guidance about how to use issue. There is no consensus or guidance about how to use
DNSSEC with various classes of Special-Use Domain Names. DNSSEC with various classes of Special-Use Domain Names.
Considerations in the use of DNSSEC with Special-Use Domain Considerations in the use of DNSSEC with Special-Use Domain
Names include: Names include:
1. What class of Special-Use Domain Name is under 1. What class of Special-Use Domain Name is under
consideration: non-DNS, locally served zone, other? consideration: non-DNS, locally served zone, or other?
2. Does the Special-Use Domain Name require a delegation in the 2. Does the Special-Use Domain Name require a delegation in the
root zone; if so, should that delegation be signed or not? root zone; if so, should that delegation be signed or not?
If there is no delegation, then this will be treated by If there is no delegation, then this will be treated by
validating resolvers as a secure denial of existence for validating resolvers as a secure denial of existence for
that zone. This would not be appropriate for a name being that zone. This would not be appropriate for a name being
resolved using the DNS protocol. resolved using the DNS protocol.
3. A process would be required through which the IETF can cause 3. A process would be required through which the IETF can cause
a delegation in the root zone to be instantiated. a delegation in the root zone to be instantiated.
4. What are the recommended practices for using DNS with the 4. What are the recommended practices for using DNS with the
specific Special-Use Domain Name? specific Special-Use Domain Name?
The problems we have stated here represent the current understanding The above list represents the current understanding of the authors as
of the authors of the document as to the complete set of problems to the complete set of problems that have been identified during
that have been identified during discussion by the working group on discussion by the working group on this topic. The remainder of this
this topic. The remainder of this document provides additional document provides additional context that will be needed for
context that will be needed for reasoning about these problems. reasoning related to these problems.
4. Existing Practice Regarding Special-Use Domain Names 4. Existing Practice regarding Special-Use Domain Names
There are three primary (see Section 4.1) and numerous secondary There are three primary (see Section 4.1) and numerous secondary
(Section 4.2) documents to consider when thinking about the Special- (Section 4.2) documents to consider when thinking about the Special-
Use Domain Names process. Use Domain Names process.
How names are resolved is ambiguous, in the sense that some names are How names are resolved is ambiguous, in the sense that some names are
Special-Use Domain names that require special handling, and some Special-Use Domain Names that require special handling and some names
names can be resolved using the DNS protocol with no special can be resolved using the DNS protocol with no special handling.
handling.
The assignment of Internet Names is not under the sole control of any The assignment of Internet Names is not under the sole control of any
one organization. IETF has authority in some cases, but only with one organization. The IETF has authority in some cases, but only
respect to "technical uses." ICANN at present is the designated with respect to "technical uses". At present, ICANN is the
administrator of the root zone, but generally not of zones other than designated administrator of the root zone; but generally not of zones
the root zone. Neither of these authorities can in any practical other than the root zone. Neither of these authorities can, in any
sense exclude the practice of ad-hoc use of names. Unauthorized use practical sense, exclude the practice of ad hoc use of names.
of domain names can be accomplished by any entity that has control Unauthorized use of domain names can be accomplished by any entity
over one or more name servers or resolvers, in the context of any that has control over one or more name servers or resolvers, in the
hosts and services that entity operates. It can also be accomplished context of any hosts and services that entity operates. It can also
by authors of software who decide that a Special-Use Domain Name is be accomplished by authors of software who decide that a Special-Use
the right way to indicate the use of an alternate resolution Domain Name is the right way to indicate the use of an alternate
mechanism. resolution mechanism.
4.1. Primary Special-Use Domain Name Documents 4.1. Primary Special-Use Domain Name Documents
The primary documents are considered primary because they directly The primary documents are considered primary because they directly
address the IETF's past thoughts on this topic in a general way, and address the IETF's past thoughts on this topic in a general way, and
also because they describe what the IETF does in practice. also because they describe what the IETF does in practice.
4.1.1. IAB Technical Comment on the Unique DNS Root 4.1.1. IAB Technical Comment on the Unique DNS Root
This document [RFC2826] is not an IETF consensus document, and [RFC2826] is not an IETF consensus document, and it appears to have
appears to have been written to address a different problem than the been written to address a different problem than the Special-Use
Special-Use Domain Name problem. However, it speaks directly to Domain Name problem. However, it speaks directly to several of the
several of the key issues that must be considered, and, coming as it key issues that must be considered, and, coming as it does from the
does from the IAB, it is rightly treated as having significant IAB, it is rightly treated as having significant authority despite
authority despite not being an IETF consensus document. not being an IETF consensus document.
This document should be considered required reading for IETF This document should be considered required reading for IETF
participants who wish to express an informed opinion on the topic of participants who wish to express an informed opinion on the topic of
Special-Use Domain Names. The main points that appear relevant to Special-Use Domain Names. The main points that appear relevant to
the Special-Use Domain Names problem are: the Special-Use Domain Names problem are:
o The Internet requires a globally unique namespace: a namespace in o The Internet requires a globally unique namespace: a namespace in
which any given name refers to the same information (has the same which any given name refers to the same information (has the same
meaning) no matter who requests that information and no matter meaning) no matter who requests that information and no matter
from which specific name server they request it. from which specific name server they request it.
o Private networks may operate private namespaces, with names that o Private networks may operate private namespaces, with names that
have meanings only locally (within the private network) but still have meanings only locally (within the private network), but they
require that names in the public namespace be globally unique. still require that names in the public namespace be globally
unique.
o The Domain Name System [RFC1035] is not the only protocol that may o The Domain Name System [RFC1035] is not the only protocol that may
be used for resolving domain names. be used for resolving domain names.
o Users cannot be assumed to know how to distinguish between o Users cannot be assumed to know how to distinguish between
symbolic references that have local meaning and references that symbolic references that have local meaning and references that
have global meaning. Users may therefore share references that have global meaning. Therefore, users may share references that
incorporate Domain Names with no global meaning (for example, a incorporate domain names with no global meaning (for example, a
URL of 'http://mysite.example.corp', where 'example.corp' is a URL of 'http://mysite.example.corp', where 'example.corp' is a
domain used privately and informally as described in domain used privately and informally as described in
[SDO-ICANN-COLL]). [SDO-ICANN-COLL]).
o Such references might refer to the object the user intends to o While such a reference in the user's context refers to the object
share within that user's context, but either refer to some other the user wishes to share, when the reference is used in a
object any recipient's context, or might not refer to any object different context, it could refer either to some different object
at all in a recipient's context. The effect of this reference in the recipient's context or to no object at all. The effect of
escaping the context in which it is valid is that the user's this reference escaping the context in which it is valid is that
intended communication will not be able to be understood by the the user's intended communication will not be able to be
recipients of the communication. understood by the recipients of the communication.
o This same problem can also occur when a single user copies a name 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 from one context in which it has one meaning into a different
context in which it has a different meaning -- for example copying context in which it has a different meaning -- for example,
a '.onion' Domain Name out of a Tor Browser [TOR], where it has copying a '.onion' domain name out of a Tor Browser [TOR], where
meaning, and pasting this name into an ssh client that doesn't it has meaning, and pasting this name into an SSH client that
support connecting over the Tor network. doesn't support connecting over the Tor network.
We can summarize the advice in this document as follows: We can summarize the advice in this document as follows:
o Domain Names with unambiguous global meaning are preferable to o Domain names with unambiguous global meaning are preferable to
Domain Names with local meaning which will be ambiguous. domain names with local meaning that will be ambiguous.
Nevertheless both globally-meaningful and locally-special names Nevertheless, both globally meaningful and locally special names
are in use and must be supported. are in use and must be supported.
o At the time of the writing of this document the IAB was of the 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 opinion that there might well be more than one name resolution
protocol used to resolve Domain Names. protocol used to resolve domain names.
4.1.2. Special-Use Domain Names 4.1.2. Special-Use Domain Names
The second important document is "Special-Use Domain Names" The second important document is "Special-Use Domain Names"
[RFC6761]. RFC 6761 represents the current IETF consensus on [RFC6761]. RFC 6761 represents the current IETF consensus on
designating and recording Special-Use Domain Names. The IETF has designating and recording Special-Use Domain Names. The IETF has
experienced problems with the designation process described in RFC experienced problems with the designation process described in RFC
6761; these concerns motivate this document. Familiarity with RFC 6761; these concerns motivate this document. Familiarity with RFC
6761 is a prerequisite for having an informed opinion on the topic of 6761 is a prerequisite for having an informed opinion on the topic of
Special-Use Domain Names. Special-Use Domain Names.
RFC 6761 defines two aspects of Special-Use Domain Names: designating RFC 6761 defines two aspects of Special-Use Domain Names: designating
a Domain Name to have a special purpose and registering that special a domain name to have a special purpose and registering that special
use in the Special-Use Domain Names registry. The designation use in the "Special-Use Domain Names" registry. The designation
process is defined in a single sentence (RFC 6761, section 4): process is defined in a single sentence (RFC 6761, Section 4):
If it is determined that special handling of a name is required in If it is determined that special handling of a name is required in
order to implement some desired new functionality, then an IETF order to implement some desired new functionality, then an IETF
"Standards Action" or "IESG Approval" specification [RFC5226] MUST "Standards Action" or "IESG Approval" specification [RFC5226] MUST
be published describing the new functionality. be published describing the new functionality.
This sentence requires that any designation of a Special-Use Domain This sentence requires that any designation of a Special-Use Domain
Name is subject to the same open review and consensus process as used Name is subject to the same open review and consensus process as used
to produce and publish all other IETF specifications. to produce and publish all other IETF specifications.
The registration process is a purely mechanical process, in which the The registration process is a purely mechanical process, in which the
existence of the newly designated Special-Use Domain Name is existence of the newly designated Special-Use Domain Name is
recorded, with a pointer to a section in the relevant specification recorded, with a pointer to a section in the relevant specification
document that defines the ways in which special handling is to be document that defines the ways in which special handling is to be
applied to the name. applied to the name.
RFC 6761 provided the process whereby Multicast DNS [RFC6762] RFC 6761 provides the process whereby "Multicast DNS" [RFC6762]
designated ".local" as a Special-Use Domain Name and included it in designated '.local' as a Special-Use Domain Name and included it in
the Special-Use Domain Names registry. It itself also enumerated a the "Special-Use Domain Names" registry. RFC 6761 also enumerates a
set of names that had been previously used or defined to have special set of names that were previously used or defined to have special
uses prior to the publication of RFC 6761. Since there had been no uses prior to its publication. Since there had been no registry for
registry for these names prior to the publication of RFC 6761, the these names prior to the publication of RFC 6761, the documents
documents defining these names could not have added them to the defining these names could not have added them to the registry.
registry.
There are at least several important points to think of with respect Several important points to think about with respect to RFC 6761 are:
to the RFC 6761:
o A Special-Use Domain Name may be a name that should be resolved 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 using the DNS protocol with no special handling. An example of
this is 'IN-ADDR.ARPA.' (which is an example of a Special-Use this is 'in-addr.arpa' (which is an example of a Special-Use
Domain Name that is not a TLD). Domain Name that is not a TLD).
o A Special-Use Domain Name may be a name that is resolved using the o A Special-Use Domain Name may be a name that is resolved using the
DNS protocol, requires no special handling in the stub resolver, DNS protocol and that requires no special handling in the stub
but requires special handling in the recursive resolver. An resolver but that requires special handling in the recursive
example of this would be "10.in-addr.arpa." resolver. An example of this would be '10.in-addr.arpa.'.
o A Special-Use Domain Name may be a name that requires special 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 handling in the stub resolver. An example would be a Special-Use
Top-Level Domain Name like '.local' which acts as a signal to Top-Level Domain Name like '.local', which acts as a signal to
indicate that the local stub resolver should use a non-DNS indicate that the local stub resolver should use a non-DNS
protocol for name resolution. protocol for name resolution.
o The current IETF consensus (from a process perspective, not o The current IETF consensus (from a process perspective, not
necessarily from the perspective of what would be consensus if the necessarily from the perspective of what would be consensus if the
IETF were to attempt to produce a new consensus document) is that IETF were to attempt to produce a new consensus document) is that
all of these purposes for Special-Use Domain Names are valid. all of these purposes for Special-Use Domain Names are valid.
The term "stub resolver" in this case does not mean "DNS protocol In this case, the term "stub resolver" does not mean "DNS protocol
stub resolver." The stub resolver is the entity within a particular stub resolver". The stub resolver is the entity within a particular
software stack that takes a question about a Domain Name and answers 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 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 DNS protocol; however, it is in the stub resolver (as we are using
term here, that the decision as to whether to use a protocol, and if the term here) that the decision as to whether to use a protocol (and
so which protocol, or whether to use a local database of some sort, if so, which protocol) or a local database of some sort is made.
is made.
RFC 6761 does not limit Special-Use Domain Names to TLDs. However, RFC 6761 does not limit Special-Use Domain Names to TLDs. However,
at present, all Special-Use Domain Names registered in the IANA at present, all Special-Use Domain Names registered in the "Special-
Special-Use Domain Names registry [SDO-IANA-SUDR] are either intended Use Domain Names" registry [SDO-IANA-SUDR] either are intended to be
to be resolved using the DNS protocol, or are TLDs, or both. That resolved using the DNS protocol, are TLDs, or are both. That is, at
is, at present there exist no Special-Use Domain Names which require present there exist no Special-Use Domain Names that require special
special handling by stub resolvers and which are not at the top level handling by stub resolvers and which are not at the top level of the
of the naming hierarchy. naming hierarchy.
One point to take from this is that there is already a requirement in 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, 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 'local' as the rightmost label of a domain name, it can only use the
protocol to resolve that Domain Name. Multicast DNS (mDNS) protocol to resolve that domain name.
4.1.3. MoU Concerning the Technical Work of the IANA 4.1.3. MoU Concerning the Technical Work of IANA
There exists a Memorandum of Understanding (MOU) [RFC2860] between There exists a Memorandum of Understanding (MoU) [RFC2860] between
the IETF and ICANN (Internet Corporation for Assigned Names and the IETF and ICANN that discusses how names and numbers will be
Numbers) which discusses how names and numbers will be managed managed through IANA. This document is important to the discussion
through the IANA (Internet Assigned Numbers Authority). This of Special-Use Domain Names because, while it delegates authority for
document is important to the discussion of Special-Use Domain Names managing the DNS Namespace generally to ICANN, it reserves to the
because, while it delegates authority for managing the Domain Name IETF the authority that is then formalized in RFC 6761. RFC 2860
System Namespace generally to ICANN, it reserves to the IETF the specifically states:
authority that RFC 6761 formalizes:
Note that (a) assignments of Domain Names for technical uses (such Note that (a) assignments of domain names for technical uses (such
as Domain Names for inverse DNS lookup), (b) assignments of as domain names for inverse DNS lookup), (b) assignments of
specialised address blocks (such as multicast or anycast blocks), specialised address blocks (such as multicast or anycast blocks),
and (c) experimental assignments are not considered to be policy and (c) experimental assignments are not considered to be policy
issues, and shall remain subject to the provisions of this issues, and shall remain subject to the provisions of this
Section 4. Section 4.
The above text is an addendum to the following: The above text is an addendum to the following:
Two particular assigned spaces present policy issues in addition Two particular assigned spaces present policy issues in addition
to the technical considerations specified by the IETF: the to the technical considerations specified by the IETF: the
assignment of Domain Names, and the assignment of IP address assignment of domain names, and the assignment of IP address
blocks. These policy issues are outside the scope of this MOU. blocks. These policy issues are outside the scope of this MOU.
In general, then, the assignment of names in the DNS root zone, and The assignment of names in the DNS root zone, and the management of
the management of the DNS namespace, is a function that is performed the Domain Namespace, is by default a function that is performed by
by ICANN. However, the MoU specifically exempts domain names ICANN. However, the MoU specifically exempts domain names assigned
assigned for technical use, and uses the example of domains used for for technical use and uses the example of domains used for inverse
inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the DNS lookup. Both 'in-addr.arpa' and 'ip6.arpa' are in the "Special-
Special-Use Domain Names registry. Use Domain Names" registry.
Implicit in the MoU is the fact that the IETF and ICANN retain, Implicit in the MoU is the fact that the IETF and ICANN retain,
between them, sole authority for assigning any names from the Domain between them, sole authority for assigning any names from the Domain
Namespace. Both the IETF and ICANN have internal processes for Namespace. Both the IETF and ICANN have internal processes for
making such assignments. making such assignments.
The point here is not to say what the implications of this statement 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 in the MoU are, but rather to call the reader's attention to the
existence of this statement. existence of this statement.
4.1.4. Liaison Statement on Technical Use of Domain Names 4.1.4. Liaison Statement on Technical Use of Domain Names
When the IETF received processing requests to add names to the When the IETF received processing requests to add names to the
Special-Use Domain Name registry, as documented in "Special-Use Domain Names" registry, as documented in [RESERVED-TLDS]
[I-D.chapin-additional-reserved-tlds] and and [P2P-DOMAIN-NAMES], the IETF chartered a review of the process
[I-D.grothoff-iesg-special-use-p2p-names], the IETF chartered a defined in RFC 6761 for adding names to the registry (as explained
review of the process defined in RFC 6761 for adding names to the earlier). The IETF sent a liaison statement [SDO-IAB-ICANN-LS] to
registry (as explained earlier). The IETF sent a Liaison Statement ICANN to notify them of the review, affirm that the discussion would
[SDO-IAB-ICANN-LS] to ICANN to notify ICANN of the review, affirm be "open and transparent to participation by interested parties", and
that the discussion would be "open and transparent to participation explicitly invite members of the ICANN community to participate.
by interested parties" and explicitly invite members of the ICANN
community to participate.
4.2. Secondary documents relating to the Special-Use Domain Name 4.1.5. IAB Statement on the Registration of Special Use Names in the
question 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 In addition to these documents, there are several others with which
participants in this discussion should be familiar. participants in this discussion should be familiar.
4.2.1. Multicast DNS 4.2.1. Multicast DNS
Multicast DNS [RFC6762] defines the Multicast DNS protocol, which Multicast DNS [RFC6762] defines the Multicast DNS protocol, which
uses the '.LOCAL' Special-Use Top-Level Domain Name. Section 3 uses the '.local' Special-Use Top-Level Domain Name. Section 3
describes the semantics of "multicast DNS names." It is of describes the semantics of "multicast DNS names". It is of
considerable historical importance to note that the -00 version of considerable historical importance to note that the -00 version of
this document, an individual submission, was published in July of the document that eventually became RFC 6762, an individual
2001. This version contains substantially the same text in section submission, was published in July of 2001. The version posted at
3, and was discussed in the DNSEXT working group at IETF 51 in August that time contains substantially the same text in Section 3 as RFC
of 2001[IETF-PRO-51]. The first version of this document designated 6762 did when published and was discussed in the DNSEXT Working Group
'.LOCAL.ARPA' as the Special-Use Domain Name. This idea was strongly at IETF 51 in August of 2001 [IETF-PRO-51]. The July 2001 draft
opposed by DNSEXT working group participants, and as a result the designated '.local.arpa' as the Special-Use Domain Name. This idea
author eventually switched to using '.LOCAL'. 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 The history of RFC 6762 is documented in substantial detail in
Appendix H of RFC 6762; some notable milestones include the initial Appendix H of RFC 6762; some notable milestones include the initial
proposal to replace Appletalk's NBP in July 1997, the chartering of proposal to replace AppleTalk's Name Binding Protocol (NBP) in July
the Zeroconf working group in September 1999, assignment of a 1997, the chartering of the Zeroconf Working Group in September 1999,
multicast address for link-local name discovery in April of 2000. A and the assignment of a multicast address for link-local name
companion requirements document, eventually published as [RFC6760] discovery in April of 2000. A companion requirements document,
was first published in September of 2001. eventually published as [RFC6760], was first published in September
of 2001.
The point of mentioning these dates is so that discussions involving The point of mentioning these dates is so that discussions involving
the time when the '.LOCAL' domain was first deployed, and the context the time when the '.local' domain was first deployed, and the context
in which it was deployed, may be properly informed. in which it was deployed, may be properly informed.
4.2.2. The .onion Special-Use Top-Level Domain Name 4.2.2. The '.onion' Special-Use Top-Level Domain Name
The .onion Special-Use Top-Level Domain Name [RFC7686] is important 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 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 Domain Names; although it does not set a new policy, the mere fact of
its publication is worth thinking about. its publication is worth thinking about.
Two important points to consider about this document are that: Two important points to consider about this document are that:
o The IETF gained consensus to publish it o The IETF gained consensus to publish it.
o Devising a resolution to the situation was constrained by at least o Devising a resolution to the situation was constrained by at least
two factors. First, there was no process for allocating special- two factors. First, there was no process for allocating Special-
use domain names at the time that the .onion project started using Use Domain Names at the time that the '.onion' project started
the name, and since at the time the scope of use of the name was using the name; at the time, and since the scope of use of the
expected to be very constrained, the developers chose to allocate name was expected to be very constrained, the developers chose to
it unilaterally rather than asking the IETF or some other SDO to allocate it unilaterally rather than asking the IETF or some other
create a new process. Standards Development Organization (SDO) to create a new process.
Second, for some time, the CA/Browser Forum [SDO-CABF] had been Second, for some time, the CA/Browser Forum [SDO-CABF] had been
issuing certificates for what they referred to as "internal issuing certificates for what they referred to as "internal
names." Internal names are names allocated unilaterally for use names". Internal names are names allocated unilaterally for use
in site-specific contexts. Issuing certificates for such names in site-specific contexts. Issuing certificates for such names
came to be considered problematic, since no formal process for came to be considered problematic, since no formal process for
testing the validity of such names existed. Consequently, CA/ testing the validity of such names existed. Consequently, the CA/
Browser Forum decided to phase out the use of such names in 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 [SDO-CABF-INT] and set a deadline after which no new
certificates for such names would be issued [SDO-CABF-DEADLINE]. certificates for such names would be issued [SDO-CABF-DEADLINE].
Because the .onion domain was allocated unilaterally, this would Because the '.onion' domain was allocated unilaterally, this would
mean that certificates for subdomains of .onion could no longer be mean that certificates for subdomains of '.onion' could no longer
issued. be issued.
The IETF's designation of .onion as a Special-Use Top-Level Domain The IETF's designation of '.onion' as a Special-Use Top-Level
Name was needed to facilitate the development of a certificate Domain Name was needed to facilitate the development of a
issuance process specific to .onion domain names certificate issuance process specific to '.onion' domain names
[SDO-CABF-BALLOT144]. [SDO-CABF-BALLOT144].
4.2.3. Locally Served DNS Zones 4.2.3. Locally Served DNS Zones
Locally Served DNS Zones [RFC6303] describes a particular use case "Locally Served DNS Zones" [RFC6303] describes a particular use case
for zones that exist by definition, and that are resolved using the for zones that exist by definition and that are resolved using the
DNS protocol, but that cannot have a global meaning, because the host DNS protocol, but that cannot have a global meaning because the host
IP addresses they reference are not unique. This applies to a IP addresses they reference are not unique. This applies to a
variety of addresses, including Private IPv4 addresses [RFC1918], variety of addresses, including private IPv4 addresses [RFC1918],
Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice "Unique Local IPv6 Unicast Addresses" [RFC4193] (in which this
was first described) and IANA-Reserved IPv4 Prefix for Shared Address practice was first described), and "IANA-Reserved IPv4 Prefix for
Space [RFC6598]. Shared Address Space" [RFC6598].
This use case is distinct from the use-case for Special-Use Domain 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 Names like '.local' and '.onion' in that the names are resolved using
the DNS protocol (but do require extensions or exceptions to the the DNS protocol (but they do require extensions or exceptions to the
usual DNS resolution to enforce resolution in a local context rather usual DNS resolution to enforce resolution in a local context rather
than the global DNS context). But it shares the problem that such than the global DNS context). It shares the problem that such names
names cannot be assumed either to be unique or to be functional in can be assumed neither to be unique across all contexts nor
all contexts for all Internet-connected hosts. functional for all Internet-connected hosts.
4.2.4. Name Collision in the DNS 4.2.4. Name Collision in the DNS
Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by "Name Collision in the DNS" [SDO-ICANN-COLL] is a study that was
ICANN that attempts to characterize the potential risk to the commissioned by ICANN in an attempt to characterize the potential
Internet of adding global DNS delegations for names that were not risk to the Internet of adding global DNS delegations for names that
previously delegated in the DNS, not reserved under any RFC, but also were not previously delegated in the DNS and were not reserved under
known to be (.home) or surmised to be (.corp) in significant use for any RFC, but were also known to be (in the case of '.home') or
Special-Use-type reasons (local scope DNS, or other resolution surmised to be (in the case of '.corp') in significant use for
Special-Use-type reasons (local scope DNS or other resolution
protocols altogether). protocols altogether).
4.2.5. SSAC Advisory on the Stability of the Domain Namespace 4.2.5. SSAC Advisory on the Stability of the Domain Namespace
ICANN SSAC ([SDO-ICANN-SSAC]) Advisory on the Stability of the Domain The ICANN Security and Stability Advisory Committee (SSAC)
Namespace [SDO-ICANN-SAC090] reports on some issues surrounding the [SDO-ICANN-SSAC] specification "SSAC Advisory on the Stability of the
conflicting uses, interested parties and processes related to the Domain Namespace" [SDO-ICANN-SAC090] reports on some issues
Domain Namespace. The document recommends the development of surrounding the conflicting uses, interested parties, and processes
collaborative processes among the various interested parties to related to the Domain Namespace. The specification recommends the
coordinate their activities related to the Domain Namespace. 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 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
[RFC7050] is an example of a document that successfully used the RFC [RFC7050] is an example of a document that successfully used the
6761 process to designate '.ipv4only.arpa' as a Special-Use Domain process in RFC 6761 to designate '.ipv4only.arpa' as a Special-Use
Name; in this case the process worked smoothly and without Domain Name; in this case, the process worked smoothly and without
controversy. controversy.
Unfortunately, while the IETF process worked smoothly, in the sense Unfortunately, while the IETF process worked smoothly, in the sense
that there was little controversy or delay in approving the new use, that there was little controversy or delay in approving the new use,
it did not work correctly: the name "ipv4only.arpa" was never added it did not work correctly: the name 'ipv4only.arpa' was never added
to the Special-Use Domain Names registry. This appears to have to the "Special-Use Domain Names" registry. This appears to have
happened because the document did not explicitly request the addition happened because the document did not explicitly request the addition
of an entry for "ipv4only.arpa" in the Special-Use Domain Name of an entry for 'ipv4only.arpa' in the "Special-Use Domain Names"
registry. This is an illustration of one of the problems that we 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 have with the process in RFC 6761: it is apparently fairly easy to
step of adding the name to the registry. miss the step of adding the name to the registry.
4.2.7. Additional Reserved Top Level Domains 4.2.7. Additional Reserved Top-Level Domains
Additional Reserved Top Level Domains "Additional Reserved Top Level Domains" [RESERVED-TLDS] is an example
[I-D.chapin-additional-reserved-tlds] is an example of a document of a document that attempted to reserve several TLDs identified by
that attempted to reserve several TLDs identified by ICANN as ICANN as particularly at risk for collision as Special-Use Domain
particularly at risk for collision as Special-Use Domain Names with Names with no documented use. This attempt failed.
no documented use. This attempt failed.
Although this document failed to gain consensus to publish, the need Although the aforementioned document failed to gain consensus to be
it was intended to fill still exists. Unfortunately, although a fair published, the need it was intended to fill still exists.
amount is known about the use of these names, no RFC documents how Unfortunately, although a fair amount is known about the use of these
they are used, and why it would be a problem to delegate them. names, no RFC exists that describes how they are used and why it
Additionally, to the extent that the uses being made of these names would be a problem to delegate them. Additionally, to the extent
are valid, no document exists indicating when it might make sense to that the uses being made of these names are valid, no document exists
use them, and when it would not make sense to use them. 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 RFC 7788 [RFC7788] defines the Top-Level Domain Name '.home' for use
default name for name resolution relative to a home network context. as the default name for name resolution relative to a home network
Although, as defined in RFC 7788, ".home" is a Special-Use Domain context. Although, as defined in RFC 7788, '.home' is a Special-Use
Name, RFC 7788 did not follow the process specified in RFC 6761: it Domain Name, RFC 7788 did not follow the process specified in RFC
did not request that ".home" be added to the IANA Special-Use Domain 6761: it did not request that '.home' be added to the "Special-Use
Name registry. This was recognized as a mistake, and resulted in the Domain Names" registry. This was recognized as a mistake and
publication of an errata, [ERRATA-4677]. Additionally, ".home" is an resulted in the posting of an errata report [Err4677]. Additionally,
example of an attempt to reuse a Domain Name that has already been '.home' is an example of an attempt to reuse a domain name that has
put into use for other purposes without following established already been put into use for other purposes without following
processes[SDO-ICANN-COLL], which further complicates the situation. established processes [SDO-ICANN-COLL], which further complicates the
At the time this document was written, the IETF was developing a situation. At the time RFC 8244 was written, the IETF was developing
solution to this problem. a solution to this problem.
5. History 5. History
Newcomers to the problem of resolving Domain Names may be under the A newcomer to the problem of resolving domain names may be under the
mistaken impression that the DNS sprang, as in the Greek legend of impression that the DNS sprang fully formed directly from Paul
Athena, directly from Paul Mockapetris' forehead. This is not the Mockapetris' head (as was the birth of Athena in Greek Mythology).
case. At the time of the writing of the IAB technical document This is not the case. At the time the IAB technical document was
([RFC2826]), memories would have been fresh of the evolutionary written [RFC2826], memories would have been fresh of the evolutionary
process that led to the DNS' dominance as a protocol for Domain Name process that led to DNS' dominance as a protocol for domain name
resolution. resolution.
In fact, in the early days of the Internet, hostnames were resolved In fact, in the early days of the Internet, hostnames were resolved
using a text file, HOSTS.TXT, which was maintained by a central using a text file, HOSTS.TXT, which was maintained by a central
authority, the Network Information Center, and distributed to all authority, the Network Information Center, and distributed to all
hosts on the Internet using the File Transfer Protocol (FTP) hosts on the Internet using the File Transfer Protocol (FTP)
[RFC0959]. The inefficiency of this process is cited as a reason for
the development of the DNS [RFC0882] [RFC0883] in 1983. [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. However, the transition from HOSTS.TXT to the DNS was not smooth.
For example, Sun Microsystems's Network Information System For example, Sun Microsystems' Network Information System (NIS)
[CORP-SUN-NIS], at the time known as Yellow Pages, was an active [CORP-SUN-NIS], at the time known as Yellow Pages, was an active
competitor to the DNS, although it failed to provide a complete competitor to the DNS, although it failed to provide a complete
solution to the global naming problem. solution to the global naming problem.
Another example was NetBIOS Name Service, also known as WINS Another example was NetBIOS Name Service, also known as WINS
[RFC1002]. This protocol was used mostly by Microsoft Windows [RFC1002]. This protocol was used mostly by Microsoft Windows
machines, but also by open source BSD and Linux operating systems to machines, but also by open-source BSD and Linux operating systems to
do name resolution using Microsoft's own name resolution protocol. do name resolution using Microsoft's own name resolution protocol.
Most modern operating systems can still use the '/etc/hosts' file for Most modern operating systems can still use the '/etc/hosts' file for
name resolution. Many still have a name service switch that can be name resolution. Many still have a name service switch that can be
configured on the host to resolve some domains using NIS or WINS. configured on the host to resolve some domains using the NIS or WINS.
Most have the capability to resolve names using mDNS by recognizing Most have the capability to resolve names using mDNS by recognizing
the special meaning of the '.local' Special-Use Top Level Domain the special meaning of the '.local' Special-Use Top-Level Domain
Name. Name.
The Sun Microsystems model of having private domains within a The Sun Microsystems model of having private domains within a
corporate site, while supporting the global Domain Name system for corporate site, while supporting the global Domain Name System for
off-site, persisted even after the NIS protocol fell into disuse. off-site, persisted even after the NIS protocol fell into disuse.
Microsoft used to recommend that site administrators use a "private" Microsoft used to recommend that site administrators use a "private"
TLD for internal use, and this practice was very much a part of the 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 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 Appendix G of [RFC6762]). This attitude is at the root of the
widespread practice of simply picking an apparently-unused TLD and widespread practice of simply picking an apparently unused TLD and
using it for experimental purposes, which persists even at the time using it for experimental purposes, which persists even at the time
of writing of this memo. of writing of this memo.
This history is being presented because discussions about Special-Use This history is being presented because discussions about Special-Use
Domain Names in the IETF often come down to the question of why users 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 of new name resolution protocols choose to use domain names rather
than using some other naming concept that doesn't overlap with the than using some other naming concept that doesn't overlap with the
namespace that, in modern times is, by default, resolved using the namespace that, in modern times is, by default, resolved using the
DNS. DNS.
The answer is that as a consequence of this long history of resolving The answer is that as a consequence of this long history of resolving
Domain Names using a wide variety of name resolution systems, Domain domain names using a wide variety of name resolution systems, domain
Names are required in a large variety of contexts in user interfaces names are required in a large variety of contexts in user interfaces
and applications programming interfaces. Any name that appears in and applications programming interfaces. Any name that appears in
such a context is a Domain Name. So developers of new name such a context is a domain name. So, developers of new name
resolution systems that must work in existing contexts actually have resolution systems that must work in existing contexts actually have
no choice: they must use a Special-Use Domain Name to segregate a no choice: they must use a Special-Use Domain Name to segregate a
portion of the namespace for use with their system. portion of the namespace for use with their system.
6. Security Considerations 6. Security Considerations
This document mentions various security and privacy considerations in This document mentions various security and privacy considerations in
the text. However, this document creates no new security or privacy the text. However, this document creates no new security or privacy
concerns. concerns.
7. IANA considerations 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 [I-D.lewis-domain-names].
9. RFC Editor Considerations
The authors were unable to find dates for references This document does not require any IANA actions.
[SDO-CABF-DEADLINE] and [SDO-CABF]. Please fix up those references
as appropriate (and remove this section before publication).
10. Informative References 8. Informative References
[CORP-SUN-NIS] [CORP-SUN-NIS]
Sun Microsystems, "Large System and Network Wikipedia, "Network Information Service", August 2017,
Administration", March 1990. <https://en.wikipedia.org/wiki/
Network_Information_Service>.
[ERRATA-4677] [DOMAIN-NAMES]
Internet Architecture Board, "Errata ID: 4677 (RFC7788)", Lewis, E., "Domain Names, A Case for Clarifying", Work in
April 2016, <https://www.rfc-editor.org/errata/eid4677>. Progress, draft-lewis-domain-names-09, August 2017.
[I-D.chapin-additional-reserved-tlds] [Err4677] RFC Errata, "Erratum ID 4677", RFC 7788,
Chapin, L. and M. McFadden, "Additional Reserved Top Level <https://www.rfc-editor.org/errata/eid4677>.
Domains", draft-chapin-additional-reserved-tlds-02 (work
in progress), March 2015.
[I-D.grothoff-iesg-special-use-p2p-names] [IETF-PRO-51]
Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and 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 L. Ryge, "Special-Use Domain Names of Peer-to-Peer
Systems", draft-grothoff-iesg-special-use-p2p-names-04 Systems", Work in Progress, draft-grothoff-iesg-special-
(work in progress), January 2015. use-p2p-names-04, January 2015.
[I-D.lewis-domain-names] [PROBLEM-SPECIAL-NAMES]
Lewis, E., "Domain Names, A Case for Clarifying", draft- Huston, G., Koch, P., Durand, A., and W. Kumari, "Problem
lewis-domain-names-09 (work in progress), August 2017. Statement for the Reservation of Special-Use Domain Names
using RFC6761", Work in Progress, draft-adpkja-dnsop-
special-names-problem-06, September 2016.
[IETF-PRO-51] [RESERVED-TLDS]
Internet Engineering Task Force, "Proceedings of the 51st Chapin, L. and M. McFadden, "Additional Reserved Top Level
IETF", August 2001, Domains", Work in Progress, draft-chapin-additional-
<http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>. reserved-tlds-02, March 2015.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", [RFC882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983, RFC 882, DOI 10.17487/RFC0882, November 1983,
<http://www.rfc-editor.org/info/rfc882>. <https://www.rfc-editor.org/info/rfc882>.
[RFC0883] Mockapetris, P., "Domain names: Implementation [RFC883] Mockapetris, P., "Domain names: Implementation
specification", RFC 883, DOI 10.17487/RFC0883, November specification", RFC 883, DOI 10.17487/RFC0883, November
1983, <http://www.rfc-editor.org/info/rfc883>. 1983, <https://www.rfc-editor.org/info/rfc883>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<http://www.rfc-editor.org/info/rfc959>. <https://www.rfc-editor.org/info/rfc959>.
[RFC1002] NetBIOS Working Group in the Defense Advanced Research [RFC1002] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, and End-to-End Projects Agency, Internet Activities Board, and End-to-End
Services Task Force, "Protocol standard for a NetBIOS Services Task Force, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed specifications", service on a TCP/UDP transport: Detailed specifications",
STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987,
<http://www.rfc-editor.org/info/rfc1002>. <https://www.rfc-editor.org/info/rfc1002>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain [RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain
Names", RFC 2352, DOI 10.17487/RFC2352, May 1998, Names", RFC 2352, DOI 10.17487/RFC2352, May 1998,
<http://www.rfc-editor.org/info/rfc2352>. <https://www.rfc-editor.org/info/rfc2352>.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the [RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
2000, <http://www.rfc-editor.org/info/rfc2826>. 2000, <https://www.rfc-editor.org/info/rfc2826>.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, Internet Assigned Numbers Authority", RFC 2860,
DOI 10.17487/RFC2860, June 2000, DOI 10.17487/RFC2860, June 2000,
<http://www.rfc-editor.org/info/rfc2860>. <https://www.rfc-editor.org/info/rfc2860>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011, RFC 6303, DOI 10.17487/RFC6303, July 2011,
<http://www.rfc-editor.org/info/rfc6303>. <https://www.rfc-editor.org/info/rfc6303>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
2012, <http://www.rfc-editor.org/info/rfc6598>. 2012, <https://www.rfc-editor.org/info/rfc6598>.
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
to Replace the AppleTalk Name Binding Protocol (NBP)", to Replace the AppleTalk Name Binding Protocol (NBP)",
RFC 6760, DOI 10.17487/RFC6760, February 2013, RFC 6760, DOI 10.17487/RFC6760, February 2013,
<http://www.rfc-editor.org/info/rfc6760>. <https://www.rfc-editor.org/info/rfc6760>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013, RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>. <https://www.rfc-editor.org/info/rfc6761>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013, RFC 7050, DOI 10.17487/RFC7050, November 2013,
<http://www.rfc-editor.org/info/rfc7050>. <https://www.rfc-editor.org/info/rfc7050>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <http://www.rfc-editor.org/info/rfc7686>. 2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>. 2015, <https://www.rfc-editor.org/info/rfc7719>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <http://www.rfc-editor.org/info/rfc7788>. 2016, <https://www.rfc-editor.org/info/rfc7788>.
[SDO-CABF] [SDO-CABF] CA/Browser Forum, "CA/Browser Forum Home Page",
CA/Browser Forum, "CA/Browser Forum", ??? ????,
<https://cabforum.org>. <https://cabforum.org>.
[SDO-CABF-BALLOT144] [SDO-CABF-BALLOT144]
CA/Browser Forum, "Ballot 144 - Validation Rules for CA/Browser Forum, "Ballot 144 - Validation Rules for
.onion Names", February 2015, .onion Names", February 2015, <https://cabforum.org/2015/
<https://cabforum.org/2015/02/18/ballot-144-validation- 02/18/ballot-144-validation-rules-dot-onion-names>.
rules-dot-onion-names>.
[SDO-CABF-DEADLINE] [SDO-CABF-DEADLINE]
CA/Browser Forum, "SSL Certificates for Internal Server CA/Browser Forum, "SSL Certificates for Internal Server
Names", ??? ????, <https://www.digicert.com/internal- Names", January 2013,
names.htm>. <https://www.digicert.com/internal-names.htm>.
[SDO-CABF-INT] [SDO-CABF-INT]
CA/Browser Forum, "Guidance on the Deprecation of Internal CA/Browser Forum, "Guidance on the Deprecation of Internal
Server Names and Reserved IP Addresses", June 2012, Server Names and Reserved IP Addresses", June 2012,
<https://www.digicert.com/internal-names.htm>. <https://cabforum.org/internal-names/>.
[SDO-IAB-ICANN-LS] [SDO-IAB-ICANN-LS]
Internet Architecture Board, "Liaison Statement from the IETF, "Liaison Statement from the IAB to the ICANN Board
IAB to the ICANN Board on Technical Use of Domain Names", on Technical Use of Domain Names", September 2014,
September 2015, <https://datatracker.ietf.org/ <https://datatracker.ietf.org/liaison/1351>.
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] [SDO-IANA-SUDR]
Internet Assigned Numbers Authority, "Special-Use Domain IANA, "Special-Use Domain Names", <http://www.iana.org/
Names registry", October 2015, assignments/special-use-domain-names>.
<http://www.iana.org/assignments/special-use-domain-names/
special-use-domain-names.xhtml>.
[SDO-ICANN-COLL] [SDO-ICANN-COLL]
Interisle Consulting Group, LLC, "Name Collisions in the Interisle Consulting Group, LLC, "Name Collision in the
DNS", August 2013, DNS", Version 1.5, August 2013, <https://www.icann.org/
<https://www.icann.org/en/system/files/files/name- en/system/files/files/name-collision-02aug13-en.pdf>.
collision-02aug13-en.pdf>.
[SDO-ICANN-DAG] [SDO-ICANN-DAG]
Internet Assigned Numbers Authority, "Special-Use Domain ICANN, "gTLD Applicant Guidebook", Version 2012-06-04,
Names registry", October 2015, June 2012, <https://newgtlds.icann.org/en/applicants/agb/
<https://newgtlds.icann.org/en/applicants/agb/guidebook- guidebook-full-04jun12-en.pdf>.
full-04jun12-en.pdf>.
[SDO-ICANN-SAC090] [SDO-ICANN-SAC090]
ICANN Security and Stability Advisory Committee, "SSAC ICANN Security and Stability Advisory Committee, "SSAC
Advisory on the Stability of the Domain Namespace", Advisory on the Stability of the Domain Namespace",
December 2016, ICANN SAC090, December 2016, <https://www.icann.org/en/
<https://www.icann.org/en/system/files/files/sac- system/files/files/sac-090-en.pdf>.
090-en.pdf>.
[SDO-ICANN-SSAC] [SDO-ICANN-SSAC]
ICANN Security and Stability Advisory Committee, "SSAC ICANN, "Security and Stability Advisory Committee (SSAC)",
Advisory on the Stability of the Domain Namespace",
December 2016, <https://www.icann.org/groups/ssac>. December 2016, <https://www.icann.org/groups/ssac>.
[TOR] The Tor Project, "Tor", 2017, [TOR] Tor, "Tor - Anonymity Online",
<https://www.torproject.org>. <https://www.torproject.org>.
Appendix A. Change Log. Contributors
-06 to -07:
o Issue #88: Bulleted list should be numbered, not unordered -
Updated the list of problems to be numbered, instead of unordered.
This is to allow future documents to refer to specific issues.
o Misc: Removed duplicate word ("that that" -> "that")
o Backfilled the "Change Log" to reflect the issues addressed
between Version -05 and -06.
-05 to -06:
o Issue #87: Section 4.2.2: expand "certs" to "certificates"
o Issue #86: Stephane Bortzmeyer: lying DNS resolvers
o Issue #85: Stephane Bortzmeyer: unilateral use
o Issue #84: Stephane Bortzmeyer: Use of the registry is
inconsistent
o Issue #83: Stephane Bortzmeyer: IETF-ICANN have a liaison
relationship
o Issue #82: Bob Harold: extra "be used"
o Issue #81: Editorial changes from Benoit Claise AD review
o Issue #80: Section 3 - Clarify citation of SDO-ICANN-COLL
o Issue #79: Update reference to "Special-Use Domain Names registry"
(?)
o Issue #78: Section 4.2.7 - add citation of Errata correcting use
of ".home" in RFC 7788
o Issue #77: Section 2 - correct citation of definition of gTLD
o Issue #76: Section 3 - clarify that problems are listed regardless
of validity or ownership,
o Issue #74, #75: Meaning versus binding (Andrew McConachie),
global/local (Andrew McConachie)
o Issue #73: Editorial improvements, Section 4.2.7
-03 to -04:
o Issue #72: Corrected original text to reflect that RFC 7050
neglected to request an SUDN registry entry for "ipv4only.arpa",
but any inference about the cause for the oversight would be
speculation.
o Issue #69: Edited Joel's suggested text.
o Issue #67: Minor change to Joel's suggested text.
o Issue #66: Edited second text update suggested by Joel and
reverted third change back to the original text.
o Issue #64: Minor changes to text suggested by Joel.
o Issue #61: Minor edit based on authors' consensus in response to
Joel's comment.
o Addressed Joel / Benoit's AD comments. See GH issues
-02 to -03 (in Github):
o Passes idnits except for errors resulting from a reference to an
RFC 2119 keyword and a citation of RFC 5226 with no matching
reference in quoted text at line 493.
o Issue #60: Add new section "6. Summary" -- Petr Spacek
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/60
o Issue #57: Document needs an "Security Considerations" section
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/57
o Numerous editorial changes for consistency; e.g. use "Special-Use
Domain Names" throughout.
o Issue #58: Document needs an "IANA Considerations" section
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/58
o Issue #39: Overlapping bullets in Section 3, with proposed
restructuring -- Russ Housley https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/39
o Issue #55: Editorial improvement to Section 3 (4) -- John
Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/55
o Issue #34: Separate two problems in paragraph that begins "No
mechanism exists for adding a name to the registry...." (2 issues)
-- Suzanne Woolf https://github.com/Abhayakara/draft-tldr-sutld-
ps/issues/34
o Issue #52: Editorial improvement to Section 3 (1) -- John
Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/52
o Issue #51: Clarification in Introduction -- John Dickinson
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/51
o Issue #49: Should cite https://datatracker.ietf.org/liaison/1351
-- George Michaelson https://github.com/Abhayakara/draft-tldr-
sutld-ps/issues/49
o Issue #50: IETF precedence in Special-Use names registry -- Ted
Lemon https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/50
o Issue #48: 4.1.2 cites sub-domains of .ARPA arguing for special
use TLD -- George Michaelson https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/48
o Issue #47: 4.3 should be made more prominent -- George Michaelson
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/47
o Issue #43: Spell out SUDN and SUTLDN rather than use acronyms --
Russ Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/43
o Issue #41: Reword bullet in Section 3 regarding Domain Name TLDs
that have been commandeered, as reported in SDO-ICANN-COLL -- Russ
Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/41
o Issue #40: Note that time to publish spec for .local included
inventing SUDN registry -- Russ Housley
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/41
o Issue #37: Title should be "Special-Use Domain Names Problem
Statement" -- Russ Housley https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/37
o Issue #36: Expand on desire for Special-Use names to be human-
readable -- Suzanne Woolf https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/36
o Issue #35: Clarify "No process exists [...]" to include both IETF
process and other process -- Suzanne Woolf
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/35
o Issue #31: Add justification for concern about IETF's ability to
assign names for technical use -- Suzanne Woolf
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/31
o Issue #12: Add DNSSEC to text -- John Levine
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/12
o Issue #6: Without a process, we just have chaos -- Stuart Cheshire
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/6
o Issue #32: Have assignments through RFC 6761 really had "technical
mistakes"? -- Suzanne Wolff https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/32
o Issue #29: Add a reason to bypass external process: expectation
for use of new name to be restricted to local scope -- Suzanne
Wolff https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/29
o Issue #27: Is "technical use" really ambiguous; too inclusive for
some people and too limited for others -- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/27
o Issue #24: Replacement for "commandeer" (2 issues)-- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/24
o Issue #22: Clarify importance of the "root of the Domain
Namespace" -- Suzanne Wolff https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/22
o Issue #21: Section 3 - clarify paragraphs 2 and 3 -- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/21
o Issue #20: Section 3: Clarify sentences beginning "Solutions to
these problems..." -- Suzanne Wolff https://github.com/Abhayakara/
draft-tldr-sutld-ps/issues/20
o Issue #19: Define "default" or "assumed" use of domain names to be
within DNS -- Suzanne Wolff https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/19
o Issue #18: Cite definition of RFC 7719 and domain names draft in
definition of "domain name" -- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/18
o Issue #45: Correct usages of Tor Browser and Tor -- Russ Housley
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/45)
o Issue #46: Reformat citation of RFC 2860 -- Russ Housley
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/46)
o Issue #44: Clean up reference to SDO-ICANN-DAG in first bullet in
section 3 -- Russ Housley (https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/44)
o Issue #42: Add reference to SDO-ICANN-SAC090 in section 4.2.5 --
Russ Housley (https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/42)
o Issue #30: Leaked queries aren't an operational problem in
practice -- Suzanne Wolf (https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/30)
o Address some of the simpler issues, including:
o Issue #13: Spelling of Tor -- Jeremy Rand
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/13)
o Issue #14: Change SDO to "organizations" -- Suzanne Woolf
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14)
o Issue #16: Match number of "policies" and "that policy" -- Suzanne
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/16)
o Issue #17: Clarify sentence beginning with "In support of the
particular set of problems described here...." -- Suzanne.
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14)
o Issue #23: Match number of "names" and "a TLD" -- Suzanne.
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/23)
-01 to -02:
o Language cleanup from Ted.
-00 to -01:
o Improved the terminology.
o Included reference to SAC090.
o Added ICANN Reserved Names (e.g .icann, .iesg, .arin) to types of
names.
o Improved background.
o Noted that semantics may differ between resolution contexts.
o Pointer to .home / .corp / .mail, other "toxic" names
o Readability fixes.
-04 to ietf-00
o Document adopted by WG.
o Significant changes from CfA integrated, please refer to diff.
-03 to -04:
o Replaced 'Internet Names' with 'Domain Names' - suggestion by John
Levine.
-02 to -03:
o Readability fixes, small grammar updates.
-01 to -02:
o Cleaned up the abstract.
o Fixed the case of Internet
o Reference to Ed Lewis' "Domain Names" 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.
o Fleshed out the problems, primarily the coordination, collisions Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ
ones. Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr
Spacek, and others provided significant review and/or useful
comments.
-00 to -01: This document also owes a great deal to Ed Lewis' excellent work on
what a "domain name" is [DOMAIN-NAMES].
o Large refactoring, basically a rewrite. Incorporated comments, We would also like to acknowledge the authors of
removed a bunch of unneeded text, etc. [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].
Authors' Addresses Authors' Addresses
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
800 Bridge Parkway 800 Bridge Parkway
Redwood City, California 94065 Redwood City, CA 94065
United States of America United States of America
Phone: +1 650 381 6000 Phone: +1 650 381 6000
Email: ted.lemon@nominum.com Email: ted.lemon@nominum.com
Ralph Droms Ralph Droms
Email: rdroms.ietf@gmail.com Email: rdroms.ietf@gmail.com
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US United States of America
Email: warren@kumari.net Email: warren@kumari.net
 End of changes. 195 change blocks. 
771 lines changed or deleted 525 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/