draft-ietf-dnsop-sutld-ps-02.txt   draft-ietf-dnsop-sutld-ps-03.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: August 3, 2017 Expires: September 14, 2017
W. Kumari W. Kumari
Google Google
January 30, 2017 March 13, 2017
Special-Use Names Problem Statement Special-Use Domain Names Problem Statement
draft-ietf-dnsop-sutld-ps-02 draft-ietf-dnsop-sutld-ps-03
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 standards organizations relating to and some publications from other organizations relating to Special-
special-use Domain Names. Use Domain Names.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 3, 2017. This Internet-Draft will expire on September 14, 2017.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problems associated with Special-Use Domain Names . . . . . . 3 3. Problems associated with Special-Use Domain Names . . . . . . 4
4. Existing Practice Regarding SUDNs . . . . . . . . . . . . . . 7 4. Existing Practice Regarding Special-Use Domain Names . . . . 9
4.1. Primary SUDN Documents . . . . . . . . . . . . . . . . . 7 4.1. Primary Special-Use Domain Name Documents . . . . . . . . 9
4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 8 4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 9
4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 9 4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 11
4.1.3. MoU Concerning the Technical Work of the IANA . . . . 10 4.1.3. MoU Concerning the Technical Work of the IANA . . . . 12
4.2. Secondary documents relating to the SUTLDN question . . . 11 4.1.4. Liaison Statement on Technical Use of Domain
4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 11 Names . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. The .onion Special-Use TLD . . . . . . . . . . . . . 12 4.2. Secondary documents relating to the Special-Use
4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 12 Domain Name question . . . . . . . . . . . . . . . . . . 14
4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 13 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 14
4.2.2. The .onion Special-Use Top-Level Domain Name . . . . 14
4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 15
4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 15
4.2.5. SSAC Advisory on the Stability of the Domain 4.2.5. SSAC Advisory on the Stability of the Domain
Namespace . . . . . . . . . . . . . . . . . . . . . . 13 Namespace . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . 13 Synthesis . . . . . . . . . . . . . . . . . . . . . . 16
4.2.7. Additional Reserved Top Level Domains . . . . . . . . 13 4.2.7. Additional Reserved Top Level Domains . . . . . . . . 16
4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Informative References . . . . . . . . . . . . . . . . . . . 16 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 19 9. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 be taken to not assume that the term Domain Name implies the use of
particular protocol for resolving these names, the Domain Name System the Domain Name System [RFC1034] for resolving these names. An
[RFC1034]. An excellent presentation on this topic can be found in excellent presentation on this topic can be found in Domain Names
Domain Names [I-D.lewis-domain-names]. [I-D.lewis-domain-names].
Special-Use Domain Names [RFC6761] created an IANA registry for Special-Use Domain Names [RFC6761] created an IANA registry for
special-use Domain Names [SDO-IANA-SUDR], defined policies for adding Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding
to the registry, and made some suggestions about how that policy to 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 RFC 6761 process can be improved, or whether it
should be deprecated. should be deprecated.
Based on current ICANN and IETF practice, including RFC 6761, there
are several different types of names in the root of the Domain
Namespace:
o Reserved by the IETF for technical purposes
o Assigned by ICANN to the public DNS root; some names reserved by
the IETF for technical purposes may appear in the Global DNS root
for reasons pertaining to the operation of the DNS
o ICANN Reserved Names; names that may not be applied for as TLDs
(see [SDO-ICANN-DAG], Section 2.2.1.2.1, Reserved Names,
Section 2.2.1.4.1, Treatment of Country or Territory Names, et
al.)
o Used by other organizations without following established
processes
o Names that are unused and are available for assignment to one of
the previous categories
This document presents a list, believed to be complete, of the This document presents a list, believed to be complete, of the
problems associated with the assignment of special-use names. In problems associated with the assignment of Special-Use Domain Names.
support of the particular set of problems described here, the In support of its analysis of the particular set of issues described
document also includes documentation of existing practice as it here, the document also includes descriptions of existing practice as
relates to the use of Domain Names, as well as a brief history of it relates to the use of domain names, a brief history of domain
Domain Names, and finally to describe the set of problems that exist names, and some observations by various IETF participants who have
as reported by various IETF participants with experience in the experience with various aspects of the current situation.
various aspects of the problem.
2. Terminology 2. Terminology
For the sake of brevity this document uses a number of abbreviations. This document uses the terminology from RFC 7719 [RFC7719]. Other
These are expanded here: terms used in this document are defined here:
Domain Name A name which serves as input to a name resolution Domain Name This document uses the term "Domain Name" as defined in
process, for example 'EXAMPLE.ORG'. section 2 of RFC 7719 [RFC7719].
Domain Namespace The set of all possible Domain Names. Domain Namespace The set of all possible Domain Names.
SUDN Special Use Domain Name Special-Use Domain Name A Domain Name listed in the Special-Use
Domain Names registry.
SUTLDN Special-Use Top-Level Domain Name For the sake of brevity this document uses some abbreviations, which
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 in section 2 of RFC 7719
[RFC7719]
gTLD Generic Top-Level Domain, as defined in in section 2 of RFC
7719 [RFC7719]
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 names. Solutions to with respect to the assignment of Special-Use Domain Names.
these problems are out of scope for this document. Because of that, Solutions to these problems, including their costs or tradeoffs, are
problems with solutions to these problems are also out of scope for out of scope for this document. They will be covered in a separate
this document, and will be covered in a separate document. document. New problems that might be created in the process of
solving problems described in this document are also out of scope:
these problems are expected to be addressed in the process of
evaluating potential solutions.
No assertion is made that any of these problems is more or less Special-Use Domain Names exist to solve a variety of problems. This
important than any other. The point of this is simply to enumerate document has two goals: enumerate all of the problems that have been
and briefly describe the problems that have been raised during identified to which Special-Use Domain Names are a solution and
discussions of the special-use name problem. The degree of detail is enumerate all of the problems that have been raised in the process of
intended to be sufficient that that participants in the discussion trying to use RFC 6761 as it was intended. As some of those problems
can agree that the problems they've raised have been adequately may fall into both categories, this document makes no attempt to
described, and no more. These problems should not appear to every categorize the problems.
reader to all be problems: we intend to cover any problem that any
participant considers a problem, not just those problems that
everyone agrees are problems.
In addition, no assertion is made that all of these problems must be There is a broad diversity of opinion about this set of problems.
addressed, or that, if we think they should be addressed, the IETF is Not every participant agrees that each of the problems enumerated in
the organization with competence to address them. While each problem this document is actually a problem. This document takes no position
has one or more solutions, the solutions may in some cases be on the relative validity of the various problems that have been
mutually contradictory, or may come with costs that do not justify enumerated. Its focused purposes are to enumerate those problems,
the benefit that would be obtained from solving them. provide the reader with context for thinking about them and provide a
context for future discussion of solutions.
This is the list of problems: This is the list of problems:
o There are several different types of names in the root of the o No formal coordination process exists between the IETF and ICANN
Domain Namespace: as they follow their respective name assignment processes (see
Section 4.1.3). The lack of coordination complicates the
* Reserved by the IETF for technical purposes management of the root of the Domain Namespace and could lead to
* Assigned by ICANN to the public DNS root
* ICANN Reserved Names; names that may not be applied for as a
TLD (see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names )
* Commandeered for use by other organizations
* Not a member of any other category
o Both ICANN and the IETF have the authority and formal processes to
assign names from the pool of unused names, but no formal
coordination process exists. The lack of coordination complicates
the management of the root of the Domain Namespace and may lead to
conflicts in name assignments [SDO-ICANN-SAC090]. conflicts in name assignments [SDO-ICANN-SAC090].
o The term "technical use" in RFC 2860 [RFC2860] is considered by o There is no explicit scoping as to what can constitute a
some to be too inclusive. "technical use" [RFC2860] and what cannot, and there is also no
consensus within the IETF as to what this term means.
o The IETF and ICANN each have administrative authority over the o Not all developers of protocols on the internet agree that
Domain Namespace. Not all developers of protocols on the internet authority over the entire Domain Namespace should reside solely
agree that this authority should reside with the IETF and ICANN. with the IETF and ICANN.
o Although IETF and ICANN nominally have authority over this o Although 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. namespace. Such parties may observe that the IETF has never
asserted control or authority over what protocols are "allowed" on
the internet, and that the principle of "permissionless
innovation" suggests there should be a way for people to include
new uses of domain names in new protocols and applications.
o Organizations do in fact sometimes commandeer subsets of the o Organizations do in fact sometimes use subsets of the Domain
namespace. Reasons a third party might do this include: Namespace without following established processes. Reasons a
third party might do this include:
* Unaware that a process exists for assigning such names * Unaware that a process exists for assigning such names
* Intended use is covered by gTLD process, but no gTLD process is * Intended use is covered by gTLD process [SDO-ICANN-DAG], but no
ongoing gTLD process is ongoing
* Intended use is covered by gTLD process, don't want to pay fee * Intended use is covered by gTLD process, but the third party
doesn't want to pay a fee
* Intended use is covered by some IETF process, but don't want to * Intended use is covered by some IETF process, but the third
follow process party doesn't want to follow the process
* Intended use is covered by ICANN or IETF process, but expected * Intended use is covered by ICANN or IETF process, but third
outcome is refusal or non-action party expects that the outcome will be refusal or non-action
* Unaware that a name intended to be used only locally may
nevertheless leak
* Unaware that a name used locally with informal allocation may
subsequently be allocated formally, creating operational
problems
o There is demand for more than one name resolution protocol for o There is demand for more than one name resolution protocol for
Domain Names, but Domain Names contain no metadata to indicate Domain Names. Domain Names contain no metadata to indicate which
which protocol to use to resolve them. protocol to use to resolve them. Domain name resolution APIs do
not provide a way to specify which protocol to use.
o When a special-use Domain Name is added to the special-use Domain o When a Special-Use Domain Name is added to the Special-Use Domain
Names registry, not all software that processes such names will Names registry, not all software that processes such names will
understand the special use of that name. In many cases, name understand the special use of that name. In many cases, name
resolution software will use the Domain Name System for resolution resolution software will use the Domain Name System for resolution
of names not known to have a special use. Consequently, any such of names not known to have a special use. Consequently, any such
use will result in queries for special-use names being sent to use will result in queries for Special-Use Domain Names being sent
Domain Name System authoritative servers. These queries may to Domain Name System authoritative servers. These queries may
constitute an operational problem for operators of root zone constitute an operational problem for operators of root zone
authoritative name servers. authoritative name servers. These queries may also inadvertently
reveal private information through the contents of the query,
which is a privacy consideration.
o The RFC6761 process is sufficiently uncertain that some protocol o The RFC 6761 process is sufficiently uncertain that some protocol
developers have assumed they could not get a name assigned; the developers have assumed they could not get a name assigned; the
process of assigning the first new name ('.local') using the RFC process of assigning the first new name ('.local') using the RFC
6761 process took more than ten years from beginning to end: 6761 process took more than ten years from beginning to end:
longer by a factor of ten than any other part of the protocol longer by a factor of ten than any other part of the protocol
development process. Other uses of the process have proceeded development process (largely because this ten years included time
more smoothly, but there is a reasonably justified perception that to develop the process as well as use it). Other uses of the
using this process is likely to be slow and difficult, with an process have proceeded more smoothly, but there is a reasonably
uncertain outcome. justified perception that using this process is likely to be slow
and difficult, with an uncertain outcome.
o There is strong resistance within the IETF to assigning Domain o 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:
* Requires a mechanism for identifying which of a set of * Requires a mechanism for identifying which of a set of
resolution processes is required in order to resolve a resolution processes is required in order to resolve a
particular name. particular name.
* Assertion of authority: there is a sense that the Domain * Assertion of authority: there is a sense that the Domain
skipping to change at page 6, line 20 skipping to change at page 7, line 7
* More than one name resolution protocol is bad, in the sense * 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.
* The semantics of alternative resolution protocols may differ * 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; other
protocols may not support RRtypes, or may support some entirely protocols may not support RRtypes, or may support some entirely
different data structuring mechanism. different data structuring mechanism.
* If there is an IETF process through which a name can be * If there is an IETF process through which a TLD can be assigned
assigned at zero cost other than time, this process will be at zero cost other than time, this process will be used as an
used as an alternative to purchasing the name through ICANN. alternative to the more costly process of getting the name
registered through ICANN.
* A name might be assigned for a particular purpose when a more * A name might be assigned for a particular purpose when a more
general use of the name would be more beneficial. general use of the name would be more beneficial.
* If the IETF assigns a name that some third party or parties * If the IETF assigns a name that some third party or parties
believes belongs to them in some way, the IETF could become believes 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.
o If there were no process for assigning names for technical use o 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.
o In cases where the IETF has made assignments through the RFC 6761 o In some cases where the IETF has made assignments through the RFC
process, technical mistakes have been made due either to 6761 process, technical mistakes have been made due to
misunderstandings as to the actual process that RFC 6761 specifies misunderstandings as to the actual process that RFC 6761 specifies
(e.g., treating the list of suggested considerations for assigning (e.g., treating the list of suggested considerations for assigning
a name as a set of requirements all of which must be met), or to a a name as a set of requirements all of which must be met). In
failure to follow the process that was defined in RFC 6761. other cases, the IETF has made de facto assignments of Special-Use
Domain Names without following the RFC 6761 process.
o There are several Domain Name TLDs that are in use without due
process for a variety of purposes [SDO-ICANN-COLL]. The status of
these names need to be clarified and recorded to avoid future
disputes about their use.
o In principle, the RFC 6761 process could be used to document the o In principle, the RFC 6761 process could be used to document the
existence of Domain Names that are not safe to assign, and provide existence of Domain Names that are not safe to assign, and provide
information on how those names are used in practice. However, information on how those names are used in practice. However,
attempts to use RFC6761 to accomplish this attempts to use RFC 6761 to accomplish this documentation have not
[I-D.chapin-additional-reserved-tlds] have not been successful. been successful (for example, see "Additional Reserved Top Level
One side effect of this is that any mitigation effect on the root Domains [I-D.chapin-additional-reserved-tlds] and Section 4.2.7).
name servers has been missed. One side effect of the lack of documentation is that any
mitigation effect on the root name servers or on privacy
considerations has been missed.
o There are several Domain Name TLDs that have been commandeered o A Domain Name can be identified as either a DNS name by placing it
without due process for a variety of purposes [SDO-ICANN-COLL]. in the DNS zone(s) or as a Special-Use Domain Name by adding it to
The status of these names need to be clarified and recorded to the IANA registry. Some names are in both places; for example,
avoid future disputes about their use. [ Ed note: We note that some locally served zone names are in DNS zones and documented in
DNSOP has previously discussed some of these in draft-chapin- the Special-Use Domain Names registry. At present, the only way a
additional-reserved-tlds-02, and decided not to adopt the draft - Domain Name can be added to the Special-Use Domain Name registry
https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html is for the IETF to take responsibility for the name and designate
. The authors are not recommending that DNSOP revisit this, it for "technical use". There are other potential uses for Domain
rather that is needs to be addressed in some venue. ] Names that should be recorded in the registry, but for which the
IETF should not take responsibility.
o No mechanism exists for adding a name to the registry without o The IETF may in some cases see the need to document that a name is
claiming that the IETF is responsible for that name, nor is it in use without claiming that the use of the name is the IETF's use
possible to state a precedence for the name, e.g. "if ICANN of the name. No mechanism exists in the current registry to mark
delegates this name, ICANN's delegation takes precedence." names in this way.
o No process exists for checking documents to make sure they don't o There is no formal mechanism that ensures that we check to make
accidentally assign names (e.g. RFC 7788). sure that a document being considered for publication does not
unintentionally violate the IETF process for adding Special-Use
Domain Names to the registry (e.g., RFC 7788 [RFC7788]).
o Use of the registry is inconsistent--some SUTLDN RFCs specify o Use of the registry is inconsistent--some Special-Use Domain Name
registry entries, some don't; some specify delegation, some don't. RFCs specify registry entries, some don't; some specify
delegation, some don't.
o There exists no safe, non-process-violating mechanism for ad-hoc o There exists no safe, non-process-violating mechanism for ad-hoc
assignment of special-use names. assignment of Special-Use Domain Names.
o It is generally assumed that protocols that need a special-use o It is generally assumed that protocols that need a Special-Use
name need a human-readable special-use name. This assumption may Domain Name need a mnemonic, single-label, human-readable Special-
not be warranted in all cases. Use Domain Name, for use in user interfaces such as command lines
or URL entry fields. While this assumption is correct in some
cases, it is likely not correct in all cases; for example, in
applications where the DNS name is never visible to a user.
o RFC 6761 uses the term "Domain Name" to describe the thing for o 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 use confusion because some readers take "Domain Name" to imply the use
of the DNS protocol. of the DNS protocol.
o The use of DNSSEC with Special-Use Domain Names is an open issue.
There is no consensus or guidance about how to use DNSSEC with
various classes of Special-Use Domain Names. Considerations in
the use of DNSSEC with Special-Use Domain Names include:
* What class of Special-Use Domain Name is under consideration:
non-DNS, locally served zone, other?
* Does the Special-Use Domain Name require a delegation in the
root zone; if so, should that delegation be signed or not? If
there is no delegation, then this will be treated by validating
resolvers as a secure denial of existence for that zone. This
would not be appropriate for a name being resolved using the
DNS protocol.
* A process would be required through which the IETF can cause a
delegation in the root zone to be instantiated.
* What are the recommended practices for using DNS with the
specific Special-Use Domain Name?
The problems we have stated here represent the current understanding The problems we have stated here represent the current understanding
of the authors of the document as to the complete set of problems of the authors of the document as to the complete set of problems
that have been identified during discussion by the working group on that have been identified during discussion by the working group on
this topic. The remainder of this document provides additional this topic. The remainder of this document provides additional
context that will be needed for reasoning about these problems. context that will be needed for reasoning about these problems.
4. Existing Practice Regarding SUDNs 4. Existing Practice Regarding Special-Use Domain Names
There are three primary and numerous secondary documents to consider There are three primary and numerous secondary documents to consider
when thinking about the Special-Use Domain Names process. when thinking about the Special-Use Domain Names process.
4.1. Primary SUDN Documents How names are resolved is ambiguous, in the sense that some names are
Special-Use Domain names that require special handling, and some
names can be resolved using the DNS protocol with no special
handling.
The assignment of Internet Names is not under the sole control of any
one organization. IETF has authority in some cases, but only with
respect to "technical uses." ICANN at present is the designated
administrator of the root zone, but generally not of zones other than
the root zone. And neither of these authorities can in any practical
sense exclude the practice of ad-hoc use of names. This can be done
by any entity that has control over one or more name servers or
resolvers, in the context of any hosts and services that that entity
operates. It can also be done by authors of software who decide that
a Special-Use Domain Name is the right way to indicate the use of an
alternate resolution mechanism.
4.1. Primary Special-Use Domain Name Documents
The primary documents are considered primary because they directly 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. Only one
of these documents is an IETF consensus document. 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
SUDN problem. However, it speaks directly to several of the key Special-Use Domain Name problem. However, it speaks directly to
issues that must be considered, and of course coming as it does from several of the key issues that must be considered, and of course
the IAB, it is rightly treated as having significant authority coming as it does from the IAB, it is rightly treated as having
despite not being an IETF consensus document. significant authority despite 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
SUDNs. The main points that appear relevant to the special use names Special-Use Domain Names. The main points that appear relevant to
problem are: the Special-Use Domain Names problem are:
o The Internet requires a globally unique namespace o The Internet requires a globally unique namespace
o Private networks may operate private namespaces, but still require o Private networks may operate private namespaces, but still require
that names in the public namespace be globally unique. 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
skipping to change at page 8, line 45 skipping to change at page 10, line 38
o Such references might refer to the object the user intends to o Such references might refer to the object the user intends to
share within that user's context, but either refer to some other share within that user's context, but either refer to some other
object any recipient's context, or might not refer to any object object any recipient's context, or might not refer to any object
at all in a recipient's context. The effect of this is that the at all in a recipient's context. The effect of this is that the
user's intended communication will not be able to be understood by user's intended communication will not be able to be understood by
the recipients of the communication. the recipients of the communication.
o This same problem can also occur simply because a single user o This same problem can also occur simply because a single user
copies a name from one context in which it has one meaning, into a copies a name from one context in which it has one meaning, into a
different context in which it has a different meaning-- for different context in which it has a different meaning-- for
example copying a '.onion' Domain Name out of a TOR browser, where example copying a '.onion' Domain Name out of a Tor Browser [TOR],
it has meaning, and pasting this name into an ssh client that where it has meaning, and pasting this name into an ssh client
doesn't support connecting over TOR. that doesn't support connecting over the Tor network.
To boil this down even further, we can take the following advice from To boil this down even further, we can take the following advice from
this document: this document:
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 which 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]. RFC6761 represents the current IETF consensus on [RFC6761]. RFC 6761 represents the current IETF consensus on
designating and recording SUDNs. The IETF has experienced problems designating and recording Special-Use Domain Names. The IETF has
with the designation process described in RFC6761; these concerns experienced problems with the designation process described in RFC
motivate this document. Again, familiarity with RFC6761 is a 6761; these concerns motivate this document. Again, familiarity with
prerequisite for having an informed opinion on the topic of SUDNs. RFC 6761 is a prerequisite for having an informed opinion on the
topic of Special-Use Domain Names.
RFC 6761 defines two aspects of SUDNs: designating a Domain Name to RFC 6761 defines two aspects of Special-Use Domain Names: designating
have a special purpose and registering that special use in the a Domain Name to have a special purpose and registering that special
Special-Use Domain Names registry. The designation process is use in the Special-Use Domain Names registry. The designation
defined in a single sentence (RFC6761, 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 implies that any designation of a special-use name is This sentence implies that any designation of a Special-Use Domain
subject to the same open review and consensus process as used to Name is subject to the same open review and consensus process as used
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 name is recorded, with existence of the newly designated Special-Use Domain Name is
a pointer to a section in the relevant specification document that recorded, with a pointer to a section in the relevant specification
defines the ways in which special handling is to be applied to the document that defines the ways in which special handling is to be
name. applied to the name.
RFC6761 provided the process whereby Multicast DNS [RFC6762] RFC 6761 provided the process whereby Multicast DNS [RFC6762]
designated ".local" as a SUDN and included it in the Special-Use designated ".local" as a Special-Use Domain Name and included it in
Domain Names registry. It itself also enumerated a set of names that the Special-Use Domain Names registry. It itself also enumerated a
had been previously used or defined to have special uses prior to the set of names that had been previously used or defined to have special
publication of RFC6761. Since there had been no registry for these uses prior to the publication of RFC 6761. Since there had been no
names prior to the publication of RFC 6761, the documents defining registry for these names prior to the publication of RFC 6761, the
these names could not have added them to the registry. documents defining these names could not have added them to the
registry.
There are at least several important points to think of with respect There are at least several important points to think of with respect
to the RFC6761: to the RFC 6761:
o A special-use name may be a name that should be resolved using the o A Special-Use Domain Name may be a name that should be resolved
DNS protocol with no special handling. An example of this is 'IN- using the DNS protocol with no special handling. An example of
ADDR.ARPA.' this is 'IN-ADDR.ARPA.' (which is an example of a Special-Use
Domain Name that is not a TLD).
o A special-use name may be a name that is resolved using the DNS o A Special-Use Domain Name may be a name that is resolved using the
protocol, requires no special handling in the stub resolver, but DNS protocol, requires no special handling in the stub resolver,
requires special handling in the recursive resolver. An example but requires special handling in the recursive resolver. An
of this would be "10.in-addr.arpa." example of this would be "10.in-addr.arpa."
o A special-use name may be a name that requires special handling in o A Special-Use Domain Name may be a name that requires special
the stub resolver. An example would be a special-use top-level handling in the stub resolver. An example would be a Special-Use
name like '.local' which acts as a signal to indicate that the Top-Level Domain Name like '.local' which acts as a signal to
local stub resolver should use a non-DNS protocol for name indicate that the local stub resolver should use a non-DNS
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 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 The term "stub resolver" in this case 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, but it is in the stub resolver, as we are using the
term here, that the decision as to whether to use a protocol, and if term here, that the decision as to whether to use a protocol, and if
so which protocol, or whether to use a local database of some sort, so which protocol, or whether to use a local database of some sort,
is made. is made.
RFC6761 does not limit special-use names to TLDs. However, at RFC 6761 does not limit Special-Use Domain Names to TLDs. However,
present, all special-use names registered in the IANA Special-Use at present, all Special-Use Domain Names registered in the IANA
Domain Names registry [SDO-IANA-SUDR] are either intended to be Special-Use Domain Names registry [SDO-IANA-SUDR] are either intended
resolved using the DNS protocol, or are top-level domains, or both. to be resolved using the DNS protocol, or are TLDs, or both. That
That is, at present there exist no special-use names which require is, at present there exist no Special-Use Domain Names which require
special handling by stub resolvers and which are not at the top level 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
RFC6762 that when stub resolvers encounter the special label, RFC 6762 that when stub resolvers encounter the special label,
'.LOCAL' at the top level of a domain name, they can only use the '.LOCAL' at the top level of a domain name, they can only use the
mDNS protocol be used for resolving that Domain Name. mDNS protocol be used for resolving 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 [RFC2860] between the IETF
and ICANN (Internet Corporation for Assigned Names and Numbers) which and ICANN (Internet Corporation for Assigned Names and Numbers) which
discusses how names and numbers will be managed through the IANA discusses how names and numbers will be managed through the IANA
(Internet Assigned Numbers Authority). This document is important to (Internet Assigned Numbers Authority). This document is important to
the discussion of SUDNs because, while it delegates authority for the discussion of Special-Use Domain Names because, while it
managing the Domain Name System Namespace generally to ICANN, it delegates authority for managing the Domain Name System Namespace
reserves to the IETF the authority that RFC 6761 formalizes: generally to ICANN, it reserves to the IETF the 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 In general, then, the assignment of names in the DNS root zone, and
the management of the DNS namespace, is a function that is performed the management of the DNS namespace, is a function that is performed
by ICANN. However, the MoU specifically exempts domain names by ICANN. However, the MoU specifically exempts domain names
assigned for technical use, and uses the example of domains used for assigned for technical use, and uses the example of domains used for
inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the
special-use Domain Names registry. Special-Use Domain Names registry.
Implicit in the MoU is the fact that the IETF and ICANN retain,
between them, sole authority for assigning any names from the Domain
Namespace. Both the IETF and ICANN have internal processes for
making such assignments.
The point here is not to say what the implications of this statement 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.2. Secondary documents relating to the SUTLDN question 4.1.4. Liaison Statement on Technical Use of Domain Names
As a result of processing requests to add names to the Special-Use
Domain Name registry, as documented in
[I-D.chapin-additional-reserved-tlds] and
[I-D.grothoff-iesg-special-use-p2p-names], the IAB initiated a review
of the process defined in RFC 6761 for adding names to the registry.
This review was identified as in the charter of the IETF DNSOP
working group, and the review has been conducted in that working
group. The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of
the review, affirmed that the discussion would be "open and
transparent to participation by interested parties" and explicitly
invited members of the ICANN community to participate.
This document is a product of the IETF DNSOP working group review of
the registry process in RFC 6761.
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' SUTLDN. Section 3 describes the semantics of uses the '.LOCAL' Special-Use Top-Level Domain Name. Section 3
"multicast DNS names." It is of considerable historical importance describes the semantics of "multicast DNS names." It is of
to note that the -00 version of this document, an individual considerable historical importance to note that the -00 version of
submission, was published in July of 2001. This version contains this document, an individual submission, was published in July of
substantially the same text in section 3, and was discussed in the 2001. This version contains substantially the same text in section
DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51]. The 3, and was discussed in the DNSEXT working group at IETF 51 in August
first version of this document designated '.LOCAL.ARPA' as the of 2001[IETF-PRO-51]. The first version of this document designated
special-use name. This idea was strongly opposed by DNSEXT working '.LOCAL.ARPA' as the Special-Use Domain Name. This idea was strongly
group participants, and as a result the author eventually switched to opposed by DNSEXT working group participants, and as a result the
using '.LOCAL'. 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; some notable milestones include the initial proposal to Appendix H; some notable milestones include the initial proposal to
replace Appletalk's NBP in July 1997, the chartering of the Zeroconf replace Appletalk's NBP in July 1997, the chartering of the Zeroconf
working group in September 1999, assignment of a multicast address working group in September 1999, assignment of a multicast address
for link-local name discovery in April of 2000. A companion for link-local name discovery in April of 2000. A companion
requirements document, eventually published as [RFC6760] was first requirements document, eventually published as [RFC6760] was first
published in September of 2001. 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 TLD 4.2.2. The .onion Special-Use Top-Level Domain Name
The .onion Special Use TLD [RFC7686] is important because it is the The .onion Special-Use Top-Level Domain Name [RFC7686] is important
most recent IETF action on the topic of SUTLDNs; although it does not because it is the most recent IETF action on the topic of Special-Use
set new policy, the mere fact of its publication is worth thinking Domain Names; although it does not set new policy, the mere fact of
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 The situation was somewhat forced, both by the fact of its o The situation was somewhat forced, both by the fact of its
unilateral use by the TOR project without following the RFC 6761 unilateral use by The Tor Project without following the RFC 6761
process, and because a deadline had been set by the CA/Browser process, and because a deadline had been set by the CA/Browser
Forum [SDO-CABF-INT] after which all .onion PKI certificates would Forum [SDO-CABF-INT] after which all .onion PKI certificates would
expire and no new certificates would be issued, unless the .onion expire and no new certificates would be issued, unless the .onion
SUTLDN were to be recognized by the IETF. Special-Use Top-Level Domain Name were to be recognized by the
IETF.
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 practice
was first described) and IANA-Reserved IPv4 Prefix for Shared Address was first described) and IANA-Reserved IPv4 Prefix for Shared Address
Space [RFC6598]. Space [RFC6598].
This use case is distinct from the use-case for SUTLDNs like '.local' This use case is distinct from the use-case for Special-Use Domain
and '.onion' in that the names are resolved using the DNS protocol Names like '.local' and '.onion' in that the names are resolved using
(but do require extensions or exceptions to the usual DNS resolution the DNS protocol (but do require extensions or exceptions to the
to enforce resolution in a local context rather than the global DNS usual DNS resolution to enforce resolution in a local context rather
context). But it shares the problem that such names cannot be than the global DNS context). But it shares the problem that such
assumed either to be unique or to be functional in all contexts for names cannot be assumed either to be unique or to be functional in
all Internet-connected hosts. all contexts 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 commissioned by
ICANN that attempts to characterize the potential risk to the ICANN that attempts to characterize the potential risk to the
Internet of adding global DNS delegations for names that were not Internet of adding global DNS delegations for names that were not
previously delegated in the DNS, not reserved under any RFC, but also previously delegated in the DNS, not reserved under any RFC, but also
known to be (.home) or surmised to be (.corp) in significant use for known to be (.home) or surmised to be (.corp) in significant use for
special-use-type reasons (local scope DNS, or other resolution 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
This document reports on some issues surrounding the conflicting SSAC Advisory on the Stability of the Domain Namespace
[SDO-ICANN-SAC090] reports on some issues surrounding the conflicting
uses, interested parties and processes related to the Domain uses, interested parties and processes related to the Domain
Namespace. The document recommends the development of collaborative Namespace. The document recommends the development of collaborative
processes among the various interested parties to coordinate their processes among the various interested parties to coordinate their
activities related to the Domain Namespace. 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 RFC
6761 process to designate '.ipv4only.arpa' as a special-use name; in 6761 process to designate '.ipv4only.arpa' as a Special-Use Domain
this case the process worked smoothly and without controversy. Name; in this case the process worked smoothly and without
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 IAB was able to simply add the name to the .ARPA happened because the IAB was able to simply add the name to the .ARPA
zone, which the IAB administers. This is an illustration of one of zone, which the IAB administers. This is an illustration of one of
the problems that we have with the 6761 process: it is apparently the problems that we have with the 6761 process: it is apparently
fairly easy to miss the step of adding the name to the registry. fairly easy to 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
[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
it was intended to fill still exists. Unfortunately, although a fair it was intended to fill still exists. Unfortunately, although a fair
amount is known about the use of these names, no document exists that amount is known about the use of these names, no document exists that
documents how they are used, and why it would be a problem to documents how they are used, and why it would be a problem to
delegate them. Additionally, to the extent that the uses being made delegate them. Additionally, to the extent that the uses being made
of these names are valid, no document exists indicating when it might of these names are valid, no document exists indicating when it might
make sense to use them, and when it would not make sense to use them. 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 Domain Name TLD ".home" for use as the
default name for name resolution relative to a home network context. default name for name resolution relative to a home network context.
Although, as defined in RFC 7788, ".home" is a special-use Domain Although, as defined in RFC 7788, ".home" is a Special-Use Domain
Name, RFC 7788 did not follow the process in RFC 6761 and request the Name, RFC 7788 did not follow the process in RFC 6761 and request the
addition of ".home" to the IANA Special-Use Domain Name registry. addition of ".home" to the IANA Special-Use Domain Name registry.
Additionally, ".home" is an example of an attempt to reuse a Domain Additionally, ".home" is an example of an attempt to reuse a Domain
Name that has already been commandeered for other purposes Name that has already been put into use for other purposes without
[SDO-ICANN-COLL], which further complicates the situation. At the following established processes[SDO-ICANN-COLL], which further
time this document was written, the IETF was developing a solution to complicates the situation. At the time this document was written,
this problem. the IETF was developing a solution to this problem.
4.3. Summary
How names are resolved is ambiguous, in the sense that some names are
special-use names that require special handling, and some names can
be resolved using the DNS protocol with no special handling.
The assignment of Internet Names is not under the sole control of any
one organization. IETF has authority in some cases, but only with
respect to "technical uses." ICANN at present is the designated
administrator of the root zone, but generally not of zones other than
the root zone. And neither of these authorities can in any practical
sense exclude the practice of ad-hoc use of names. This can be done
by any entity that has control over one or more name servers or
resolvers, in the context of any hosts and services that that entity
operates. It can also be done by authors of software who decide that
a special-use name is the right way to indicate the use of an
alternate resolution mechanism.
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 memories would have been fresh of the evolutionary process that led
to the DNS' dominance as a protocol for Domain Name resolution. to the DNS' dominance as a protocol for Domain Name resolution.
skipping to change at page 15, line 20 skipping to change at page 17, line 36
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 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' SUTLDN. the special meaning of the '.local' Special-Use Top Level Domain
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"
top-level domain for internal use, and this practice was very much a TLD for internal use, and this practice was very much a part of the
part of the zeitgeist at the time (see section 5.1 of zeitgeist at the time (see section 5.1 of [SDO-ICANN-COLL] and
[SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at Appendix G of [RFC6762]). This attitude is at the root of the
the root of the widespread practice of simply picking an unused top- widespread practice of simply picking an unused TLD and using it for
level domain and using it for experimental purposes, which persists experimental purposes, which persists even at the time of writing of
even at the time of writing of this memo. this memo.
This history is being presented because discussions about special-use This history is being presented because discussions about Special-Use
names in the IETF often come down to the question of why users of new Domain Names in the IETF often come down to the question of why users
name resolution protocols choose to use Domain Names, rather than of new name resolution protocols choose to use Domain Names, rather
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. Contributors 6. Security Considerations
This document mentions various security and privacy considerations in
the text. However, this document creates no new security or privacy
concerns.
7. IANA considerations
This document has no actions for IANA.
8. Contributors
This document came about as a result of conversations that occurred This document came about as a result of conversations that occurred
in the conference hotel lobby, the weekend before IETF 95, when the in the conference hotel lobby, the weekend before IETF 95, when the
original author, Ted Lemon, was trying to come up with a better original author, Ted Lemon, was trying to come up with a better
problem statement. Stuart Cheshire, Mark Andrews, David Conrad, Paul problem statement. Stuart Cheshire, Mark Andrews, David Conrad, Paul
Ebersman and Aaron Falk all made helpful and insightful observations 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.
skipping to change at page 16, line 28 skipping to change at page 19, line 5
was the key motivating factor in the writing of this document, and he was the key motivating factor in the writing of this document, and he
agreed to co-author it without too much arm-twisting. Warren spent a agreed to co-author it without too much arm-twisting. Warren spent a
lot of time working with us on this document after it was first lot of time working with us on this document after it was first
published, and joined as an author in order to make sure that the 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 work got finished; without him the -01 and -02 versions might not
have happened. 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].
7. Informative References 9. Informative References
[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 17, line 20 skipping to change at page 19, line 45
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>. <http://www.rfc-editor.org/info/rfc1918>.
[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
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
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] [I-D.chapin-additional-reserved-tlds]
Chapin, L. and M. McFadden, "Additional Reserved Top Level Chapin, L. and M. McFadden, "Additional Reserved Top Level
Domains", draft-chapin-additional-reserved-tlds-02 (work Domains", draft-chapin-additional-reserved-tlds-02 (work
in progress), March 2015. 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] [I-D.lewis-domain-names]
Lewis, E., "Domain Names", draft-lewis-domain-names-04 Lewis, E., "Domain Names", draft-lewis-domain-names-05
(work in progress), September 2016. (work in progress), February 2017.
[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://www.digicert.com/internal-names.htm>.
[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-
skipping to change at page 19, line 11 skipping to change at page 21, line 45
Names registry", October 2015, Names registry", October 2015,
<http://www.iana.org/assignments/special-use-domain-names/ <http://www.iana.org/assignments/special-use-domain-names/
special-use-domain-names.xhtml>. special-use-domain-names.xhtml>.
[SDO-ICANN-DAG] [SDO-ICANN-DAG]
Internet Assigned Numbers Authority, "Special-Use Domain Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015, Names registry", October 2015,
<https://newgtlds.icann.org/en/applicants/agb/guidebook- <https://newgtlds.icann.org/en/applicants/agb/guidebook-
full-04jun12-en.pdf>. 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>.
[CORP-SUN-NIS] [CORP-SUN-NIS]
Sun Microsystems, "Large System and Network Sun Microsystems, "Large System and Network
Administration", March 1990. Administration", March 1990.
[IETF-PRO-51] [IETF-PRO-51]
Internet Engineering Task Force, "Proceedings of the 51st Internet Engineering Task Force, "Proceedings of the 51st
IETF", August 2001, IETF", August 2001,
<http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>. <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
[TOR] The Tor Project, "Tor", 2017,
<https://www.torproject.org>.
Appendix A. Change Log. Appendix A. Change Log.
-02 to -03 (in Github):
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.
Issue #57: Document needs an "Security Considerations" section
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/57
Numerous editorial changes for consistency; e.g. use "Special-Use
Domain Names" throughout.
Issue #58: Document needs an "IANA Considerations" section
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/58
Issue #39: Overlapping bullets in Section 3, with proposed
restructuring -- Russ Housley https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/39
Issue #55: Editorial improvement to Section 3 (4) -- John
Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/55
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
Issue #52: Editorial improvement to Section 3 (1) -- John
Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/52
Issue #51: Clarification in Introduction -- John Dickinson
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/51
Issue #49: Should cite https://datatracker.ietf.org/liaison/1351
-- George Michaelson https://github.com/Abhayakara/draft-tldr-
sutld-ps/issues/49
Issue #50: IETF precedence in Special-Use names registry -- Ted
Lemon https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/50
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
Issue #47: 4.3 should be made more prominent -- George Michaelson
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/47
Issue #43: Spell out SUDN and SUTLDN rather than use acronyms --
Russ Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/43
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
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
Issue #37: Title should be "Special-Use Domain Names Problem
Statement" -- Russ Housley https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/37
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
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
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
Issue #12: Add DNSSEC to text -- John Levine
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/12
Issue #6: Without a process, we just have chaos -- Stuart Cheshire
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/6
Issue #32: Have assignments through RFC 6761 really had "technical
mistakes"? -- Suzanne Wolff https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/32
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
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
Issue #24: Replacement for "commandeer" (2 issues)-- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/24
Issue #22: Clarify importance of the "root of the Domain
Namespace" -- Suzanne Wolff https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/22
Issue #21: Section 3 - clarify paragraphs 2 and 3 -- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/21
Issue #20: Section 3: Clarify sentences beginning "Solutions to
these problems..." -- Suzanne Wolff https://github.com/Abhayakara/
draft-tldr-sutld-ps/issues/20
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
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
Issue #45: Correct usages of Tor Browser and Tor -- Russ Housley
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/45)
Issue #46: Reformat citation of RFC 2860 -- Russ Housley
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/46)
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)
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)
Issue #30: Leaked queries aren't an operational problem in
practice -- Suzanne Wolf (https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/30)
Address some of the simpler issues, including:
Issue #13: Spelling of Tor -- Jeremy Rand
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/13)
Issue #14: Change SDO to "organizations" -- Suzanne Woolf
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14)
Issue #16: Match number of "policies" and "that policy" -- Suzanne
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/16)
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)
Issue #23: Match number of "names" and "a TLD" -- Suzanne.
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/23)
-01 to -02: -01 to -02:
Language cleanup from Ted. Language cleanup from Ted.
-00 to -01: -00 to -01:
Improved the terminology. Improved the terminology.
Included reference to SAC090. Included reference to SAC090.
 End of changes. 98 change blocks. 
283 lines changed or deleted 567 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/