[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]
Versions: 00 01 02 03 04 05 06
Network Working Group J. Abley
Internet-Draft Dyn, Inc.
Intended status: Informational P. Koch
Expires: April 21, 2016 DENIC
A. Durand
ICANN
October 19, 2015
Problem Statement for the Reservation of Top-Level Domains in the
Special-Use Domain Names Registry
draft-adpkja-dnsop-special-names-problem-00
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, but which have syntactically-
similar namespaces.
When an end-user triggers resolution of a name on a system which
supports multiple, different protocols for name resolution, it is
desirable that the protocol to be used is unambiguous, and that
requests intended for one protocol are not inadvertently addressed
using another.
[RFC6761] introduced a framework by which, under certain
circumstances, a particular domain name could be acknowledged as
being special. This framework has been used to make top-level domain
reservations, that is, particular top-level domains that should not
be used within the DNS to accommodate parallel use of non-DNS name
resolution protocols by end-users and avoid the possibility of
namespace collisions.
Various challenges have become apparent with this application of the
guidance provided in [RFC6761]. This document aims to document those
challenges in the form of a problem statement, to facilitate further
discussion of potential solutions.
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/.
Abley, et al. Expires April 21, 2016 [Page 1]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
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 April 21, 2016.
Copyright Notice
Copyright (c) 2015 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RFC6761 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architectural considerations . . . . . . . . . . . . . . . . 5
5. Technical considerations . . . . . . . . . . . . . . . . . . 6
6. Organizational considerations . . . . . . . . . . . . . . . . 7
6.1. Non-exhaustive list of external organizational
considerations . . . . . . . . . . . . . . . . . . . . . 7
6.2. IETF Internal considerations . . . . . . . . . . . . . . 8
6.2.1. Process . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.2. Technical criteria . . . . . . . . . . . . . . . . . 8
6.2.3. Name evaluation . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 11
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2. Pithy Quotes from History . . . . . . . . . . . . . . . . 11
A.3. Change History . . . . . . . . . . . . . . . . . . . . . 12
A.3.1. draft-adpkja-special-names-problem-00 . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Abley, et al. Expires April 21, 2016 [Page 2]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
1. Terminology
Clear and unambiguous use of terminology is important for the clear
formulation of any problem statement. The DNS protocol suffers from
imprecise and overloaded terminology (e.g. see
[I-D.ietf-dnsop-dns-terminology]) without confusing matters further
with terms and concepts from other naming systems that are similar,
but different.
In the interests of clarity, the following terms used in this
document are to be interpreted as follows:
Aardvark (n): a medium-sized, burrowing, nocturnal mammal native
to Africa; the only living species of the order Tubulidentata.
See <https://en.wikipedia.org/wiki/Aardvark>. This is a
placeholder.
Registry (n): the Special-Use Domain Names Registry created by
[RFC6761] and published at <https://www.iana.org/assignments/
special-use-domain-names/special-use-domain-names.xhtml>
[This section to be completed following review and refinement of the
rest of the text.]
2. Introduction
In recent years, using the last label of a domain name (aka TLD) as
switch to indicate how to treat name resolution has been experimented
using the framework of [RFC6761]. Examples of such switches include:
.example (don't resolve), .local (use mDNS), .onion (use tor), any
TLD registered in IANA-maintained root-zone (use DNS).
Such usage, which a few commenters have referred to as "protocol
switching," is not limited to "protocol switch" in the strict sense
of indicating specific protocols on the wire. It could indicate to
switch to another name space (eg .onion), use a different protocol
(eg tor, or mdns), or indicate to use a local DNS scope by not using
the DNS root for name resolution (eg .home in homenet) or something
else altogether.
This switch practice is not explicitly documented anywhere. Indeed,
the full semantics of domain names isn't really documented anywhere
either, although [Ed Lewis domain-names draft] is a current attempt
to catalog the precedents.
[RFC6761] defines ways to reserve domain names and is now used to
augment the technical exemption made in [RFC2860] (IETF-ICANN MoU):
Abley, et al. Expires April 21, 2016 [Page 3]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
"Note that (a) assignments of domain names for technical uses
(such as domain names for inverse DNS lookup), (b) assignments of
specialized address blocks (such as multicast or anycast blocks),
and (c) experimental assignments are not considered to be policy
issues, and shall remain subject to the provisions of this
Section 4."
The discussions in the DNSOP WG and the IETF Last Call processes
about the .onion registration in the Special Use Domain Names
registry (1,200 messages) have made it apparent that clarity about if
and how to treat this "protocol switching" practice would help a lot
in deciding the merit of future similar applications. One possible
outcome of the discussion would be to decline to recognize such usage
of domain names in the architecture, another one is to formalize it
and understand better the issues that come with it.
3. RFC6761
In Section 5, [RFC6761] describes seven questions to be answered in
order to provide clear guidance about how and why a particular domain
name is special. These seven questions can be broadly categorized as
follows:
1. impact on end-users;
2. impact on applications;
3. impact on name resolution APIs and libraries;
4. impact on recursive resolvers;
5. impact on authoritative DNS servers;
6. impact on DNS server operators;
7. impact on DNS registries and registrars.
Answers to these seven questions provide guidance to the
corresponding seven audiences on how to handle a special-use domain
name once it has been reserved by inclusion in the Registry.
However, they are inadequate for making the determination whether a
particular domain name qualifies as being special in the first place.
This memo proposes to categorize considerations related to switches
in 3 categories: Architectural, Technical and Organizational. This
memo then lists a number of questions to drive the discussion. The
list of issues discussed here is non-exhaustive.
Abley, et al. Expires April 21, 2016 [Page 4]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
4. Architectural considerations
The first thing to consider in this discussion is that not all names
(or domain names) are par of the Domain Name System. See [ID-lewis-
domain-names] for an in-depth discussion on this topic.
At the time of writing, three top-level domain names reserved by
inclusion in the Registry are used by name resolution protocols other
than the DNS:
LOCALHOST is used to refer to the host on which the name
resolution takes place, without reference to the DNS;
LOCAL is used by the Multicast DNS protocol specified in [RFC6762]
which is similar in some respects to the DNS, but which uses
different well-known port number and is limited to a particular
multicast scope;
ONION is used to construct names that designate anonymous hidden
services reachable via the Tor network using onion routing.
The three 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 some cases).
The top-level label is effectively being used as a name resolution
protocol identifier. The lack of a more elegant way to specify a
name resolution protocol in (for example) a URI amounts to an
architectural oversight. However, it is not clear that this is still
a problem that can be solved; it could be argued that in the absence
of a more elegant alternative, a pragmatic choice to embed protocol
selectors as namespace tokens has effectively already been made. The
running code and effective consensus in how it should be used by
significant user bases should not be discounted. Although the
reservation of names in the DNS namespace can be made at any level,
the three examples above demonstrate use-cases for reservation at the
top-level, and hence that case must be considered.
In [RFC2826] the IAB noted that
"To remain a global network, the Internet requires the existence
of a globally unique public name space. The DNS name space is a
hierarchical name space derived from a single, globally unique
root."
"Maintaining a globally-unique public namespace that supports
different name resolution protocols is hence an architectural
requirement, and some facility for reservation of top-level
domains in the DNS is necessary."
Abley, et al. Expires April 21, 2016 [Page 5]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
If we accept the notion that the most significant label of a domain
name is actually a protocol switch, it implies that we are actually
building a catalog of all top level domains that explain which are
are switches. Note that such a catalog does not formally exist
today. It may remain a concept to guide this discussion or be
implemented as an actual IANA registry. In effect, it associates
TLDs with indications on how applications and resolvers should treat
them.
It should also be noted that there are other choice than using the
most significant label for a protocol switch. In particular, a
proposal to move those protocol switches under a specific top level
domain has been discussed (.ALT). If that architecture choice is
made, some of the questions listed in the sections bellow would
become moot.
Note: [RFC6761] mentions the reserved names could be any label in any
random string, not just the rightmost one (or ones). However, this
creates a number of complications and has not seen much support in
the community as of now.
5. Technical considerations
Each of the seven questions posed by [RFC6761] has the potential to
expose special handling of particular names in applications by a
particular audience. However, it is not clear what any of those
audiences might reasonably expect as a result of a successful request
to add a top-level domain to the Registry.
For example, reservation of a top-level domain by the IETF does not
guarantee that DNS queries for names within a reserved domain will
not be sent over the Internet. The requirements of the operators of
recursive resolvers in the DNS cannot be relied upon to be
implemented; the impact on the operators of DNS authoritative servers
hence cannot be reliably assumed to be zero. In the case of [I-
D.ietf-dnsop-onion-tld], leakage of ONION queries on the Internet
might lead to disclosure of private information that, in some cases,
might pose a risk to the personal safety of end-users.
At the time of writing, the [RFC6761] registry does not include
direct guidance for any of the seven audiences, relying instead upon
a reference for each entry in the Registry to the document that
requested its insertion. Such documents might well be opaque to many
readers ([RFC6762] is a seventy-page protocol specification, for
example, which is arguably not the most expressive way to set
expectations of non-technical end-users).
Abley, et al. Expires April 21, 2016 [Page 6]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
Useful reservations of top-level domains should be accompanied by
documentation of realistic expectations of each of the seven
audiences, and the evaluation of particular requests should consider
the practical likelihood of those expectations being met and the
implications if they are not.
Here is a non-exhaustive list of additional questions that have
surfaced in discussion of requests for names to be added to the
Special Use Names registry:
What does it mean to have a "non-DNS" entry in the registry
described above?
Are applications supposed to check that registry to know what to
do?
Can/Should applications do this check dynamically?
What if an application makes this dynamic check and realizes the
name contains a switch it does not know how to treat?
Similar questions applies to resolvers (DNS and non-DNS), what is the
expected behavior?
6. Organizational considerations
Organizational considerations can be broken down in two categories,
internal and external.
6.1. Non-exhaustive list of external organizational considerations
The policy surrounding the implementation and management of top-level
domains in the DNS has been developed using a multi-stakeholder
process convened by ICANN according to the MoU between ICANN and IETF
[RFC2860].
Whilst discussing the particular attributes that make a domain name
special, [RFC6761] notes that "the act of defining such a special
name creates a higher-level protocol rule, above ICANN's management
of allocatable names on the public Internet."
Using top level domains as protocol switches blurs the line expressed
in [RFC2860] between what is policy vs what is technical. In
particular, if the IETF formalizes this concept in the Internet
architecture, coordination will be require between ICANN and IETF on
such names. Using the analogy described above of a catalog/registry
of such switches, care must be applied to make sure we do not end up
Abley, et al. Expires April 21, 2016 [Page 7]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
with 2 process streams allowed to create entries without some form of
synchronization
6.2. IETF Internal considerations
6.2.1. Process
[RFC6761] specifies the way in which "an IETF 'Standards Action' or
'IESG Approval' document" should present answers to the questions
described above (see Section 2), but does not describe the process by
which the answers to those questions should be evaluated.
For example, it is not clear who is responsible for carrying out an
evaluation. A document which requests additions to the Registry
might be performed by the IESG, by the IAB, by the DNSOP working
group, by an ad-hoc working group, by expert review or any
combination of those approaches. [RFC6761] provides no direction.
As an illustration of the inconsistency that has been observed
already, [RFC6762] was published as an AD-sponsored individual
submission in the INT area, and the IESG evaluation record does not
reveal any discussion of the reservation of the LOCAL top-level
domain in the DNS. [I-D.ietf-dnsop-onion-tld], however, was
published as a working group document through DNSOP, and an extensive
discussion by both the participants of DNSOP and the IESG on the
merits of the request took place. The evaluation process, in the
absence of clear direction, is demonstrably inconsistent.
At the time of writing, the DNSOP working group charter does not
clearly indicate that DNSOP is the proper venue for the evaluation to
be carried out, although it also says that matters regarding the
namespace are on topic. Also, as pointed out in section 3.2), we are
not dealing with a DNS-only issue, but also with an application
issue. It is not clear at all if a DNS-centric venue such as DNSop
is the right one to examine the merits of [RFC6761] candidates.
6.2.2. Technical criteria
Regardless of the actual name being proposed as protocol switch, it
is also not clear what technical criteria should the evaluation body
use to examine the merit of an application for such a reserved name/
protocol switch. For example, is large scale prior deployment an
acceptable criteria?
Abley, et al. Expires April 21, 2016 [Page 8]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
6.2.3. Name evaluation
With regard to the actual choice of name, [RFC6761] is silent. The
answers to the seven questions are expected to tell how a name,
presumably already chosen outside of the process, might be handled if
it's determined to be a "special use" name but is silent on how to
choose a name or how to evaluate a specific proposed name.
Going back to the previous point of prior usage of the protocol, in
the case of LOCALHOST, LOCAL and ONION, those particular domain 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
not, the practical cost of a transition was argued as a justification
for their inclusion in the registry. However, when formulating a
general process for future such reservations, such prior use of
particular names may or may not be the approach the IETF wants to
choose.
The following questions should be discussed by the IETF:
Is there a need to reserve any name, as long as it is unique, or
is there any technical reason to reserve a particular name?
Are non-technical reasons to reserve a "specific" name acceptable?
Is demonstrated prior-usage of a specific name a valid rationale?
When processing gTLD applications, ICANN has a process to review
those to check if the proposed names are potentially offensive to
certain communities, have political ramifications, etc.. It is worth
asking if the IETF should have a similar process in place to evaluate
specific proposed reserved names, and, if so, how such process would
be implemented, and how appeals should be handled?
7. Security Considerations
This document aims to provide a problem statement that will inform
future work. Whilst security and privacy are fundamental
considerations, this document expects that that future work will
include such analysis, and hence no attempt is made to do so here.
8. IANA Considerations
This document has no IANA actions.
Abley, et al. Expires April 21, 2016 [Page 9]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
9. Acknowledgements
Your name here, etc.
10. References
10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[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>.
10.2. Informative References
[I-D.ietf-dnsop-dns-terminology]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", draft-ietf-dnsop-dns-terminology-05 (work in
progress), September 2015.
[I-D.ietf-dnsop-onion-tld]
Appelbaum, J. and A. Muffett, "The .onion Special-Use
Domain Name", draft-ietf-dnsop-onion-tld-01 (work in
progress), September 2015.
[I-D.lewis-domain-names]
Lewis, E., "Domain Names", draft-lewis-domain-names-01
(work in progress), September 2015.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
Abley, et al. Expires April 21, 2016 [Page 10]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
2000, <http://www.rfc-editor.org/info/rfc2826>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
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 working group.
A.2. Pithy Quotes from History
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-
toplevel name. The suggestion was made by MOCKAPETRIS@USC-ISIF
that perhaps the existing toplevel nameholders might vote on
whether the applicant for a new toplevel name should be granted,
with a majority needed for approval. It seems to me this might
produce a clique whereby whoever initially gains power will hold
it and prevent its "enemies" from getting in too. This will make
the toplevel rather less than universal.
(E-mail from Robert Elton Maas to the namedroppers mailing list on 9
November 1983)
My basic point is that as a world-wide network evolves it is
ridiculous to force people to name resources in terms of one
static hierarchy which very closely resembles the current
internetwork topology (as the current scheme does). What we are
eventually going to require is a distributed expert for making
sense out of a name someone hands it. There will be no simple
algorithm to be written on one page of an RFC that will suffice to
resolve a name. Rather, a number of heuristics will let a
resolver make sense out of a given name by querying other experts
which it suspects may be more knowledgeable about the name than it
is, or by forwarding a piece of mail to an expert which is at
least one level closer to the destination in some hierarchy.
(E-mail from Peter Karp to the namedroppers mailing list on 8
February 1984)
Abley, et al. Expires April 21, 2016 [Page 11]
Internet-Draft Top-Level/Special-Use Domain Names October 2015
A.3. Change History
A.3.1. draft-adpkja-special-names-problem-00
Initial draft circulated for comment.
Authors' Addresses
Joe Abley
Dyn, Inc.
103-186 Albert Street
London, ON N6A 1M1
Canada
Phone: +1 519 670 9327
Email: jabley@dyn.com
Peter Koch
DENIC
Email: pk@denic.de
Alain Durand
ICANN
Email: alain.durand@icann.org
Abley, et al. Expires April 21, 2016 [Page 12]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/