| 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
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.
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/.
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 (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.
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:
[This section to be completed following review and refinement of the rest of the text.]
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):
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.
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:
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.
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:
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
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.
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).
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:
Similar questions applies to resolvers (DNS and non-DNS), what is the expected behavior?
Organizational considerations can be broken down in two categories, internal and external.
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 with 2 process streams allowed to create entries without some form of synchronization
[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.
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?
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:
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?
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.
This document has no IANA actions.
Your name here, etc.
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987. |
| [RFC1035] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987. |
| [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. |
| [RFC6761] | Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013. |
| [I-D.ietf-dnsop-dns-terminology] | Hoffman, P., Sullivan, A. and K. Fujiwara, "DNS Terminology", Internet-Draft draft-ietf-dnsop-dns-terminology-05, September 2015. |
| [I-D.ietf-dnsop-onion-tld] | Appelbaum, J. and A. Muffett, "The .onion Special-Use Domain Name", Internet-Draft draft-ietf-dnsop-onion-tld-01, September 2015. |
| [I-D.lewis-domain-names] | Lewis, E., "Domain Names", Internet-Draft draft-lewis-domain-names-01, 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. |
| [RFC2826] | Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000. |
| [RFC6762] | Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013. |
This section (and sub-sections) to be removed prior to publication.
An appropriate forum for discussion of this draft is for now the dnsop working group.
(E-mail from Robert Elton Maas to the namedroppers mailing list on 9 November 1983)
(E-mail from Peter Karp to the namedroppers mailing list on 8 February 1984)
Initial draft circulated for comment.