| Network Working Group | T. Lemon |
| Internet-Draft | Nominum, Inc. |
| Intended status: Informational | R. Droms |
| Expires: May 3, 2017 | |
| W. Kumari | |
| October 30, 2016 |
Special-Use Names Problem Statement
draft-ietf-dnsop-sutld-ps-00
The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other standards organizations relating to special-use domain names.
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 May 3, 2017.
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.
One of the key services required to use the Internet is name resolution. Name resolution is the process of translating a symbolic name into some object or set of objects to which the name refers, most typically one or more IP addresses. These names are often referred to as domain names. When reading this document, care must be taken to not assume that the term Domain Name implies the particular protocol for resolving these names, the Domain Name System [RFC1034]. An excellent presentation on this topic can be found in Domain Names [I-D.lewis-domain-names].
Special-Use Domain Names [RFC6761] created an IANA registry for special-use domain names [SDO-IANA-SUDR], defined policies for adding to the registry, and made some suggestions about how that policy might be implemented. Since the publication of RFC 6761, the IETF has been asked to designate several new special-use Domain Names in this registry. During the evaluation process for these special-use Domain Names, the IETF encountered several different sorts of issues. Because of this, the IETF has decided to investigate the problem and decide if and how the RFC 6761 process can be improved, or whether it should be deprecated.
This document presents a list, believed to be complete, of the problems associated with the assignment of special-use names. In support of the particular set of problems described here, the document also includes documentation of existing practice as it relates to the use of Domain Names, as well as a brief history of domain names, and finally to describe the set of problems that exist as reported by various IETF participants with experience in the various aspects of the problem.
For the sake of brevity this document uses a number of abbreviations. These are expanded here:
This section presents a list of problems that have been identified with respect to the assignment of special-use names. Solutions to these problems are out of scope for this document. Because of that, problems with solutions to these problems are also out of scope for this document, and will be covered in a separate document.
No assertion is made that any of these problems is more or less important than any other. The point of this is simply to enumerate and briefly describe the problems that have been raised during discussions of the special-use name problem. The degree of detail is intended to be sufficient that that participants in the discussion can agree that the problems they've raised have been adequately described, and no more. These problems should not appear to every reader to all be problems: we intend to cover any problem that any participant considers a problem, not just those problems that everyone agrees are problems.
In addition, no assertion is made that all of these problems must be addressed, or that, if we think they should be addressed, the IETF is the organization with competence to address them. While each problem has one or more solutions, the solutions may in some cases be mutually contradictory, or may come with costs that do not justify the benefit that would be obtained from solving them.
This is the list of problems:
The problems we have stated here represent the current understanding of the authors of the document as to the complete set of problems that have been identified during discussion by the working group on this topic. The remainder of this document provides additional context that will be needed for reasoning about these problems.
There are three primary and numerous secondary documents to consider when thinking about the Special-Use Domain Names process.
The primary documents are considered primary because they directly address the IETF's past thoughts on this topic in a general way, and also because they describe what the IETF does in practice. Only one of these documents is an IETF consensus document.
This document [RFC2826] is not an IETF consensus document, and appears to have been written to address a different problem than the SUDN problem. However, it speaks directly to several of the key issues that must be considered, and of course coming as it does from the IAB, it is rightly treated as having significant authority despite not being an IETF consensus document.
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of SUDNs. The main points that appear relevant to the special use names problem are:
To boil this down even further, we can take the following advice from this document:
The second important document is Special-Use Domain Names [RFC6761]. RFC6761 represents the current IETF consensus on designating and recording SUDNs. The IETF has experienced problems with the designation process described in RFC6761; these concerns motivate this document. Again, familiarity with RFC6761 is a prerequisite for having an informed opinion on the topic of SUDNs.
RFC 6761 defines two aspects of SUDNs: designating a domain name to have a special purpose and registering that special use in the Special-Use Domain Names registry. The designation process is defined in a single sentence (RFC6761, section 4):
This sentence implies that any designation of a special-use name is subject to the same open review and consensus process as used to produce and publish all other IETF specifications.
The registration process is a purely mechanical process, in which the existence of the newly designated special use name is recorded, with a pointer to a section in the relevant specification document that defines the ways in which special handling is to be applied to the name.
RFC6761 provided the process whereby Multicast DNS [RFC6762] designated ".local" as a special-use name and included it in the Special-Use Names registry. It itself also enumerated a set of names that had been previously used or defined to have special uses prior to the publication of RFC6761. Since there had been no registry for these names prior to the publication of RFC 6761, the documents defining these names could not have added them to the registry.
There are at least several important points to think of with respect to the RFC6761:
The term "stub resolver" in this case does not mean "DNS protocol stub resolver." The stub resolver is the entity within a particular software stack that takes a question about a Domain name and answers it. One way a stub resolver can answer such a question is using the DNS protocol, but it is in the stub resolver, as we are using the term here, that the decision as to whether to use a protocol, and if so which protocol, or whether to use a local database of some sort, is made.
RFC6761 does not limit special-use names to TLDs. However, at present, all special-use names registered in the IANA Special-Use Domain Names registry [SDO-IANA-SUDR] are either intended to be resolved using the DNS protocol, or are top-level domains, or both. That is, at present there exist no special-use names which require special handling by stub resolvers and which are not at the top level of the naming hierarchy.
One point to take from this is that there is already a requirement in RFC6762 that when stub resolvers encounter the special label, '.LOCAL' at the top level of a domain name, they can only use the mDNS protocol be used for resolving that domain name.
There exists a Memorandum of Understanding[RFC2860] between the IETF and ICANN (Internet Corporation for Assigned Names and Numbers) which discusses how names and numbers will be managed through the IANA (Internet Assigned Numbers Authority). This document is important to the discussion of SUDNs because, while it delegates authority for managing the Domain Name System Namespace generally to ICANN, it reserves to the IETF the authority that RFC 6761 formalizes:
The above text is an addendum to the following:
In general, then, the assignment of names in the DNS root zone, and the management of the DNS namespace, is a function that is performed by ICANN. However, the MoU specifically exempts domain names assigned for technical use, and uses the example of domains used for inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the special-use domain names registry.
The point here is not to say what the implications of this statement in the MoU are, but rather to call the reader's attention to the existence of this statement.
In addition to these documents, there are several others with which participants in this discussion should be familiar.
Multicast DNS [RFC6762] defines the Multicast DNS protocol, which uses the '.LOCAL' SUTLDN. Section 3 describes the semantics of "multicast DNS names." It is of considerable historical importance to note that the -00 version of this document, an individual submission, was published in July of 2001. This version contains substantially the same text in section 3, and was discussed in the DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51]. The first version of this document designated '.LOCAL.ARPA' as the special-use name. This idea was strongly opposed by DNSEXT working group participants, and as a result the author eventually switched to using '.LOCAL'.
The history of RFC 6762 is documented in substantial detail in Appendix H; some notable milestones include the initial proposal to replace Appletalk's NBP in July 1997, the chartering of the Zeroconf working group in September 1999, assignment of a multicast address for link-local name discovery in April of 2000. A companion requirements document, eventually published as [RFC6760] was first published in September of 2001.
The point of mentioning these dates is so that discussions involving the time when the '.LOCAL' domain was first deployed, and the context in which it was deployed, may be properly informed.
The .onion Special Use TLD [RFC7686] is important because it is the most recent IETF action on the topic of SUTLDNs; although it does not set new policy, the mere fact of its publication is worth thinking about.
Two important points to consider about this document are that:
Locally Served DNS Zones [RFC6303] describes a particular use case for zones that exist by definition, and that are resolved using the DNS protocol, but that cannot have a global meaning, because the host IP addresses they reference are not unique. This applies to a variety of addresses, including Private IPv4 addresses [RFC1918], Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice was first described) and IANA-Reserved IPv4 Prefix for Shared Address Space [RFC6598].
This use case is distinct from the use-case for SUTLDNs like '.local' and '.onion' in that the names are resolved using the DNS protocol. But it shares the problem that such names cannot be assumed either to be unique or to be functional in all contexts for all Internet-connected hosts.
Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by ICANN that attempts to characterize the potential risk to the Internet of adding global DNS delegations for names that were not previously delegated in the DNS, not reserved under any RFC, but also known to be (.home) or surmised to be (.corp) in significant use for special-use-type reasons (local scope DNS, or other resolution protocols altogether).
Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [RFC7050] is an example of a document that successfully used the RFC 6761 process to designate '.ipv4only.arpa' as a special-use name; in this case the process worked smoothly and without controversy.
Unfortunately, while the IETF process worked smoothly, in the sense that there was little controversy or delay in approving the new use, it did not work correctly: the name 'ipv4only.arpa' was never added to the special-use domain names registry. This appears to have happened because the IAB was able to simply add the name to the .ARPA zone, which the IAB administers. This is an illustration of one of the problems that we have with the 6761 process: it is apparently fairly easy to miss the step of adding the name to the registry.
Additional Reserved Top Level Domains [I-D.chapin-additional-reserved-tlds] is an example of a document that attempted to reserve several TLDs identified by ICANN as particularly at risk for collision as special-use domain names with no documented use. This attempt failed.
Although this document failed to gain consensus to publish, the need it was intended to fill still exists. Unfortunately, although a fair amount is known about the use of these names, no document exists that documents how they are used, and why it would be a problem to delegate them. Additionally, to the extent that the uses being made of these names are valid, no document exists indicating when it might make sense to use them, and when it would not make sense to use them.
How names are resolved is ambiguous, in the sense that some names are special-use names that require special handling, and some names can be resolved using the DNS protocol with no special handling.
The assignment of Internet Names is not under the sole control of any one organization. IETF has authority in some cases, but only with respect to "technical uses." ICANN at present is the designated administrator of the root zone, but generally not of zones other than the root zone. And neither of these authorities can in any practical sense exclude the practice of ad-hoc use of names. This can be done by any entity that has control over one or more name servers or resolvers, in the context of any hosts and services that that entity operates. It can also be done by authors of software who decide that a special-use name is the right way to indicate the use of an alternate resolution mechanism.
Newcomers to the problem of resolving domain names may be under the mistaken impression that the DNS sprang, as in the Greek legend of Athena, directly from Paul Mockapetris' forehead. This is not the case. At the time of the writing of the IAB technical document, memories would have been fresh of the evolutionary process that led to the DNS' dominance as a protocol for domain name resolution.
In fact, in the early days of the Internet, hostnames were resolved using a text file, HOSTS.TXT, which was maintained by a central authority, the Network Information Center, and distributed to all hosts on the Internet using the File Transfer Protocol (FTP) [RFC0959]. The inefficiency of this process is cited as a reason for the development of the DNS [RFC0882] [RFC0883] in 1983.
However, the transition from HOSTS.TXT to the DNS was not smooth. For example, Sun Microsystems's Network Information System [CORP-SUN-NIS], at the time known as Yellow Pages, was an active competitor to the DNS, although it failed to provide a complete solution to the global naming problem.
Another example was NetBIOS Name Service, also known as WINS [RFC1002]. This protocol was used mostly by Microsoft Windows machines, but also by open source BSD and Linux operating systems to do name resolution using Microsoft's own name resolution protocol.
Most modern operating systems can still use the '/etc/hosts' file for name resolution. Many still have a name service switch that can be configured on the host to resolve some domains using NIS or WINS. Most have the capability to resolve names using mDNS by recognizing the special meaning of the '.local' SUTLDN.
The Sun Microsystems model of having private domains within a corporate site, while supporting the global domain name system for off-site, persisted even after the NIS protocol fell into disuse. Microsoft used to recommend that site administrators use a "private" top-level domain for internal use, and this practice was very much a part of the zeitgeist at the time (see section 5.1 of [SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at the root of the widespread practice of simply picking an unused top-level domain and using it for experimental purposes, which persists even at the time of writing of this memo.
This history is being presented because discussions about special-use names in the IETF often come down to the question of why users of new name resolution protocols choose to use Domain names, rather than using some other naming concept that doesn't overlap with the namespace that, in modern times is, by default, resolved using the DNS.
The answer is that as a consequence of this long history of resolving Domain Names using a wide variety of name resolution systems, Domain Names are required in a large variety of contexts in user interfaces and applications programming interfaces. Any name that appears in such a context is a Domain Name. So developers of new name resolution systems that must work in existing contexts actually have no choice: they must use a special-use Domain Name to segregate a portion of the namespace for use with their system.
This document came about as a result of conversations that occurred in the conference hotel lobby, the weekend before IETF 95, when the original author, Ted Lemon, was trying to come up with a better problem statement. Stuart Cheshire, Mark Andrews, David Conrad, Paul Ebersman and Aaron Falk all made helpful and insightful observations or patiently answered questions. This should not be taken as an indication that any of these folks actually agree with what the document says, but their generosity with time and thought are appreciated in any case.
Ralph started out as an innocent bystander, but discussion with him was the key motivating factor in the writing of this document, and he agreed to co-author it without too much arm-twisting. Warren spent a lot of time working with us on this document after it was first published, and joined as an author in order to make sure that the work got finished; without him the -01 and -02 versions might not have happened.
This document also owes a great deal to Ed Lewis' excellent work on what a "domain name" is [I-D.lewis-domain-names].
-03 to -04:
-02 to -03:
-01 to -02:
-00 to -01: