Network Working Group G. Huston
Internet-Draft APNIC
Intended status: Informational P. Koch
Expires: March 14, 2017 DENIC eG
A. Durand
ICANN
W. Kumari
Google
September 10, 2016
Problem Statement for the Reservation of Special-Use Domain Names using
RFC6761
draft-adpkja-dnsop-special-names-problem-06
Abstract
The dominant protocol for name resolution on the Internet is the
Domain Name System (DNS). However, other protocols exist that are
fundamentally different from the DNS, and may or may not share the
same namespace.
When an end-user triggers resolution of a name on a system that
supports multiple, different protocols or resolution mechanisms, it
is desirable that the protocol used is unambiguous, and that requests
intended for one protocol are not inadvertently answered using
another protocol.
RFC 6761 introduced a framework by which a particular domain name
could be acknowledged as being special. Various challenges have
become apparent with this application of the guidance provided in RFC
6761. This document focuses solely on documenting the specific
challenges created by RFC 6761 in the form of a problem statement in
order to facilitate further discussions of potential solutions. In
particular, it refrains from proposing or promoting any solution.
Also, the current document does not focus on other general issues
related to the use of special use domain names.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Huston, et al. Expires March 14, 2017 [Page 1]
Internet-Draft Special-Use Domain Names September 2016
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction: DNS, Name Space or Name Spaces, Name Resolution
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IETF RFC6761 Special Names . . . . . . . . . . . . . . . . . 4
3. Issues with RFC 6761 process . . . . . . . . . . . . . . . . 4
4. Issues with the RFC6761 registry . . . . . . . . . . . . . . 5
5. Issues Around the IETF Evaluation of Candidate Strings . . . 6
6. Other Issues Related to RFC6761 . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 8
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 8
A.2. Change History . . . . . . . . . . . . . . . . . . . . . 8
A.2.1. draft-adpkja-special-names-problem-00 . . . . . . . . 8
Appendix B. Change history . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Huston, et al. Expires March 14, 2017 [Page 2]
Internet-Draft Special-Use Domain Names September 2016
1. Introduction: DNS, Name Space or Name Spaces, Name Resolution
Protocols
For a very long time, "DNS" and "the name space" have been perceived
as the same thing. However, this has not always been the case; in
the past, other name resolution protocols (such as NIS, NIS+, host
files, UUCP addresses, and others) were popular. Most of those have
been obsoleted by the DNS in the late 1990s. More information on the
history of names and namespaces can be found in
[I-D.lewis-domain-names].
More recently, new name resolution protocols have been proposed, each
addressing a particular need or a particular community. For example,
the DONA handle system [DONA] has been used by parts of the
publication industry. The Apple "Bonjour" set of protocols, inspired
by what was available on Appletalk networks, was developed to perform
automatic name resolution on a local IP network. The TOR project is
using the onion system to obfuscate communications, the GNU Name
System (GNS) system is using block chains to build a decentralized
name system to offer "privacy and censorship resistance". Many more
name resolution protocols have been proposed.
These alternate name resolution protocols do not exist in a vacuum.
Application developers have expressed a strong desire to build their
software to function in any of those universes with minimal changes.
In order to do so, the software has to deterministically recognize
what kind of name it is dealing with and associate it with the
corresponding name resolution protocol. An algorithmic solution
frequently chosen by application developers consists simply in using
a special tag padded at the end of a name to indicate an alternate
name resolution method. For example, if a name ends in .local, the
software uses the Apple Bonjour protocol based on multicast DNS; if
the name ends in .onion, it uses the TOR protocol; if the name ends
in .gnu, it uses the GNS protocol, and so on. One noteworthy
exception to this approach is the DONA system that has its own
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
developed (and massively distributed) that have encoded their
favorite "tag" as a DNS TLD in a free-for-all, beginning their
existence by squatting on that DNS space; .local, .gnu, .onion
started out like that.
Huston, et al. Expires March 14, 2017 [Page 3]
Internet-Draft Special-Use Domain Names September 2016
2. IETF RFC6761 Special Names
The IETF used a provision from the IETF/ICANN MoU [RFC2860] section
4.3 that says that "(a) assignments of domain names for technical
uses" is to be considered the purview of IETF (outside of the scope
of ICANN) in order to create a way to reserve such names in a list of
"special names". That process is documented in [RFC6761] (which,
however, does not directly refer the IETF/ICANN MoU). The [RFC6761]
process was first applied for .local, and the more recently for
.onion.
When the [RFC6761] process was put in place, many thought it would
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.
[RFC6761] has a number of issues. This document groups those issues
in several categories.
3. Issues with RFC 6761 process
a. [RFC6761] does not mention if the protocol using the reserved
name should be published as an RFC document.
Most applications have, so far, come from outside
organizations, and the described protocols that have not been
developed by the IETF.
b. [RFC6761] does not provide clear enough directions as to which
group of people is responsible for carrying out the evaluation
for inclusion in the registry.
There are ambiguities and no formal criteria on how the IETF
can (or even whether the IETF should) evaluate the merits of
applicants to [RFC6761] reservations.
c. The "seven questions" of [RFC6761] are inadequate for evaluating
proposals.
Section 5 of [RFC6761] describes seven questions to be
answered by an applicant for [RFC6761] status. However,
running this process for the .onion application showed that
those seven questions are inadequate for making the
determination of whether a particular string qualifies for
[RFC6761] treatment.
d. Some organizations may want to experiment with a reserved name.
Huston, et al. Expires March 14, 2017 [Page 4]
Internet-Draft Special-Use Domain Names September 2016
They may or may not be ready (or willing) to go through a
cumbersome process and find [RFC6761] too difficult to deal
with. They would like a much simpler registration process,
with limited or no burden to apply.
e. The [RFC6761] process could be abused.
In particular, the process can be abused to reserve a specific
string within an existing suffix (or set of suffixes using
wildcards) not under the control of IETF.
f. [RFC6761] does not have provision for subsequent management of
the registry, such as updates, deletions of entries, etc...
4. Issues with the RFC6761 registry
a. The [RFC6761] registry lacks sufficient documentation supporting
a registration.
The registry may point to the RFC creating the reservation,
but not to the supporting materials.
b. The [RFC6761] registry lacks clear directions for applications to
select which name resolution method to use upon seeing the
special name.
In particular, it lists the reserved names but does not
include direct guidance, neither in free text form nor in
machine-readable instructions, for any of the seven audiences.
Instead, the registry relies on a reference for each entry to
the document that requested its insertion. Such documents
could be difficult to read for many readers; for example,
[RFC6762] is a 70-page protocol specification which is not an
effective way to set expectations of non-technical end-users.
c. Reserving a string in [RFC6761] does not guarantee queries will
not leak in the DNS.
The applicants for [RFC6761] status cannot be guaranteed that
leakage will not occur and will need to take this into account
in their protocol design.
d. The intended usage or protocol for which the [RFC6761]
reservation is made may or may not be successful.
In the case of failure of adoption, the reserved string would
be wasted.
Huston, et al. Expires March 14, 2017 [Page 5]
Internet-Draft Special-Use Domain Names September 2016
5. Issues Around the IETF Evaluation of Candidate Strings
a. The IETF does not have a formal process to evaluate candidate
strings for issues such as trademark infringement and name
collisions.
This leads to concerns about liability risks incurred by
adding a particular string to the [RFC6761] registry.
b. Submitting the application to IETF last call does not guarantee
such issues will be always caught.
[RFC7788] describing the "home networking control protocol"
was recently published. That document includes text
instructing devices to use names terminating by default with
the .home suffix. [RFC7788] did not reference [RFC6761]
anywhere and had no IANA sections about this reservation. It
was published without anyone noticing this during the entire
review process. The issue was caught after the publication,
and an errata was published.
6. Other Issues Related to RFC6761
[RFC6761] does not include a mechanism to collaborate with ICANN.
The current round of ICANN gTLD (described at [NEW-GTLD]) is, as
the time of this writing, closed to new applications. It is,
however, not yet completed. Some applications are still under
consideration. There is a risk that, without proper collaboration
between the IETF and ICANN, a new entry in the [RFC6761] registry
could conflict with one of those applications still under review.
It should also be noted that discussions have started about
forming the next round of ICANN gTLDs, thus this issue will not go
away at the conclusion of the current gTLD round.
7. Security Considerations
This document aims to provide a problem statement that will inform
future work. While security and privacy are fundamental
considerations, this document expects that future work will include
such analysis, and hence no attempt is made to do so here. See
[SAC-057] for further considerations.
Reserving names has been presented as a way to prevent leakage into
the DNS. However, instructing resolvers to not forward the queries
(and/or by instructing authoritative servers not to respond) is not a
guarantee that such leakage will be prevented. The security (or
Huston, et al. Expires March 14, 2017 [Page 6]
Internet-Draft Special-Use Domain Names September 2016
privacy) of an application MUST NOT rely on names not being exposed
to the Internet DNS resolution system.
8. IANA Considerations
This document has no IANA actions.
9. Acknowledgements
Thanks to Paul Hoffman for a large amount of editing.
10. References
10.1. Normative References
[IANA-SPECIAL-USE]
IANA, "Special-Use Domain Names", 2016,
<https://www.iana.org/assignments/special-use-domain-
names>.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860,
DOI 10.17487/RFC2860, June 2000,
<http://www.rfc-editor.org/info/rfc2860>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<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>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <http://www.rfc-editor.org/info/rfc7788>.
10.2. Informative References
[DONA] DONA, "DONA Foundation", June 2016,
<https://www.dona.net>.
[FROGANS] Frogans Technology, "Frogans Technology", June 2016,
<https://www.frogans.org>.
Huston, et al. Expires March 14, 2017 [Page 7]
Internet-Draft Special-Use Domain Names September 2016
[GUIDEBOOK]
ICANN, "gTLD Application Guidebook", June 2012,
<https://newgtlds.icann.org/en/applicants/agb/guidebook-
full-04jun12-en.pdf>.
[HUSTON] Huston, G., "What's in a Name?", December 2015,
<http://www.circleid.com/posts/20151222_whats_in_a_name/>.
[I-D.lewis-domain-names]
Lewis, E., "Domain Names", draft-lewis-domain-names-03
(work in progress), June 2016.
[NEW-GTLD]
ICANN, "New Generic Top-Level Domains", 2016,
<https://newgtlds.icann.org/>.
[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
This section (and sub-sections) to be removed prior to publication.
A.1. Venue
An appropriate forum for discussion of this draft is, for now, the
DNSOP WG.
A.2. Change History
A.2.1. draft-adpkja-special-names-problem-00
Initial draft circulated for comment.
Appendix B. Change history
[ RFC Editor: Please remove this section before publication]
-06 to -05:
o Clarify the sole focus of this draft is to document problems
created by RFC6761, and not the larger issue of NON-DNS TLDs.
o Split issue lists and rewrite some for clarity.
-05 to -04:
Huston, et al. Expires March 14, 2017 [Page 8]
Internet-Draft Special-Use Domain Names September 2016
o Added two issues to the issue list: market failure and
experimental use.
-04 to -03:
o Minor edits to correct grammar, clarify that the current ICANN
gTLD round is closed.
-03 to -02:
o Significant readability changes to focus the discussion.
-01 to -02:
o A very large number of readability / grammar / reference fixes
from Paul Hoffman.
-00 to -01:
o Significant readability changes.
-00:
o Initial draft circulated for comment.
Authors' Addresses
Geoff Huston
APNIC
Email: gih@apnic.net
Peter Koch
DENIC eG
Kaiserstrasse 75-77
Frankfurt 60329
Germany
Email: pk@denic.de
Alain Durand
ICANN
Email: alain.durand@icann.org
Huston, et al. Expires March 14, 2017 [Page 9]
Internet-Draft Special-Use Domain Names September 2016
Warren Kumari
Google
Email: warren@kumari.net
Huston, et al. Expires March 14, 2017 [Page 10]