< draft-adpkja-dnsop-special-names-problem-01.txt   draft-adpkja-dnsop-special-names-problem-02.txt >
Network Working Group J. Abley Network Working Group J. Abley
Internet-Draft Dyn, Inc. Internet-Draft Dyn, Inc.
Intended status: Informational P. Koch Intended status: Informational P. Koch
Expires: September 9, 2016 DENIC Expires: September 21, 2016 DENIC eG
A. Durand A. Durand
ICANN ICANN
W. Kumari W. Kumari
Google Google
March 08, 2016 March 20, 2016
Problem Statement for the Reservation of Top-Level Domains in the Problem Statement for the Reservation of Top-Level Domains in the
Special-Use Domain Names Registry Special-Use Domain Names Registry
draft-adpkja-dnsop-special-names-problem-01 draft-adpkja-dnsop-special-names-problem-02
Abstract Abstract
The dominant protocol for name resolution on the Internet is the The dominant protocol for name resolution on the Internet is the
Domain Name System (DNS). However, other protocols exist that are Domain Name System (DNS). However, other protocols exist that are
fundamentally different from the DNS, and may or may not share the fundamentally different from the DNS, and may or may not share the
same namespace. same namespace.
When an end-user triggers resolution of a name on a system which When an end-user triggers resolution of a name on a system which
supports multiple, different protocols (or resolution mechanisms) for supports multiple, different protocols (or resolution mechanisms) for
name resolution, it is desirable that the protocol used is name resolution, it is desirable that the protocol used is
unambiguous, and that requests intended for one protocol are not unambiguous, and that requests intended for one protocol are not
inadvertently answered using another. inadvertently answered using another.
[RFC6761] introduced a framework by which, under certain RFC 6761 introduced a framework by which, under certain
circumstances, a particular domain name could be acknowledged as circumstances, a particular domain name could be acknowledged as
being special. This framework has been used twice to reserve top- being special. This framework has been used twice to reserve top-
level domains (.local and .onion) that should not be used within the level domains (.local and .onion) that should not be used within the
DNS to avoid the possibility of namespace collisions in parallel use DNS, to avoid the possibility of namespace collisions in parallel use
of non-DNS name resolution protocols. of non-DNS name resolution protocols.
Various challenges have become apparent with this application of the Various challenges have become apparent with this application of the
guidance provided in [RFC6761]. This document aims to document those guidance provided in RFC 6761. This document aims to document those
challenges in the form of a problem statement, to facilitate further challenges in the form of a problem statement, to facilitate further
discussion of potential solutions. discussion of potential solutions.
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 September 9, 2016. This Internet-Draft will expire on September 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RFC6761 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. RFC 6761 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architectural considerations . . . . . . . . . . . . . . . . 6 4. Architectural Considerations . . . . . . . . . . . . . . . . 6
5. Technical considerations . . . . . . . . . . . . . . . . . . 8 5. Technical Considerations . . . . . . . . . . . . . . . . . . 8
6. Organizational considerations . . . . . . . . . . . . . . . . 9 6. Organizational Considerations . . . . . . . . . . . . . . . . 9
6.1. Non-exhaustive list of external organizational 6.1. External Organizational Considerations . . . . . . . . . 9
considerations . . . . . . . . . . . . . . . . . . . . . 9 6.2. IETF Internal Considerations . . . . . . . . . . . . . . 10
6.2. IETF Internal considerations . . . . . . . . . . . . . . 10
6.2.1. Process . . . . . . . . . . . . . . . . . . . . . . . 10 6.2.1. Process . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.2. Technical criteria . . . . . . . . . . . . . . . . . 11 6.2.2. Technical Criteria . . . . . . . . . . . . . . . . . 11
6.2.3. Name evaluation . . . . . . . . . . . . . . . . . . . 12 6.2.3. Name evaluation . . . . . . . . . . . . . . . . . . . 12
6.2.4. The ICANN process to evaluate names . . . . . . . . . 12 6.3. The ICANN process to evaluate names . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 16 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 16
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. Pithy Quotes from History . . . . . . . . . . . . . . . . 16 A.2. Pithy Quotes from History . . . . . . . . . . . . . . . . 17
A.3. Change History . . . . . . . . . . . . . . . . . . . . . 17 A.3. Change History . . . . . . . . . . . . . . . . . . . . . 17
A.3.1. draft-adpkja-special-names-problem-00 . . . . . . . . 17 A.3.1. draft-adpkja-special-names-problem-00 . . . . . . . . 17
Appendix B. Change history . . . . . . . . . . . . . . . . . . . 17 Appendix B. Change history . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Terminology 1. Terminology
Clear and unambiguous use of terminology is important for the clear Clear and unambiguous use of terminology is important for the clear
formulation of any problem statement. The DNS protocol suffers from formulation of any problem statement. The DNS protocol suffers from
imprecise and overloaded terminology (e.g. see RFC7719). The use of imprecise and overloaded terminology (for example, see [RFC7719]).
terms and concepts from other naming systems that are similar (but The use of terms and concepts from other naming systems that are
different) simply confuses matters further. similar (but different) simply confuses matters further.
In the interests of clarity, the following terms used in this In the interests of clarity, the following terms used in this
document are to be interpreted as follows: document are to be interpreted as follows:
Registry (n): the Special-Use Domain Names Registry created by Registry (n): the Special-Use Domain Names Registry created by
[RFC6761] and published at <https://www.iana.org/assignments/ [RFC6761] and published at [IANA-SPECIAL-USE].
special-use-domain-names/special-use-domain-names.xhtml>
[This section to be completed following review and refinement of the [This section to be completed following review and refinement of the
rest of the text.] rest of the text.]
2. Introduction 2. Introduction
A number of systems use the last label in a name to act as a switch Some systems use the last label in a name to act as a switch to a
to a different, non-DNS resolution process - examples of such different, non-DNS resolution process - examples of such switches
switches include: .local (use mDNS) and .onion (use Tor). This include: .local (to use mDNS) and .onion (to use Tor). This switch
switch practice is not explicitly documented anywhere, and the method practice is not explicitly documented anywhere, and the method for
for accomplishing this varies by implementation. As an interesting accomplishing this varies by implementation. As an interesting
aside, the full semantics of domain names isn't really documented aside, the full semantics of domain names isn't really documented
anywhere either, although [Ed Lewis domain-names draft] is a current anywhere either, although [I-D.lewis-domain-names] is a current
attempt to rectify this. attempt to rectify this.
This technique of using the last label as a switch has a number of This technique of using the last label as a switch has a number of
properties which make it attractive to people implementing alternate properties which make it attractive to people implementing alternate
name resolution systems, including: name resolution systems, including:
o The names can follow the common DNS syntax of LDH labels, o The names can follow the common DNS syntax of LDH labels,
separated by dots. This means that these names can be entered in separated by dots. This means that these names can be entered in
any application which takes exiting DNS names. any application which takes existing DNS names.
o The switch to the new resolution process can be implemented in a o The switch to the new resolution process can be implemented in a
number of ways, such as custom application code, a shim in the number of ways, such as custom application code, a shim in the
normal DNS resolution process, or on the system's configured DNS normal DNS resolution process, or on the system's configured DNS
servers. servers.
o The names "look" like names to users. o The names "look" like names to users.
At this point, one should note RFC6303, which already defines Note that [RFC6303] defines "locally served zones". The important
"locally served zones", with the important difference that per difference is that in [RFC6303], the names get registered for special
RFC6303 the names get registered for special treatment if they are treatment if they are already special: they are not declared special
already special - they are not declared special by the registration. by the registration.
[RFC6761] defines ways to reserve domain names and could be read to [RFC6761] defines ways to reserve domain names. This could be read
augment the technical exemption made in [RFC2860] (IETF-ICANN MoU): to augment the technical uses exemption made in [RFC2860] (also
called "the IETF-ICANN MoU"). [RFC2860] says:
"Note that (a) assignments of domain names for technical uses "Note that (a) assignments of domain names for technical uses
(such as domain names for inverse DNS lookup), (b) assignments of (such as domain names for inverse DNS lookup), (b) assignments of
specialized address blocks (such as multicast or anycast blocks), specialized 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 framework in [RFC6761]RFC6761 has recently been used to reserve The framework in [RFC6761] has recently been used to reserve the
the .onion label, allowing it to be used as a switch to the tor .onion label, allowing it to be used as a switch to the Tor
resolution process[RFC7686]. By the .onion label in the "Special-Use resolution process, as described in [RFC7686]. Because the .onion
Domain Names" registry [TODO: WK - Link], The Tor Project can be label in the IANA "Special-Use Domain Names" registry
assured that there will not be a .onion TLD created in the IANA [IANA-SPECIAL-USE], the Tor Project can be assured that there will
rooted DNS, and thus the possibility of collisions in the namespace not be a .onion TLD created in the IANA rooted DNS, and thus the
will be avoided. possibility of collisions in the namespace will be avoided.
The discussions in the DNSOP WG and the IETF Last Call processes The discussions in the DNSOP Working Group (WG) and the IETF Last
about the .onion registration in the Special Use Domain Names Call processes for the .onion registration in the Special Use Domain
registry (1,200 messages) have made it apparent that clarity about if Names registry (1,200 messages) have made it apparent that clarity
and how to treat this "protocol switching" practice would help a lot about if and how to treat this "protocol switching" practice would
in deciding the merit of future similar applications. help a lot in deciding the merit of future similar applications.
One possible outcome of the discussion would be to decline to One possible outcome of the discussion would be to decline to
recognize such usage of domain names in the architecture, another one recognize such usage of domain names in the architecture; another
is to formalize it and better understand the issues that come with possible outcome is to formalize it and better understand the issues
it. that come with it.
An additional consideration is that names which follow the DNS syntax An additional consideration is that names which follow the DNS syntax
(including those which use alternate name resolutions processes to (including those which use alternate name resolutions processes to
the DNS) are in the same namespace as names in the DNS. This means the DNS) are in the same namespace as names in the DNS. This means
that currently both the IETF (through [RFC6761]) and ICANN are making that currently both the IETF (through [RFC6761]) and ICANN are making
allocations or reservations from a shared namespace. If this allocations or reservations from a shared namespace. If this
continues to be the case, in order to avoid conflict, close continues to be the case, in order to avoid conflict, close
coordination is necessary. coordination between the two organizations is necessary.
3. RFC6761 3. RFC 6761
In Section 5, [RFC6761] describes seven questions to be answered to Section 5 of [RFC6761] describes seven questions to be answered to
justify how and why a particular domain name is special. These seven justify how and why a particular domain name is special. These seven
questions can be broadly categorized as follows: questions can be broadly categorized as follows:
1. impact on end-users; 1. impact on end-users;
2. impact on applications; 2. impact on applications;
3. impact on name resolution APIs and libraries; 3. impact on name resolution APIs and libraries;
4. impact on recursive resolvers; 4. impact on recursive resolvers;
5. impact on authoritative DNS servers; 5. impact on authoritative DNS servers;
6. impact on DNS server operators; 6. impact on DNS server operators;
7. impact on DNS registries and registrars. 7. impact on DNS registries and registrars.
The intent of those seven questions was originally to serve as the The intent of those seven questions was originally to serve as the
justifications for *why* the special-use registration should be justifications for why a proposed special-use registration should be
granted, demonstrating that it (a) provides a result that the granted, demonstrating that it (a) provides a result that the
community judges to be good, and (b) the aforementioned good result community judges to be good, and (b) the aforementioned good result
cannot reasonably be achieved in another way. The rough consensus cannot reasonably be achieved in another way. The rough consensus
from significant discussion was that .onion did satisfy both (a) and from significant discussion was that .onion did satisfy both (a) and
(b), but this was not clearly demonstrated by the answers to the (b), but this was not clearly demonstrated by the answers to the
"seven questions". Furthermore, it is unclear if and how these "seven questions". Furthermore, it is unclear if and how these
questions could reliably and unambiguously be used to make the questions could reliably and unambiguously be used to make the
determination, leading to the conclusion that they are generally determination, leading to the conclusion that they are generally
inadequate for making the determination whether a particular domain inadequate for making the determination whether a particular domain
name qualifies as requiring special/different treatment. name qualifies as requiring special/different treatment.
Applications which follow the [RFC6761] process are likely to devolve Applications which follow the [RFC6761] process are likely to devolve
into a "beauty contest". More over, the answers to the seven into a "beauty contest". Moreover, the answers to the seven
questions are not available in a machine readable form to questions are not available in a machine readable form to
applications that want to follow [RFC6761]. applications that want to follow [RFC6761].
So the answers to these seven questions can better be seen as So the answers to these seven questions can better be seen as
providing guidance to the corresponding seven audiences on how to providing guidance to the corresponding seven audiences on how to
handle a special-use domain name once it has been reserved by handle a special-use domain name once it has been reserved by
inclusion in the Registry, and not as entrance filters for inclusion inclusion in the Registry, and not as entrance filters for inclusion
in the registry. in the registry.
They specify desired behavior in the internet for handling a The answers to the seven questions specify desired behavior in the
particular domain name, not the basis for deciding whether the effort internet for handling a particular domain name, not the basis for
to implement special behavior across all of those audiences is worth deciding whether the effort to implement special behavior across all
the cost. This indifference to costs is not necessarily scalable. of those audiences is worth the cost. This indifference to costs is
not necessarily scalable for making future decisions about potential
inclusion in the registry.
The justification in [RFC6761] is concerned with the rationale of The justification in [RFC6761] is concerned with the rationale of
reserving a domain name that precludes its subsequent use as a reserving a domain name that precludes its subsequent use as a top
generic top level domain name. However, the document fails to offer level domain name. However, the document fails to offer such a
such a rationale, and instead requires the justification of the rationale, and instead requires the justification of the reserved
reserved name to include the provision of guidance to a number of name to include the provision of guidance to a number of audiences
audiences (users, application developers, DNS resolver applications, (users, application developers, DNS resolver applications, DNS
DNS resolution service operators, and name registries and registrars) resolution service operators, and name registries and registrars) as
as to how to handle names that are listed in this registry. But this to how to handle names that are listed in this registry. But this
guidance is not, in and of itself, an adequate rationale for the guidance is not, in and of itself, an adequate rationale for the
selection of a particular name value to be reserved in this registry. selection of a particular name value to be reserved in this registry.
What is missing in [RFC6761] is the consideration of the name itself. What is missing in [RFC6761] is the consideration of the name itself.
If one were to contrast the procedures relating to the admission of a If one were to contrast the procedures relating to the admission of a
name to the IETF Special Use Name registry to the processes name to the IETF Special Use Name registry to the processes
associated with the New gTLD Program operated by ICANN, then it is associated with the New gTLD Program operated by ICANN [NEW-GTLD],
evident that the IETF process does not admit many considerations then it is evident that the IETF process does not admit many
which appear to be areas of evaluation in the new gTLD program. More considerations which appear to be areas of evaluation in the New gTLD
on this in a subsequent section. program. More on this in section Section 6.3.
This memo proposes to categorize considerations related to the usage This document proposes to categorize considerations related to the
of RFC6761 registry for protocol switches in 3 categories: usage of the [RFC6761] registry for protocol switches in 3
Architectural, Technical and Organizational. This memo then lists a categories: Architectural, Technical and Organizational. This
number of questions to drive the discussion. The list of issues document then lists a number of questions to drive the discussion.
discussed here is non-exhaustive. The list of issues discussed here is non-exhaustive.
However, some voices have noted that [RFC6761] describes other However, some people have noted that [RFC6761] describes other
alternative special handling aside from protocol switches. That alternative special handling aside from protocol switches. That
alternative special handling must be considered carefully at the time alternative special handling must be considered carefully at the time
of publication of the defining RFC, regardless of the nature of the of publication of the defining RFC, regardless of the nature of the
special use. special use.
4. Architectural considerations 4. Architectural Considerations
The first thing to consider in this discussion is that not all names The first thing to consider in this discussion is that not all names
(or domain names) are part of the Domain Name System. See [ID-lewis- (or domain names) are part of the Domain Name System. See
domain-names] for an in-depth discussion on this topic. [I-D.lewis-domain-names] for an in-depth discussion on this topic.
At the time of writing, two top-level domain names reserved by At the time of writing, two top-level domain names reserved by
inclusion in the Registry are used by name resolution protocols other inclusion in the Registry went through the [RFC6761] process and are
than the DNS and went through the [RFC6761] process: used by name resolution protocols other than the DNS:
.local is used by the Multicast DNS protocol specified in .local is used by the Multicast DNS protocol specified in
[RFC6762] which is similar in some respects to the DNS, but which [RFC6762] which is similar in some respects to the DNS, but which
uses a different well-known port number and is limited to a uses a different well-known port number and is limited to a
particular multicast scope; particular multicast scope;
ONION is used to construct names that designate services reachable .onion is used to construct names that designate services
via the Tor network using onion routing. reachable via the Tor network using onion routing.
These two name resolution protocols are, to varying degrees,
different from the DNS, and the namespaces used in each naming scheme
are also different. The top-level label is effectively being used as
a name resolution protocol identifier. At the core of the issue is
that different "strings" that look like "domain names" (i.e. are
within the same name space) but are not DNS names are used
interchangeably in the URI (or URN).
In particular, DNS imposes constraints on name syntax. An example of
such constraints is the 63 octet limit per label. Strings used in
the .onion domain do not have that constraint.
The two name resolution protocols described above are, to varying
degrees, different from the DNS, and the namespaces used in each
naming scheme are also different (albeit similar, in the .local
case). The top-level label is effectively being used as a name
resolution protocol identifier. At the core of the issue is that
different "strings" that look like "domain names" (i.e. are within
the same name space) but are not DNS names are used interchangeably
in the URI (or URN). In particular, DNS imposes constraints on name
syntax. An example of such constraints is the 64 octet limit per
label. Strings used in the ONION domain do not have that constraint.
It could be argued that in the absence of a more elegant alternative, It could be argued that in the absence of a more elegant alternative,
a pragmatic choice to embed protocol selectors as namespace tokens a pragmatic choice to embed protocol selectors as namespace tokens
has effectively already been made. The running code and effective has effectively already been made. The running code and effective
consensus in how it should be used by significant user bases should consensus in how it should be used by significant user bases should
not be discounted. Although the reservation of names in the DNS not be discounted. Although the reservation of names in the DNS
namespace can be made at any level, the two examples above namespace can be made at any level, the two examples above
demonstrate use-cases for reservation at the top-level, and hence demonstrate use-cases for reservation at the top-level, and hence
that case must be considered. that case must be considered.
The underlying discussion here is the tussle between the applications The underlying discussion here is the tussle between the applications
and the network. Application architects see using special name tags and the network. Application architects see using special name tags
(a la .onion) as an easy way to get new features deployed. They (such as .onion) as an easy way to get new features deployed. They
consider the hurdles of deploying new URI schemes such as consider the hurdles of deploying new URI schemes such as
http:/onion/onion-name as too onerous and too slow to deploy for http:/onion/onion-name as too onerous and too slow to deploy for
their needs. Network architects worry of overloading the semantics their needs. Network architects worry of overloading the semantics
of DNS names and/or creating a name space that is larger than the DNS of DNS names and/or creating a name space that is larger than the DNS
namespace. They refer to bad precedents such as .uucp and .bitnet. namespace. They refer to bad precedents such as .uucp and .bitnet.
The fundamental point to consider here is the unicity (or The fundamental point to consider here is the unicity (or
multiplicity) of the name space. Are we talking about one namespace multiplicity) of the name space. Are we talking about one namespace
with different resolution protocols or independent name spaces? with different resolution protocols or independent name spaces?
skipping to change at page 8, line 4 skipping to change at page 7, line 49
didn't expect names constructed according to whatever rules they're didn't expect names constructed according to whatever rules they're
following to be unique across a set of names that spans multiple following to be unique across a set of names that spans multiple
operating environments and resolution protocols. operating environments and resolution protocols.
In [RFC2826] the IAB noted that In [RFC2826] the IAB noted that
"To remain a global network, the Internet requires the existence "To remain a global network, the Internet requires the existence
of a globally unique public name space. The DNS name space is a of a globally unique public name space. The DNS name space is a
hierarchical name space derived from a single, globally unique hierarchical name space derived from a single, globally unique
root." root."
"Maintaining a globally-unique public namespace that supports "Maintaining a globally-unique public namespace that supports
different name resolution protocols is hence an architectural different name resolution protocols is hence an architectural
requirement, and some facility for reservation of top-level requirement, and some facility for reservation of top-level
domains in the DNS is necessary." domains in the DNS is necessary."
If we were to accept the notion that the last label of a domain name If we were to accept the notion that the last label of a domain name
is actually a protocol switch, we are actually building a catalog of is actually a protocol switch, we are actually building a catalog of
all top level domains and what resolution protocol each one invokes. all top level domains and what resolution protocol each one invokes.
Note that such a catalog does not formally exist today, as [RFC6761] Note that such a catalog does not formally exist today, because
is an exception list to the general case which is supposed to use [RFC6761] is an exception list to the general case which is supposed
regular DNS as resolution protocol. Such a catalog may remain a to use regular DNS as resolution protocol. Such a catalog may remain
concept to guide this discussion or be implemented as an actual IANA a concept to guide this discussion or be implemented as an actual
registry. In effect, it would associate TLDs with indications on how IANA registry [IANA-SPECIAL-USE]. In effect, it would associate TLDs
applications and resolvers should treat them. However, such an with indications on how applications and resolvers should treat them.
approach would leave open the question of not-yet-defined TLDs. No However, such an approach would leave open the question of not-yet-
resolution mechanism could be associated with those. defined TLDs. No resolution mechanism could be associated with those
in advance so that systems would have to continue to assume that such
names are part of the DNS. For reasons of completeness it is noted
that suggestions have been made to help the distinction by using
special labels (as in IDNs).
It should also be noted that there are choices for a protocol switch It should also be noted that there are choices for a protocol switch
other than reserving labels. In particular, a proposal to move those other than reserving labels. In particular, a proposal to move those
protocol switches under a specific top level domain has been protocol switches under a specific top level domain has been
discussed (.ALT). If that architecture choice is made, some of the discussed (.ALT). If that architecture choice is made, some of the
questions listed in the sections below would become moot. questions listed in the sections below would become moot.
Note: [RFC6761] mentions the reserved names could be any label in any Note: [RFC6761] mentions the reserved names could be any label in a
random string, not just the rightmost one (or ones). However, this domain name, not just the rightmost one (or ones). However, this
creates a number of complications and has not seen much support in creates a number of complications and has not seen much support in
the community as of now. the community as of now.
5. Technical considerations 5. Technical Considerations
Each of the seven questions posed by [RFC6761] has the potential to Each of the seven questions posed by [RFC6761] has the potential to
describe why special handling of the requested name(s) in describe why it may be necessary for special handling of the
applications by a particular audience may be necessary. However, requested name(s) in applications by a particular audience. However,
aside from reserving the name, it is not entirely clear what any of aside from reserving the name, it is not entirely clear what any of
those audiences might further expect as a result of a successful those audiences might further expect as a result of a successful
request to add a top-level domain to the Registry. request to add a top-level domain to the Registry.
For example, reservation of a top-level domain by the IETF does not For example, reservation of a top-level domain by the IETF does not
guarantee that DNS queries for names within a reserved domain will guarantee that DNS queries for names within a reserved domain will
not be sent over the Internet. The requirements of the operators of not be sent over the Internet. The requirements of the operators of
recursive resolvers in the DNS cannot be relied upon to be recursive resolvers in the DNS cannot be relied upon to be
implemented; the impact on the operators of DNS authoritative servers implemented; the impact on the operators of DNS authoritative servers
hence cannot be reliably assumed to be zero. In the case of [I- hence cannot be reliably assumed to be zero. In the case of
D.ietf-dnsop-onion-tld], leakage of .onion queries on the Internet [RFC7686], leakage of .onion queries on the Internet might lead to
might lead to disclosure of private information that, in some cases, disclosure of private information that, in some cases, might pose a
might pose a risk to the personal safety of end-users. risk to the personal safety of end-users.
At the time of writing, the [RFC6761] registry does not include At the time of writing, the [RFC6761] registry does not include
direct guidance for any of the seven audiences, relying instead upon direct guidance for any of the seven audiences, relying instead upon
a reference for each entry in the Registry to the document that a reference for each entry in the Registry to the document that
requested its insertion. Such documents might well be opaque to many requested its insertion. Such documents might well be opaque to many
readers; ([RFC6762] is a seventy-page protocol specification, for readers; [RFC6762] is a seventy-page protocol specification, for
example, which is arguably not the most effective way to set example, which is arguably not the most effective way to set
expectations of non-technical end-users). expectations of non-technical end-users).
Useful reservations of top-level domains should be accompanied by Useful reservations of top-level domains should be accompanied by
documentation of realistic expectations of each of the seven documentation of realistic expectations of each of the seven
audiences, and the evaluation of particular requests should consider audiences, and the evaluation of particular requests should consider
the practical likelihood of those expectations being met and the the practical likelihood of those expectations being met and the
implications if they are not. implications if they are not.
Here is a non-exhaustive list of additional questions that have Here is a non-exhaustive list of additional questions that have
surfaced in discussion of requests for names to be added to the surfaced in discussion of requests for names to be added to the
Special Use Names registry: Special Use Names registry:
What does it mean to have a "non-DNS" entry in the registry What does it mean to have a "non-DNS" entry in the registry
described above? described above?
Are applications supposed to check that registry to know what to Are applications supposed to check that registry to know what to
do? do?
Can/Should applications do this check dynamically? Can, or should, applications do this check dynamically?
What if an application makes this dynamic check and realizes the What if an application makes this dynamic check and discovers the
name contains a switch it does not know how to treat? name contains a switch it does not know how to handle?
Similar questions applies to resolvers (DNS and non-DNS); what is the Similar questions applies to resolvers (DNS and non-DNS); what is the
expected behavior? expected behavior?
One particular avenue of investigation would be to see if such One particular avenue of investigation would be to see if such
considerations could be encoded in machine understandable code in an considerations could be encoded in machine understandable code in an
extension of the current [RFC6761] registry. extension of the current [RFC6761] registry.
6. Organizational considerations 6. Organizational Considerations
Organizational considerations can be broken down in two categories, This section gives two categories of organizational considerations:
internal and external. external and internal.
6.1. Non-exhaustive list of external organizational considerations 6.1. External Organizational Considerations
The policy surrounding the implementation and management of top-level The policy surrounding the implementation and management of top-level
domains in the DNS has been developed using a multi-stakeholder domains in the DNS has been developed using a multi-stakeholder
process convened by ICANN according to the MoU between ICANN and IETF process convened by ICANN according to the MoU between ICANN and IETF
[RFC2860]. It is out of scope for this document to revisit that MoU. [RFC2860]. It is out of scope for this document to revisit that MoU.
Whilst discussing the particular attributes that make a domain name While discussing the particular attributes that make a domain name
special, [RFC6761] notes that "the act of defining such a special special, [RFC6761] notes that "the act of defining such a special
name creates a higher-level protocol rule, above ICANN's management name creates a higher-level protocol rule, above ICANN's management
of allocatable names on the public Internet." of allocatable names on the public Internet."
[RFC2860] draws a line between what is policy and what is technical. [RFC2860] draws a line between what is policy and what is technical.
A variety of opinions have been expressed regarding whether [RFC6761] A variety of opinions have been expressed regarding whether [RFC6761]
blurs this line. In particular, see http://www.circleid.com/ blurs this line. In particular, [HUSTON] has one viewpoint on the
posts/20151222_whats_in_a_name/ for a certain viewpoint on the topic. topic. As noted earlier, it is out of scope for this document to
As noted earlier, it is out of scope for this document to analyse analyse this issue beyond noting that such a variety of views exist.
this issue beyond noting that such a variety of views exist.
Taking a different perspective, it has been argued that [RFC6761] Taking a different perspective, it has been argued that [RFC6761]
specifically extends the DNS protocol to include special treatment specifically extends the DNS protocol to include special treatment
for names in the registry, and that there's nothing in 2860 at all for names in the registry, and that there's nothing in [RFC2860] at
that limits the IETF's authority to change the protocol. all that limits the IETF's authority to change the protocol.
However, it should be noted that, if the IETF were to formalize the However, it should be noted that, if the IETF were to formalize the
concept of protocol/name switch in the Internet architecture, concept of protocol/name switch in the Internet architecture,
coordination would be require between ICANN and IETF on such names. coordination would be require between ICANN and IETF on such names.
Using the analogy described above of a catalog/registry of such Using the analogy described above of a catalog/registry of such
switches, care must be taken to make sure we do not end up with 2 switches, care must be taken to make sure we do not end up with two
process streams allowed to create entries without any process streams allowed to create entries without complete
synchronization. synchronization.
6.2. IETF Internal considerations 6.2. IETF Internal Considerations
6.2.1. Process 6.2.1. Process
[RFC6761] specifies the way in which "an IETF 'Standards Action' or [RFC6761] specifies the way in which "an IETF 'Standards Action' or
'IESG Approval' document" should present answers to the questions 'IESG Approval' document" should present answers to the questions
described above (see Section 2), but does not describe the process by described above (see Section 2), but does not describe the process by
which the answers to those questions should be evaluated. which the answers to those questions should be evaluated.
For example, it is not clear who is responsible for carrying out an For example, it is not clear who is responsible for carrying out an
evaluation. A document which requests additions to the Registry evaluation. A document which requests additions to the Registry
might be performed by the IESG, by the IAB, by the DNSOP working might be performed by the IESG, by the IAB, by the DNSOP WG, by an
group, by an ad-hoc working group, by expert review or any ad-hoc working group, by expert review or any combination of those
combination of those approaches. [RFC6761] provides no direction. approaches. [RFC6761] provides no direction.
As an illustration of the inconsistency that has been observed As an illustration of the inconsistency that has been observed
already, [RFC6762] was published as an AD-sponsored individual already, [RFC6762] was published as an AD-sponsored individual
submission in the INT area, and the IESG evaluation record does not submission in the INT area, and the IESG evaluation record does not
reveal any discussion of the reservation of the .local top-level reveal any discussion of the reservation of the .local top-level
domain in the DNS. [I-D.ietf-dnsop-onion-tld], however, was domain in the DNS. [RFC7686], however, was published as a working
published as a working group document through DNSOP, and an extensive group document through the DNSOP WG, and an extensive discussion by
discussion by both the participants of DNSOP and the IESG on the both the participants of the DNSOP WG and the IESG on the merits of
merits of the request took place. The evaluation process, in the the request took place. The evaluation process, in the absence of
absence of clear direction, is demonstrably inconsistent. clear direction, is demonstrably inconsistent.
We should point to RFC 5226 and explicitly quote the definition of We should point to [RFC5226] and explicitly quote the definition of
"Standards Action" or "IESG Approval": "Standards Action" or "IESG Approval":
IESG Approval is not intended to be used often or as a "common IESG Approval is not intended to be used often or as a "common
case"; indeed, it has seldom been used in practice during the case"; indeed, it has seldom been used in practice during the
period RFC 2434 was in effect. Rather, it is intended to be period RFC 2434 was in effect. Rather, it is intended to be
available in conjunction with other policies as a fall-back available in conjunction with other policies as a fall-back
mechanism in the case where one of the other allowable approval mechanism in the case where one of the other allowable approval
mechanisms cannot be employed in a timely fashion or for some mechanisms cannot be employed in a timely fashion or for some
other compelling reason. IESG Approval is not intended to other compelling reason. IESG Approval is not intended to
circumvent the public review processes implied by other policies circumvent the public review processes implied by other policies
that could have been employed for a particular assignment. IESG that could have been employed for a particular assignment. IESG
Approval would be appropriate, however, in cases where expediency Approval would be appropriate, however, in cases where expediency
is desired and there is strong consensus for making the assignment is desired and there is strong consensus for making the assignment
(e.g., WG consensus). (e.g., WG consensus).
So, while it is very interesting to note that [RFC6761] was an AD So, while it is very interesting to note that [RFC6761] was an AD
sponsored individual submission in spite of two active DNS related sponsored individual submission in spite of two active DNS related
WGs, 6762 is probably clean: it defines the protocol and is itself on WGs, [RFC6762] is probably clean: it defines the protocol and is
standards track. itself on standards track.
RFC 7686 however, while on standards track, does not define the TOR [RFC7686] however, while on standards track, does not define the TOR
protocol, so it was used to fulfill the 'standards action' protocol, so it was used to fulfill the 'standards action'
requirement by the letter. It contains normative references to non- requirement by the letter. It contains normative references to non-
IETF protocols, which is noteworthy. IETF protocols, which is noteworthy.
A comparison of the two '7 question forms' reveals that at least the A comparison of the two "seven question forms" from [RFC6761] reveals
responses to questions 2, 3, and 4, differ significantly while there that at least the responses to questions 2, 3, and 4, differ
is no defined way to communicate the difference to the affected significantly while there is no defined way to communicate the
software entities. difference to the affected software entities.
An alternate view has been expressed with regard to the protocol An alternate view has been expressed with regard to the protocol
evaluation. It states that the authority belongs to the IESG to seek evaluation. It states that the authority belongs to the IESG to seek
whatever support it likes, within the established process, in making whatever support it likes, within the established process, in making
standards decisions, including delegating evaluation of a specific standards decisions, including delegating evaluation of a specific
registry change proposal to a WG or a directorate. The IESG might registry change proposal to a WG or a directorate. The IESG might
have varied what guidance it sought, but that does not constitute have varied what guidance it sought, but that does not constitute
"inconsistency" under the process. That being said, more complete "inconsistency" under the process. That being said, more complete
evaluation guidance would be helpful to the IESG and the community. evaluation guidance would be helpful to the IESG and the community.
6.2.2. Technical criteria 6.2.2. Technical Criteria
Regardless of the actual name being proposed as protocol and/or Regardless of the actual name being proposed as protocol and/or
namespace switch, it is also not clear what technical criteria the namespace switch, it is also not clear what technical criteria the
evaluation body should use to examine the merit of an application for evaluation body should use to examine the merit of an application for
such a reserved name/protocol switch. For example, is large scale such a reserved name/protocol switch. For example, is large scale
prior deployment an acceptable criteria? A number of voices have prior deployment an acceptable criteria? A number of people have
clearly answered "no" to that question as it would only encourage clearly answered "no" to that question as it would only encourage
"squatting" on names. "squatting" on names.
However, in the case of .local and .onion, those particular domain However, in the case of .local and .onion, those particular domain
names were already in use by a substantial population of end-users at names were already in use by a substantial population of end-users at
the time they were requested to be added to the Registry. Rightly or the time they were requested to be added to the Registry. Rightly or
not, the practical cost of a transition away from the requested not, the practical cost of a transition away from the requested
strings was argued as a justification for their inclusion in the strings was argued as a justification for their inclusion in the
registry. registry.
6.2.3. Name evaluation 6.2.3. Name evaluation
With regard to the actual choice of name, [RFC6761] is silent. The With regard to the actual choice of name, [RFC6761] is silent. The
answers to the seven questions are expected to tell how a name, answers to the seven questions are expected to tell how a name,
presumably already chosen outside of the process, might be handled if presumably already chosen outside of the process, might be handled if
it is determined to be a "special use" name. However, it is silent it is determined to be a "special use" name. However, it is silent
on how to choose a name or how to evaluate a specific proposed name. on how to choose a name or how to evaluate a specific proposed name.
6.2.4. The ICANN process to evaluate names Going back to the IETF process used for the evaluation of .local and
.onion, one might ask the following questions:
For example, what consideration have there been in the
intellectual property rights in the reservation of a name in this
Special Use Name registry, and what procedures should be followed
in the case of a dispute over the rights to use a name in this
manner? Also, to what extent could such a reservation of a name
in this Special Use Names registry be used to block competing
interests and/or competing technologies? What are the competition
and consumer issues that need to be considered if the reservation
of a name in this registry causes some form of exclusive access
and reduced competitive access, or where there is no ability for
consumers to exercise choice in a situation where providers
compete in the offering of services?
A related consideration is that the current process of admission
to the Special Use Name registry appears to admit no formal
assessment of environmental impact. Is the name that is proposed
to be entered into this registry already being used in local
contexts, with or without an association with DNS name resolution,
such that its use as a reserved name through an entry in this
registry, and its continued use in local contexts could cause harm
to users? To what extent can this impact be assessed, and what
level of impact is considered acceptable?
While the "seven questions" relate to altered behaviors by
specific audiences and users of names there is no explicit
consideration of the security in this process. Is the
registration of such a name a "safe" action for the IETF to take?
To what extent could the use of this reserved name be used in a
hostile or malicious manner? What measures have been taken to
mitigate or otherwise address such potential vulnerabilities?
ICANN has created an entire set of groups, organizations, committees,
processes and procedures to deal with the evaluation of applied for
new TLDs, complete with a cadre of lawyers and policy people. Unless
the IETF were willing to do the same, it would have a hard time
performing evaluation of the strings themselves, distinct from the
evaluation of the technology behind the name resolution system.
An alternate view has been expressed that such a process is not
necessary because the IESG is the body that makes the decision on a
specific name reserved by [RFC6761], and the IETF has a workable
appeal process to deal with any potential issues. However, looking
at the level of contention created in the ICANN process around the
choice of certain names, serious doubts have been expressed to the
scalability and ultimate viability of such an appeal process.
6.3. The ICANN process to evaluate names
Section 4.3 of [RFC2860] says: Section 4.3 of [RFC2860] says:
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. blocks.
This remains as true today as when it was written (2000). Domain This remains as true today as when it was written (2000). Domain
names have a number of considerations that have complex policy issues names have a number of considerations that have complex policy issues
that ICANN deals with and which the IETF may not be well equipped to that ICANN deals with and which the IETF may not be well equipped to
handle. handle.
The ICANN process applicant have to go through to get a name is The ICANN process applicant have to go through to get a name is
described in the applicant guide book described in the applicant guide book [GUIDEBOOK], which is a 338
https://newgtlds.icann.org/en/applicants/agb/guidebook-full- page document. It should however be noted that the current round of
04jun12-en.pdf which is a 338 page document. It should however be gTLD application is closed and rules may differ in the next round if
noted that the current round of gTLD application is closed and rules and when it happens.
may differ in the next round if and when it happens.
Considerations include, but are not limited to: Considerations include, but are not limited to:
Geographical During the most recent round of new gTLD applications, Geographical During the most recent round of new gTLD applications,
there were a number of applications for so call "geographic" there were a number of applications for so call "geographic"
terms. These included applications for .amazon and .patagonia. terms. These included applications for .amazon and .patagonia.
The .amazon application in particular was controversial - the The .amazon application in particular was controversial - the
governments of Brazil and Peru requested that ICANN's Governmental governments of Brazil and Peru requested that ICANN's Governmental
Advisory Committee (GAC) to issue a warning that granting .amazon Advisory Committee (GAC) to issue a warning that granting .amazon
to Amazon would "prevent the use of this domain for purposes of to Amazon would "prevent the use of this domain for purposes of
public interest related to the protection, promotion, and public interest related to the protection, promotion, and
awareness raising on issues related to the Amazon biome." The awareness raising on issues related to the Amazon biome." The
IETF is not well suited to evaluating this sort of issue. IETF is not well suited to evaluating this sort of issue.
Brands / Trademark law If Wile E. Coyote approached the IETF Brands / Trademark law If Wile E. Coyote approached the IETF
requesting that the IETF reserve .acme, a trademark held by a requesting that the IETF reserve .acme, a trademark held by a
large corporation making anvils and giant slingslots, the IETF large corporation making anvils and giant slingshots, the IETF
could become embroiled in trademark lawsuit - and even if the IETF could become embroiled in trademark lawsuit - and even if the IETF
were not, we have enough armchair lawyers that the discussions were not, we have enough armchair lawyers that the discussions
would be extremely annoying :-). Closely related to this issue is would be extremely annoying :-). Closely related to this issue is
"protected designation of origin (PDO)" - for example, Champagne. "protected designation of origin (PDO)" - for example, Champagne.
String similarity ICANN has an entire process for evaluating the String similarity ICANN has an entire process for evaluating the
string similarity / confusability between applied for (and string similarity / confusability between applied for (and
current) strings - for example, under what conditions would the current) strings - for example, under what conditions would the
IETF be able to make a determination if someone attempted to use IETF be able to make a determination if someone attempted to use
RFC6761 to reserve .c0m? [RFC6761] to reserve .c0m?
International Organization Names Certain names and organizations get International Organization Names Certain names and organizations get
additional protection under trademark law - well known examples of additional protection under trademark law - well known examples of
this are the RedCross/RedCrescent and the International Olympic this are the RedCross/RedCrescent and the International Olympic
Committee (IOC). Whether or not this should be the case is well Committee (IOC). Whether or not this should be the case is well
outside anything that the IETF should have an opinion on but, outside anything that the IETF should have an opinion on but,
undoubtedly, there are many within the community who will have an undoubtedly, there are many within the community who will have an
opinion (and will want to argue it ad nauseam :-)) opinion (and will want to argue it at length).
Offensive Terms There are a huge range of these, from the obscure / Offensive Terms There are a huge range of these, from the obscure /
archaic (waesucks, gadsbudlikins) to the more obvious and current archaic (waesucks, gadsbudlikins) to the more obvious and current.
([xml2rfc-error], [xml2rfc-error] and [xml2rfc-error]. Certain Certain terms are sufficiently offensive that the IETF would have
terms are sufficiently offensive that the IETF would have a hard a hard time coming to any useful consensus (other then "Eeeew!")
time coming to any useful consensus (other then "Eeeew!")
Going back to the IETF process used for the evaluation of .local and
.onion, one might ask the following questions:
For example, what consideration have there been in the
intellectual property rights in the reservation of a name in this
Special Use Name registry, and what procedures should be followed
in the case of a dispute over the rights to use a name in this
manner? Also, to what extent could such a reservation of a name
in this Special Use Names registry be used to block competing
interests and/or competing technologies? What are the competition
and consumer issues that need to be considered if the reservation
of a name in this registry causes some form of exclusive access
and reduced competitive access, or where there is no ability for
consumers to exercise choice in a situation where providers
compete in the offering of services?
A related consideration is that the current process of admission
to the Special Use Name registry appears to admit no formal
assessment of environmental impact. Is the name that is proposed
to be entered into this registry already being used in local
contexts, with or without an association with DNS name resolution,
such that its use as a reserved name through an entry in this
registry, and its continued use in local contexts could cause harm
to users? To what extent can this impact be assessed, and what
level of impact is considered acceptable?
While the "seven questions" relate to altered behaviours by
specific audiences and users of names there is no explicit
consideration of the security in this process. Is the
registration of such a name a "safe" action for the IETF to take?
To what extent could the use of this reserved name be used in a
hostile or malicious manner? What measures have been taken to
mitigate or otherwise address such potential vulnerabilities?
ICANN has created an entire set of groups, organizations, committees,
processes and procedures to deal with the evaluation of applied for
new TLDs, complete with a cadre of lawyers and policy people. Unless
the IETF were willing to do the same, it would have a hard time
performing evaluation of the strings themselves, distinct from the
evaluation of the technology behind the name resolution system.
An alternate view has been expressed, that such a process is not
necessary because the IESG is the body that makes the decision on a
specific name reserved by RFC6761, and the IETF has a workable appeal
process to deal with any potential issues. However, looking at the
level of contention created in the ICANN process around the choice of
certain names, serious doubts have been expressed to the scalability
and ultimate viability of such an appeal process.
7. Security Considerations 7. Security Considerations
This document aims to provide a problem statement that will inform This document aims to provide a problem statement that will inform
future work. Whilst security and privacy are fundamental future work. While security and privacy are fundamental
considerations, this document expects that future work will include considerations, this document expects that future work will include
such analysis, and hence no attempt is made to do so here. See among such analysis, and hence no attempt is made to do so here. See among
other places SAC-057 [https://www.icann.org/en/system/files/files/ other places [SAC-057]
sac-057-en.pdf]
Reserving names has been presented as a way to prevent leakage into Reserving names has been presented as a way to prevent leakage into
the DNS. However, instructing resolvers to not forward the queries the DNS. However, instructing resolvers to not forward the queries
(and/or by instructing authoritative servers not to respond) will (and/or by instructing authoritative servers not to respond) is not a
garantee that such leakage will not happen. The security (or guarantee that such leakage will be prevented. The security (or
privacy) of an application MUST NOT rely on names not being exposed privacy) of an application MUST NOT rely on names not being exposed
to the Internet DNS resolution system. to the Internet DNS resolution system.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Acknowledgements 9. Acknowledgements
Your name here, etc. Thanks to Paul Hoffman for a large amount of editing.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IANA-SPECIAL-USE]
IANA, "Special-Use Domain Names", 2016,
<https://www.iana.org/assignments/special-use-domain-
names>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, Internet Assigned Numbers Authority", RFC 2860,
DOI 10.17487/RFC2860, June 2000, DOI 10.17487/RFC2860, June 2000,
<http://www.rfc-editor.org/info/rfc2860>. <http://www.rfc-editor.org/info/rfc2860>.
[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,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[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>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-dnsop-dns-terminology] [GUIDEBOOK]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS ICANN, "gTLD Application Guidebook", June 2012,
Terminology", draft-ietf-dnsop-dns-terminology-05 (work in <https://newgtlds.icann.org/en/applicants/agb/guidebook-
progress), September 2015. full-04jun12-en.pdf>.
[I-D.ietf-dnsop-onion-tld] [HUSTON] Huston, G., "What's in a Name?", December 2015,
Appelbaum, J. and A. Muffett, "The .onion Special-Use <http://www.circleid.com/posts/20151222_whats_in_a_name/>.
Domain Name", draft-ietf-dnsop-onion-tld-01 (work in
progress), September 2015.
[I-D.lewis-domain-names] [I-D.lewis-domain-names]
Lewis, E., "Domain Names", draft-lewis-domain-names-02 Lewis, E., "Domain Names", draft-lewis-domain-names-02
(work in progress), January 2016. (work in progress), January 2016.
[NEW-GTLD]
ICANN, "New Generic Top-Level Domains", 2016,
<https://newgtlds.icann.org/>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <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>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
DOI 10.17487/RFC6762, February 2013, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
<http://www.rfc-editor.org/info/rfc6762>. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011,
<http://www.rfc-editor.org/info/rfc6303>.
[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>.
[SAC-057] ICANN Security and Stability Advisory Committee, "SSAC
Advisory on Internal Name Certificates", March 2013,
<https://www.icann.org/en/system/files/files/sac-
057-en.pdf>.
Appendix A. Editorial Notes Appendix A. Editorial Notes
This section (and sub-sections) to be removed prior to publication. This section (and sub-sections) to be removed prior to publication.
A.1. Venue A.1. Venue
An appropriate forum for discussion of this draft is for now the An appropriate forum for discussion of this draft is for now the
dnsop working group. DNSOP WG.
A.2. Pithy Quotes from History A.2. Pithy Quotes from History
The question has arisen as to how the toplevel naming authority The question has arisen as to how the toplevel naming authority
decides who gets a toplevel name and who must get by with a non- decides who gets a toplevel name and who must get by with a non-
toplevel name. The suggestion was made by MOCKAPETRIS@USC-ISIF toplevel name. The suggestion was made by MOCKAPETRIS@USC-ISIF
that perhaps the existing toplevel nameholders might vote on that perhaps the existing toplevel nameholders might vote on
whether the applicant for a new toplevel name should be granted, whether the applicant for a new toplevel name should be granted,
with a majority needed for approval. It seems to me this might with a majority needed for approval. It seems to me this might
produce a clique whereby whoever initially gains power will hold produce a clique whereby whoever initially gains power will hold
skipping to change at page 17, line 28 skipping to change at page 17, line 51
A.3. Change History A.3. Change History
A.3.1. draft-adpkja-special-names-problem-00 A.3.1. draft-adpkja-special-names-problem-00
Initial draft circulated for comment. Initial draft circulated for comment.
Appendix B. Change history Appendix B. Change history
[ RFC Editor: Please remove this section before publication] [ RFC Editor: Please remove this section before publication]
-01 to -02:
o A very large number of readability / grammar / reference fixes
from Paul Hoffman.
-00 to -01: -00 to -01:
o Significant readability changes. o Significant readability changes.
o [WK: Stopped at end of Sec 3]
-00: -00:
o Initial draft circulated for comment. o Initial draft circulated for comment.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Dyn, Inc. Dyn, Inc.
103-186 Albert Street 103-186 Albert Street
London, ON N6A 1M1 London, ON N6A 1M1
skipping to change at page 18, line 4 skipping to change at page 18, line 26
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Dyn, Inc. Dyn, Inc.
103-186 Albert Street 103-186 Albert Street
London, ON N6A 1M1 London, ON N6A 1M1
Canada Canada
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: jabley@dyn.com Email: jabley@dyn.com
Peter Koch Peter Koch
DENIC DENIC eG
Kaiserstrasse 75-77
Frankfurt 60329
Germany
Email: pk@denic.de Email: pk@denic.de
Alain Durand Alain Durand
ICANN ICANN
Email: alain.durand@icann.org Email: alain.durand@icann.org
Warren Warren Kumari
Google Google
Email: warren@kumari.net Email: warren@kumari.net
 End of changes. 85 change blocks. 
233 lines changed or deleted 269 lines changed or added

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