< draft-adpkja-dnsop-special-names-problem-03.txt   draft-adpkja-dnsop-special-names-problem-04.txt >
Network Working Group G. Huston Network Working Group G. Huston
Internet-Draft APNIC Internet-Draft APNIC
Intended status: Informational P. Koch Intended status: Informational P. Koch
Expires: November 25, 2016 DENIC eG Expires: December 30, 2016 DENIC eG
A. Durand A. Durand
ICANN ICANN
W. Kumari W. Kumari
Google Google
May 24, 2016 June 28, 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-03 draft-adpkja-dnsop-special-names-problem-04
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 that When an end-user triggers resolution of a name on a system that
supports multiple, different protocols (or resolution mechanisms), it supports multiple, different protocols or resolution mechanisms, it
is desirable that the protocol used is unambiguous, and that requests is desirable that the protocol used is unambiguous, and that requests
intended for one protocol are not inadvertently answered using intended for one protocol are not inadvertently answered using
another. another protocol.
RFC 6761 introduced a framework by which a particular domain name RFC 6761 introduced a framework by which a particular domain name
could be acknowledged as being special. Various challenges have could be acknowledged as being special. Various challenges have
become apparent with this application of the guidance provided in RFC become apparent with this application of the guidance provided in RFC
6761. This document aims to document those challenges in the form of 6761. This document aims to document those challenges in the form of
a problem statement in order to facilitate further discussion of a problem statement in order to facilitate further discussion of
potential solutions. potential solutions.
Status of This Memo Status of This Memo
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 November 25, 2016. This Internet-Draft will expire on December 30, 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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: DNS, Name space or Name Spaces, Name Resolution 1. Introduction: DNS, Name space or Name Spaces, Name Resolution
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IETF RFC6761 Special Names . . . . . . . . . . . . . . . . . 3 2. IETF RFC6761 Special Names . . . . . . . . . . . . . . . . . 3
3. Issues with 6761 . . . . . . . . . . . . . . . . . . . . . . 4 3. Issues with RFC 6761 Itself . . . . . . . . . . . . . . . . . 4
4. Candidate string evaluation and relationship with ICANN . . . 5 4. Issues with Evaluating Candidate String and Relationship to
the ICANN Process . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 7 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 7
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 7 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 8
A.2. Change History . . . . . . . . . . . . . . . . . . . . . 7 A.2. Change History . . . . . . . . . . . . . . . . . . . . . 8
A.2.1. draft-adpkja-special-names-problem-00 . . . . . . . . 7 A.2.1. draft-adpkja-special-names-problem-00 . . . . . . . . 8
Appendix B. Change history . . . . . . . . . . . . . . . . . . . 7 Appendix B. Change history . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction: DNS, Name space or Name Spaces, Name Resolution 1. Introduction: DNS, Name space or Name Spaces, Name Resolution
Protocols Protocols
For a very long time, DNS and the name space have been perceived as For a very long time, "DNS" and "the name space" have been perceived
one and the same. However, this has not always been the case; in the as the same thing. However, this has not always been the case; in
past, other name resolution protocols were popular. One can remember the past, other name resolution protocols (such as NIS, NIS+, host
NIS, NIS+, host files, UUCP addresses... Most of those have been files, UUCP addresses, and others) were popular. Most of those have
obsoleted by the DNS in the late 1990s. More information on the been obsoleted by the DNS in the late 1990s. More information on the
history of names and namespaces can be found in history of names and namespaces can be found in
[I-D.lewis-domain-names]. [I-D.lewis-domain-names].
More recently, new name resolution protocols have been proposed, each More recently, new name resolution protocols have been proposed, each
addressing a particular need or a particular community. For example, addressing a particular need or a particular community. For example,
the DONA handle system has been used by the publication industry. the DONA handle system [DONA] has been used by parts of the
The Apple "Bonjour" set of protocols, inspired by what was available publication industry. The Apple "Bonjour" set of protocols, inspired
on Appletalk networks, has been developed to perform automatic name by what was available on Appletalk networks, was developed to perform
resolution on a local IP network. The TOR project is using the onion automatic name resolution on a local IP network. The TOR project is
system to obfuscate communications, the GNU Name System (GNS) system using the onion system to obfuscate communications, the GNU Name
is using block chains to build a decentralized name system to offer System (GNS) system is using block chains to build a decentralized
"privacy and censorship resistance". Many more have been proposed. name system to offer "privacy and censorship resistance". Many more
name resolution protocols have been proposed.
Those alternate name resolution protocols do not exist in a vacuum. These alternate name resolution protocols do not exist in a vacuum.
Application developers have expressed a strong desire to build their Application developers have expressed a strong desire to build their
software so it will function in any of those universes with minimal software to function in any of those universes with minimal changes.
changes. Doing so means that the software has to recognize In order to do so, the software has to deterministically recognize
deterministically what kind of name it is dealing with and associate what kind of name it is dealing with and associate it with the
it with the corresponding name resolution protocol. Because of this corresponding name resolution protocol. An algorithmic solution
desired lack of explicit signaling, an algorithmic solution
frequently chosen by application developers consists simply to use a frequently chosen by application developers consists simply to use a
special tag padded at the end of a name to indicate an alternate name special tag padded at the end of a name to indicate an alternate name
resolution method. Examples: if a name ends in .local, the software resolution method. For example, if a name ends in .local, the
uses the Apple Bonjour protocol based on multicast DNS; if the name software uses the Apple Bonjour protocol based on multicast DNS; if
ends in .onion, it uses the TOR protocol; if the name ends in .gnu, the name ends in .onion, it uses the TOR protocol; if the name ends
it uses the GNS protocol, etc... One noteworthy exception to this in .gnu, it uses the GNS protocol, and so on. One noteworthy
approach is the DONA system that exists independently and has exception to this approach is the DONA system that has its own
developed its own interoperability solution with the DNS. interoperability mechanism with the DNS. Another noteworthy
exception is the Frogans technology [FROGANS] which name space uses
the character '*' to separate network names from site names and allow
any character, including dots on either side of the '*'.
A result of the above is that a number of applications have been A result of the above is that a number of applications have been
developed (and massively distributed) that have encoded their developed (and massively distributed) that have encoded their
favorite "tag" as a DNS TLD in a free-for-all, beginning their favorite "tag" as a DNS TLD in a free-for-all, beginning their
existence squatting on that DNS space... .local, .gnu, .onion existence by squatting on that DNS space; .local, .gnu, .onion
started out like that. started out like that.
2. IETF RFC6761 Special Names 2. IETF RFC6761 Special Names
The IETF used a provision from the IETF/ICANN MoU [RFC2860] section The IETF used a provision from the IETF/ICANN MoU [RFC2860] section
4.3 that says that "(a) assignments of domain names for technical 4.3 that says that "(a) assignments of domain names for technical
uses" is to be considered the purview of IETF (as in, outside of the uses" is to be considered the purview of IETF (outside of the scope
scope of ICANN) in order to create a way to reserve such names in a of ICANN) in order to create a way to reserve such names in a list of
list of "special names". That process is documented in [RFC6761] "special names". That process is documented in [RFC6761] (which,
(which curiously does not directly refer the IETF/ICANN MoU). It was however, does not directly refer the IETF/ICANN MoU). The [RFC6761]
first applied for .local and more recently for .onion. When that process was first applied for .local, and the more recently for
process was put in place, it was thought it would only be used a .onion.
handful of times. However, a large number of applications have since
been made to the IETF. The .onion evaluation took almost a year and
has started a massive (and often heated) discussion in the IETF.
This [RFC6761] process to reserve special name has a number of When the [RFC6761] process was put in place, it was thought it would
issues, that can be grouped in two categories: only be used a handful of times. However, a large number of
applications have since been made to the IETF. The .onion evaluation
took almost a year and has started a massive (and often heated)
discussion in the IETF.
This [RFC6761] process to reserve special name has many issues. This
document groups the issues that have been brought up in two general
categories:
o Issues with [RFC6761] itself, including issues discovered during o Issues with [RFC6761] itself, including issues discovered during
the evaluation of .onion the evaluation of .onion
o Higher level issues regarding candidate string evaluation and o Issues regarding evaluating candidate strings and the relationship
relationship with ICANN of this process with ICANN's processes
3. Issues with 6761 3. Issues with RFC 6761 Itself
1. It can be use to reserve any names, not just TLDs. For example, 1. [RFC6761] can be used to reserve any names, not just TLDs. For
it could potentially be used to forbid a registrar to register example, it could potentially be used to forbid a registrar to
specific names in any TLD. register specific names in any TLD.
2. [RFC6761] does not mention if the protocol for which it is 2. [RFC6761] does not mention if the protocol using the reserved
requested to reserve a string should be published as an RFC name should be published as an RFC document. Most applications
document. Most applications have, so far, come from outside have, so far, come from outside organizations, and the described
organizations, and the described protocols that have not been protocols that have not been developed by the IETF.
developed by the IETF.
3. [RFC6761] does not provide clear enough direction as to what 3. [RFC6761] does not provide clear enough direction as to which
party is responsible for carrying out the evaluation. group of people is responsible for carrying out the evaluation
for inclusion in the registry.
4. There are ambiguities and no formal criteria on how the IETF can 4. There are ambiguities and no formal criteria on how the IETF can
(or even whether the IETF should) evaluate the merits of (or even whether the IETF should) evaluate the merits of
applicants to [RFC6761] reservations. Section 5 of [RFC6761] applicants to [RFC6761] reservations. Section 5 of [RFC6761]
describes seven questions to be answered by an applicant for describes seven questions to be answered by an applicant for
[RFC6761] status. However, running this process for the .onion [RFC6761] status. However, running this process for the .onion
application showed that those seven questions are inadequate for application showed that those seven questions are inadequate for
making the determination for whether a particular strings making the determination for whether a particular strings
qualifies as requiring special/different treatment. qualifies for [RFC6761] treatment.
5. Placing a string in the [RFC6761] registry does not guarantee 5. Placing a string in the [RFC6761] registry does not guarantee
that DNS queries for names within a reserved domain will not be that DNS queries for names within a reserved domain will not be
sent over the Internet. As such, the applicant for [RFC6761] sent over the Internet. As such, the applicant for [RFC6761]
status cannot be guaranteed that leakage will not occur and will status cannot be guaranteed that leakage will not occur and will
need to take this into account in the protocol design. Useful need to take this into account in their protocol design. Useful
reservations of top-level domains should be accompanied by 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 audiences, and the evaluation of particular requests should
consider the practical likelihood of those expectations being met consider the practical likelihood of those expectations being met
and the implications if they are not. and the implications if they are not.
6. The [RFC6761] registry lists the reserved names but does not 6. The [RFC6761] registry lists the reserved names but does not
include direct guidance, neither in free text form nor in machine include direct guidance, neither in free text form nor in machine
readable instructions, for any of the seven audiences, relying readable instructions, for any of the seven audiences. Instead,
instead upon a reference for each entry in the Registry to the the registry relies on a reference for each entry to the document
document that requested its insertion. Such documents might well that requested its insertion. Such documents could be difficult
be opaque to many readers; [RFC6762] is a seventy-page protocol to read for many readers; for example, [RFC6762] is a 70-page
specification, for example, which is arguably not the most protocol specification which is not an effective way to set
effective way to set expectations of non-technical end-users expectations of non-technical end-users.
4. Candidate string evaluation and relationship with ICANN 4. Issues with Evaluating Candidate String and Relationship to the
ICANN Process
1. IETF does not have process to evaluate the proposed strings 1. The IETF does not have process to evaluate candidate strings for
candidate to [RFC6761] status for things like trademark, IPR, issues such as trademark, name collision, and so on. Instead,
name collision, etc.. Instead, the IETF relies on document the IETF relies on document reviews, working group and IETF-wide
reviews, working group and IETF-wide last call, and ultimately a last call, and ultimately a decision is made by the IESG. That
decision is made by the IESG. That decision can be appealed, decision can be appealed, first to the IAB and second to the ISOC
first to the IAB and second to the ISOC board of trusties. board of trusties.
2. The IETF "review" process is not foolproof. [RFC7788] describing 2. The IETF review process is not foolproof. [RFC7788] describing
the "home networking control protocol" was recently published. the "home networking control protocol" was recently published.
That document includes text instructing devices to use names That document includes text instructing devices to use names
terminating by default with the .home suffix. [RFC7788] did not terminating by default with the .home suffix. [RFC7788] did not
reference [RFC6761] anywhere and had no IANA sections about this reference [RFC6761] anywhere and had no IANA sections about this
reservation. It was published without anyone noticing this reservation. It was published without anyone noticing this
during the entire review process. The issue was caught after the during the entire review process. The issue was caught after the
publication, and an errata was published. publication, and an errata was published.
3. There exists now at least 2 streams to take strings out of the 3. There exists now at least two streams to take strings out of the
global namespace: IETF RFC6761 "special names" and ICANN "gTLD global namespace: the IETF's special-use domain names (described
program" (see [NEW-GTLD]). It is important to observed that the in [RFC6761]) and ICANN's gTLD program (described at [NEW-GTLD]).
IETF RFC6761 reservations could happen in a ad-hoc fashion at any [RFC6761] reservations happen in a ad-hoc fashion at different
time, while ICANN delegations typically happen in batches, and times, while ICANN's gTLD delegations typically happen in
the latest gTLD round is closed. Note: the ICANN gTLD batches. (The ICANN gTLD application process is described in the
application process is described in the applicant guide book applicant guide book [GUIDEBOOK]). One should note that the
[GUIDEBOOK]. current round of ICANN gTLD is closed to new applications, but
not yet completed as some applications are still under
consideration. One should note that discussions have started
about forming the next round of ICANN gTLDs.
4. The major risk is having a conflict when both the IETF and ICANN 4. There is a significant risk of conflict when both the IETF and
want to use the same or similar strings. There exist no defined ICANN want to register the same string, and also when they want
cooperation between ICANN and IETF to avoid this problem. to register similar strings. There currently is no defined
mechanism for cooperation between ICANN and IETF to avoid these
problems.
5. There might be limited concerns if IETF were to reserve a string 5. There could be conflict if an IETF reservation were to be made
outside of an ICANN gTLD round. The next ICANN gTLD applicant during a possible future ICANN gTLD round. A hypothetical case
book would simply refer to the existing list at publication time. for this would be somebody trying prevent a competitor from
However, there is a possibility of conflict if an IETF getting a gTLD by asking the IETF to reserve that string or a
reservation were to happen during an ICANN gTLD round. A similar string.
hypothetical case study could be somebody trying a denial of
service attack early in the ICANN application process by asking
the IETF to reserved a string sought after by a competitor.
5. Security Considerations 5. 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. While 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
other places [SAC-057] [SAC-057] for further considerations.
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) is not a (and/or by instructing authoritative servers not to respond) is not a
guarantee that such leakage will be prevented. 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.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 7, line 11 skipping to change at page 7, line 19
[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>.
[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>.
8.2. Informative References 8.2. Informative References
[DONA] DONA, "DONA Foundation", June 2016,
<https://www.dona.net>.
[FROGANS] Frogans Technology, "Frogans Technology", June 2016,
<https://www.frogans.org>.
[GUIDEBOOK] [GUIDEBOOK]
ICANN, "gTLD Application Guidebook", June 2012, ICANN, "gTLD Application Guidebook", June 2012,
<https://newgtlds.icann.org/en/applicants/agb/guidebook- <https://newgtlds.icann.org/en/applicants/agb/guidebook-
full-04jun12-en.pdf>. full-04jun12-en.pdf>.
[HUSTON] Huston, G., "What's in a Name?", December 2015, [HUSTON] Huston, G., "What's in a Name?", December 2015,
<http://www.circleid.com/posts/20151222_whats_in_a_name/>. <http://www.circleid.com/posts/20151222_whats_in_a_name/>.
[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
 End of changes. 32 change blocks. 
98 lines changed or deleted 115 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/