draft-ietf-dnsop-sutld-ps-07.txt   draft-ietf-dnsop-sutld-ps-08.txt 
Network Working Group T. Lemon Network Working Group T. Lemon
Internet-Draft Nominum, Inc. Internet-Draft Nominum, Inc.
Intended status: Informational R. Droms Intended status: Informational R. Droms
Expires: January 4, 2018 Expires: February 5, 2018
W. Kumari W. Kumari
Google Google
July 3, 2017 August 4, 2017
Special-Use Domain Names Problem Statement Special-Use Domain Names Problem Statement
draft-ietf-dnsop-sutld-ps-07 draft-ietf-dnsop-sutld-ps-08
Abstract Abstract
The Special-Use Domain Names IANA registry policy defined in RFC 6761 The Special-Use Domain Names IANA registry policy defined in RFC 6761
has been shown through experience to present unanticipated has been shown through experience to present unanticipated
challenges. This memo presents a list, intended to be comprehensive, challenges. This memo presents a list, intended to be comprehensive,
of the problems that have been identified. In addition it reviews of the problems that have been identified. In addition it reviews
the history of Domain Names and summarizes current IETF publications the history of Domain Names and summarizes current IETF publications
and some publications from other organizations relating to Special- and some publications from other organizations relating to Special-
Use Domain Names. Use Domain Names.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on February 5, 2018.
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 (http://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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . 11
4.1.3. MoU Concerning the Technical Work of the IANA . . . . 13 4.1.3. MoU Concerning the Technical Work of the 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.2. Secondary documents relating to the Special-Use 4.2. Secondary documents relating to the Special-Use
Domain Name question . . . . . . . . . . . . . . . . . . 14 Domain Name question . . . . . . . . . . . . . . . . . . 14
4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 14
4.2.2. The .onion Special-Use Top-Level Domain Name . . . . 15 4.2.2. The .onion Special-Use Top-Level Domain Name . . . . 15
4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . 16
4.2.7. Additional Reserved Top Level Domains . . . . . . . . 17 4.2.7. Additional Reserved Top Level Domains . . . . . . . . 17
5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 19 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 19
10. Informative References . . . . . . . . . . . . . . . . . . . 19 10. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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
skipping to change at page 3, line 42 skipping to change at page 3, line 42
(see [SDO-ICANN-DAG], Section 2.2.1.2.1, Reserved Names, (see [SDO-ICANN-DAG], Section 2.2.1.2.1, Reserved Names,
Section 2.2.1.4.1, Treatment of Country or Territory Names, et Section 2.2.1.4.1, Treatment of Country or Territory Names, et
al.) al.)
o Used by other organizations without following established o 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, believed to be complete, of the This document presents a list, derived from a variety of sources
problems associated with the assignment of Special-Use Domain Names. including discussion in the IETF dnsop WG, of the problems associated
In support of its analysis of the particular set of issues described with the assignment of Special-Use Domain Names. The list is
here, the document also includes descriptions of existing practice as intended to be an unfiltered compilation of issues. In support of
it relates to the use of domain names, a brief history of domain its analysis of the particular set of issues described here, the
names, and some observations by various IETF participants who have document also includes descriptions of existing practice as it
relates to the use of domain names, a brief history of domain names,
and some observations by various IETF participants who have
experience with various aspects of the current situation. 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].
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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 RFC 6761 process, technical mistakes have been made due to
misunderstandings as to the actual process that RFC 6761 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 RFC 6761
process. process (see [RFC7050], [RFC7788]).
12. There are several Domain Name TLDs that are in use without due 12. There are several Domain Name TLDs that are in use without due
process for a variety of purposes. The status of these names process for a variety of purposes. The status of these names
need to be clarified and recorded to avoid future disputes about need to be clarified and recorded to avoid future disputes about
their use [SDO-ICANN-COLL]. their use [SDO-ICANN-COLL].
13. In principle, the RFC 6761 process could be used to document the 13. In principle, the RFC 6761 process could be used to document the
existence of Domain Names that are not safe to assign, and existence of Domain Names that are not safe to assign, and
provide information on how those names are used in practice. provide information on how those names are used in practice.
However, attempts to use RFC 6761 to accomplish this However, attempts to use RFC 6761 to accomplish this
skipping to change at page 10, line 17 skipping to change at page 10, line 17
over one or more name servers or resolvers, in the context of any over one or more name servers or resolvers, in the context of any
hosts and services that entity operates. It can also be accomplished hosts and services that entity operates. It can also be accomplished
by authors of software who decide that a Special-Use Domain Name is by authors of software who decide that a Special-Use Domain Name is
the right way to indicate the use of an alternate resolution the right way to indicate the use of an alternate resolution
mechanism. 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. Only one also because they describe what the IETF does in practice.
of these documents is an IETF consensus document.
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 This document [RFC2826] is not an IETF consensus document, and
appears to have been written to address a different problem than the appears to have been written to address a different problem than the
Special-Use Domain Name problem. However, it speaks directly to Special-Use Domain Name problem. However, it speaks directly to
several of the key issues that must be considered, and, coming as it several of the key issues that must be considered, and, coming as it
does from the IAB, it is rightly treated as having significant does from the IAB, it is rightly treated as having significant
authority despite not being an IETF consensus document. authority despite not being an IETF consensus document.
skipping to change at page 13, line 23 skipping to change at page 13, line 23
special handling by stub resolvers and which are not at the top level special handling by stub resolvers and which are not at the top level
of the naming hierarchy. of the 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' at the top level of a domain name, it can only use the mDNS
protocol to resolve that Domain Name. 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 the IANA
There exists a Memorandum of Understanding [RFC2860] between the IETF There exists a Memorandum of Understanding (MOU) [RFC2860] between
and ICANN (Internet Corporation for Assigned Names and Numbers) which the IETF and ICANN (Internet Corporation for Assigned Names and
discusses how names and numbers will be managed through the IANA Numbers) which discusses how names and numbers will be managed
(Internet Assigned Numbers Authority). This document is important to through the IANA (Internet Assigned Numbers Authority). This
the discussion of Special-Use Domain Names because, while it document is important to the discussion of Special-Use Domain Names
delegates authority for managing the Domain Name System Namespace because, while it delegates authority for managing the Domain Name
generally to ICANN, it reserves to the IETF the authority that RFC System Namespace generally to ICANN, it reserves to the IETF the
6761 formalizes: 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:
skipping to change at page 14, line 16 skipping to change at page 14, line 16
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
As a result of processing requests to add names to the Special-Use When the IETF received processing requests to add names to the
Domain Name registry, as documented in Special-Use Domain Name registry, as documented in
[I-D.chapin-additional-reserved-tlds] and [I-D.chapin-additional-reserved-tlds] and
[I-D.grothoff-iesg-special-use-p2p-names], a review was chartered of [I-D.grothoff-iesg-special-use-p2p-names], the IETF chartered a
the process defined in RFC 6761 for adding names to the registry (as review of the process defined in RFC 6761 for adding names to the
explained earlier). The Liaison Statement [SDO-IAB-ICANN-LS] registry (as explained earlier). The IETF sent a Liaison Statement
notified ICANN of the review, affirmed that the discussion would be [SDO-IAB-ICANN-LS] to ICANN to notify ICANN of the review, affirm
"open and transparent to participation by interested parties" and that the discussion would be "open and transparent to participation
explicitly invited 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.2. Secondary documents relating to the Special-Use Domain Name
question 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
skipping to change at page 15, line 37 skipping to change at page 15, line 39
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, 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 name had been allocated unilaterally, it was Because the .onion domain was allocated unilaterally, this would
affected by this policy. mean that certificates for subdomains of .onion could no longer be
issued.
The IETF's designation of .onion as a Special-Use Top-Level Domain The IETF's designation of .onion as a Special-Use Top-Level Domain
Name was needed to facilitate the development of a certificate Name was needed to facilitate the development of a certificate
issuance process specific to .onion domain names 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
skipping to change at page 16, line 47 skipping to change at page 17, line 7
[RFC7050] is an example of a document that successfully used the RFC [RFC7050] is an example of a document that successfully used the RFC
6761 process to designate '.ipv4only.arpa' as a Special-Use Domain 6761 process to designate '.ipv4only.arpa' as a Special-Use Domain
Name; in this case the process worked smoothly and without 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 SUDN registry. This is an of an entry for "ipv4only.arpa" in the Special-Use Domain Name
illustration of one of the problems that we have with the 6761 registry. This is an illustration of one of the problems that we
process: it is apparently fairly easy to miss the step of adding the have with the 6761 process: it is apparently fairly easy to miss the
name to the registry. 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
[I-D.chapin-additional-reserved-tlds] is an example of a document [I-D.chapin-additional-reserved-tlds] is an example of a document
that attempted to reserve several TLDs identified by ICANN as that attempted to reserve several TLDs identified by ICANN as
particularly at risk for collision as Special-Use Domain Names with particularly at risk for collision as Special-Use Domain 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 this document failed to gain consensus to publish, the need
skipping to change at page 17, line 39 skipping to change at page 17, line 46
put into use for other purposes without following established put into use for other purposes without following established
processes[SDO-ICANN-COLL], which further complicates the situation. processes[SDO-ICANN-COLL], which further complicates the situation.
At the time this document was written, the IETF was developing a At the time this document was written, the IETF was developing a
solution to this problem. solution to this problem.
5. History 5. History
Newcomers to the problem of resolving Domain Names may be under the Newcomers to the problem of resolving Domain Names may be under the
mistaken impression that the DNS sprang, as in the Greek legend of mistaken impression that the DNS sprang, as in the Greek legend of
Athena, directly from Paul Mockapetris' forehead. This is not the Athena, directly from Paul Mockapetris' forehead. This is not the
case. At the time of the writing of the IAB technical document, case. At the time of the writing of the IAB technical document
memories would have been fresh of the evolutionary process that led ([RFC2826]), memories would have been fresh of the evolutionary
to the DNS' dominance as a protocol for Domain Name resolution. process that led to the DNS' dominance as a protocol for Domain Name
resolution.
In fact, in the early days of the Internet, hostnames were resolved 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 [RFC0959]. The inefficiency of this process is cited as a reason for
the development of the DNS [RFC0882] [RFC0883] in 1983. the development of the DNS [RFC0882] [RFC0883] 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's Network Information System
skipping to change at page 18, line 26 skipping to change at page 18, line 37
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 unused TLD and using it for widespread practice of simply picking an apparently-unused TLD and
experimental purposes, which persists even at the time of writing of using it for experimental purposes, which persists even at the time
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
skipping to change at page 19, line 11 skipping to change at page 19, line 20
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. This document has no actions for IANA.
8. Contributors 8. Contributors
This document came about as a result of conversations that occurred Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron
in the conference hotel lobby, the weekend before IETF 95, when the Falk and Suzanne Woolf all made helpful and insightful observations
original author, Ted Lemon, was trying to come up with a better
problem statement. Stuart Cheshire, Mark Andrews, David Conrad, Paul
Ebersman and Aaron Falk all made helpful and insightful observations
or patiently answered questions. This should not be taken as an or patiently answered questions. This should not be taken as an
indication that any of these folks actually agree with what the indication that any of these folks actually agree with what the
document says, but their generosity with time and thought are document says, but their generosity with time and thought are
appreciated in any case. appreciated in any case.
Ralph started out as an innocent bystander, but discussion with him Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ
was the key motivating factor in the writing of this document, and he Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr
agreed to co-author it without too much arm-twisting. Warren spent a Spacek and others provided significant review and / or useful
lot of time working with us on this document after it was first comments.
published, and joined as an author in order to make sure that the
work got finished; without him the -01 and -02 versions might not
have happened.
This document also owes a great deal to Ed Lewis' excellent work on This document also owes a great deal to Ed Lewis' excellent work on
what a "Domain Name" is [I-D.lewis-domain-names]. what a "Domain Name" is [I-D.lewis-domain-names].
9. RFC Editor Considerations 9. RFC Editor Considerations
The authors were unable to find dates for references The authors were unable to find dates for references
[SDO-CABF-DEADLINE] and [SDO-CABF]. Please fix up those references [SDO-CABF-DEADLINE] and [SDO-CABF]. Please fix up those references
as appropriate (and remove this section before publication). as appropriate (and remove this section before publication).
10. Informative References 10. Informative References
[CORP-SUN-NIS]
Sun Microsystems, "Large System and Network
Administration", March 1990.
[ERRATA-4677]
Internet Architecture Board, "Errata ID: 4677 (RFC7788)",
April 2016, <https://www.rfc-editor.org/errata/eid4677>.
[I-D.chapin-additional-reserved-tlds]
Chapin, L. and M. McFadden, "Additional Reserved Top Level
Domains", draft-chapin-additional-reserved-tlds-02 (work
in progress), March 2015.
[I-D.grothoff-iesg-special-use-p2p-names]
Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and
L. Ryge, "Special-Use Domain Names of Peer-to-Peer
Systems", draft-grothoff-iesg-special-use-p2p-names-04
(work in progress), January 2015.
[I-D.lewis-domain-names]
Lewis, E., "Domain Names, A Case for Clarifying", draft-
lewis-domain-names-09 (work in progress), August 2017.
[IETF-PRO-51]
Internet Engineering Task Force, "Proceedings of the 51st
IETF", August 2001,
<http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", [RFC0882] 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>. <http://www.rfc-editor.org/info/rfc882>.
[RFC0883] Mockapetris, P., "Domain names: Implementation [RFC0883] 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, <http://www.rfc-editor.org/info/rfc883>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
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>. <http://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>. <http://www.rfc-editor.org/info/rfc1002>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
skipping to change at page 20, line 35 skipping to change at page 21, line 20
[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>. <http://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, <http://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, DOI Internet Assigned Numbers Authority", RFC 2860,
10.17487/RFC2860, June 2000, DOI 10.17487/RFC2860, June 2000,
<http://www.rfc-editor.org/info/rfc2860>. <http://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>. <http://www.rfc-editor.org/info/rfc4193>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
6303, DOI 10.17487/RFC6303, July 2011, RFC 6303, DOI 10.17487/RFC6303, July 2011,
<http://www.rfc-editor.org/info/rfc6303>. <http://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, <http://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)", RFC to Replace the AppleTalk Name Binding Protocol (NBP)",
6760, DOI 10.17487/RFC6760, February 2013, RFC 6760, DOI 10.17487/RFC6760, February 2013,
<http://www.rfc-editor.org/info/rfc6760>. <http://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>. <http://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>. <http://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", RFC the IPv6 Prefix Used for IPv6 Address Synthesis",
7050, DOI 10.17487/RFC7050, November 2013, RFC 7050, DOI 10.17487/RFC7050, November 2013,
<http://www.rfc-editor.org/info/rfc7050>. <http://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, <http://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, <http://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, <http://www.rfc-editor.org/info/rfc7788>.
[I-D.chapin-additional-reserved-tlds]
Chapin, L. and M. McFadden, "Additional Reserved Top Level
Domains", draft-chapin-additional-reserved-tlds-02 (work
in progress), March 2015.
[I-D.grothoff-iesg-special-use-p2p-names]
Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and
L. Ryge, "Special-Use Domain Names of Peer-to-Peer
Systems", draft-grothoff-iesg-special-use-p2p-names-04
(work in progress), January 2015.
[I-D.lewis-domain-names]
Lewis, E., "Domain Names, A Case for Clarifying", draft-
lewis-domain-names-08 (work in progress), June 2017.
[SDO-CABF-INT]
CA/Browser Forum, "Guidance on the Deprecation of Internal
Server Names and Reserved IP Addresses", June 2012,
<https://www.digicert.com/internal-names.htm>.
[SDO-CABF-DEADLINE]
CA/Browser Forum, "SSL Certificates for Internal Server
Names", ??? ????, <https://www.digicert.com/internal-
names.htm>.
[SDO-CABF] [SDO-CABF]
CA/Browser Forum, "CA/Browser Forum", ??? ????, 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/02/18/ballot-144-validation- <https://cabforum.org/2015/02/18/ballot-144-validation-
rules-dot-onion-names>. rules-dot-onion-names>.
[SDO-CABF-DEADLINE]
CA/Browser Forum, "SSL Certificates for Internal Server
Names", ??? ????, <https://www.digicert.com/internal-
names.htm>.
[SDO-CABF-INT]
CA/Browser Forum, "Guidance on the Deprecation of Internal
Server Names and Reserved IP Addresses", June 2012,
<https://www.digicert.com/internal-names.htm>.
[SDO-IAB-ICANN-LS]
Internet Architecture Board, "Liaison Statement from the
IAB to the ICANN Board on Technical Use of Domain Names",
September 2015, <https://datatracker.ietf.org/
liaison/1351>.
[SDO-IANA-SUDR]
Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015,
<http://www.iana.org/assignments/special-use-domain-names/
special-use-domain-names.xhtml>.
[SDO-ICANN-COLL] [SDO-ICANN-COLL]
Interisle Consulting Group, LLC, "Name Collisions in the Interisle Consulting Group, LLC, "Name Collisions in the
DNS", August 2013, DNS", August 2013,
<https://www.icann.org/en/system/files/files/name- <https://www.icann.org/en/system/files/files/name-
collision-02aug13-en.pdf>. collision-02aug13-en.pdf>.
[SDO-ICANN-DAG]
Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015,
<https://newgtlds.icann.org/en/applicants/agb/guidebook-
full-04jun12-en.pdf>.
[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, December 2016,
<https://www.icann.org/en/system/files/files/sac- <https://www.icann.org/en/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", Advisory on the Stability of the Domain Namespace",
December 2016, <https://www.icann.org/groups/ssac>. December 2016, <https://www.icann.org/groups/ssac>.
[SDO-IANA-SUDR]
Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015,
<http://www.iana.org/assignments/special-use-domain-names/
special-use-domain-names.xhtml>.
[SDO-ICANN-DAG]
Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015,
<https://newgtlds.icann.org/en/applicants/agb/guidebook-
full-04jun12-en.pdf>.
[SDO-IAB-ICANN-LS]
Internet Architecture Board, "Liaison Statement from the
IAB to the ICANN Board on Technical Use of Domain Names",
September 2015, <https://datatracker.ietf.org/
liaison/1351>.
[ERRATA-4677]
Internet Architecture Board, "Errata ID: 4677 (RFC7788)",
April 2016, <https://www.rfc-editor.org/errata/eid4677>.
[CORP-SUN-NIS]
Sun Microsystems, "Large System and Network
Administration", March 1990.
[IETF-PRO-51]
Internet Engineering Task Force, "Proceedings of the 51st
IETF", August 2001,
<http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
[TOR] The Tor Project, "Tor", 2017, [TOR] The Tor Project, "Tor", 2017,
<https://www.torproject.org>. <https://www.torproject.org>.
Appendix A. Change Log. Appendix A. Change Log.
-06 to -07: -06 to -07:
o Issue #88: Bulleted list should be numbered, not unordered - o Issue #88: Bulleted list should be numbered, not unordered -
Updated the list of problems to be numbered, instead of unordered. Updated the list of problems to be numbered, instead of unordered.
This is to allow future documents to refer to specific issues. This is to allow future documents to refer to specific issues.
 End of changes. 28 change blocks. 
121 lines changed or deleted 119 lines changed or added

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