Problem Statement for the Reservation of Top-Level Domains in the Special-Use Domain Names Registry
draft-adpkja-dnsop-special-names-problem-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Joe Abley , Peter Koch , Alain Durand | ||
Last updated | 2015-10-19 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-adpkja-dnsop-special-names-problem-00
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]