From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8244.txt | 1403 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1403 insertions(+) create mode 100644 doc/rfc/rfc8244.txt (limited to 'doc/rfc/rfc8244.txt') diff --git a/doc/rfc/rfc8244.txt b/doc/rfc/rfc8244.txt new file mode 100644 index 0000000..e3aec34 --- /dev/null +++ b/doc/rfc/rfc8244.txt @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Lemon +Request for Comments: 8244 Nominum, Inc. +Category: Informational R. Droms +ISSN: 2070-1721 + W. Kumari + Google + October 2017 + + + Special-Use Domain Names Problem Statement + +Abstract + + The policy defined in RFC 6761 for IANA registrations in the + "Special-Use Domain Names" registry has been shown, through + experience, to present challenges that were not anticipated when RFC + 6761 was written. This memo presents a list, intended to be + comprehensive, of the problems that have since been identified. In + addition, it reviews the history of domain names and summarizes + current IETF publications and some publications from other + organizations relating to Special-Use Domain Names. + + This document should be considered required reading for IETF + participants who wish to express an informed opinion on the topic of + Special-Use Domain Names. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8244. + + + + + + + + + + +Lemon, et al. Informational [Page 1] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + +Copyright Notice + + Copyright (c) 2017 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 + (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Problems Associated with Special-Use Domain Names . . . . . . 4 + 4. Existing Practice regarding Special-Use Domain Names . . . . 10 + 4.1. Primary Special-Use Domain Name Documents . . . . . . . . 10 + 4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 10 + 4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 12 + 4.1.3. MoU Concerning the Technical Work of IANA . . . . . . 13 + 4.1.4. Liaison Statement on Technical Use of Domain Names . 14 + 4.1.5. IAB Statement on the Registration of Special Use + Names in the ARPA Domain . . . . . . . . . . . . . . 15 + 4.2. Secondary Documents Relating to the Special-Use Domain + Name Question . . . . . . . . . . . . . . . . . . . . . . 15 + 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 15 + 4.2.2. The '.onion' Special-Use Top-Level Domain Name . . . 16 + 4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 16 + 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 17 + 4.2.5. SSAC Advisory on the Stability of the Domain + Namespace . . . . . . . . . . . . . . . . . . . . . . 17 + 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address + Synthesis . . . . . . . . . . . . . . . . . . . . . . 17 + 4.2.7. Additional Reserved Top-Level Domains . . . . . . . . 18 + 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 8. Informative References . . . . . . . . . . . . . . . . . . . 20 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + + + + + + +Lemon, et al. Informational [Page 2] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + +1. Introduction + + 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 not to assume that the term domain name implies the use of + the Domain Name System [RFC1034] for resolving these names. An + excellent presentation on this topic can be found in Domain Names + [DOMAIN-NAMES]. + + "Special-Use Domain Names" [RFC6761] created the "Special-Use Domain + Names" IANA registry [SDO-IANA-SUDR], defined policies for adding to + the registry, and made some suggestions about how those policies + 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 process defined in RFC 6761 can be improved, or + whether it should be deprecated. The IETF DNSOP Working Group + charter was extended to include conducting a review of the process + for adding names to the registry that is defined in RFC 6761. This + document is a product of that review. + + Based on current ICANN and IETF practice, including RFC 6761, there + are several different types of names in the root of the Domain + Namespace: + + o Names reserved by the IETF for technical purposes + + o Names assigned by ICANN to the public DNS root; some names + reserved by the IETF for technical purposes may appear in the + global DNS root for reasons pertaining to the operation of the DNS + + o ICANN Reserved Names; names that may not be applied for as TLDs + (see "Reserved Names" and "Treatment of Country or Territory + Names" (Sections 2.2.1.2.1 and 2.2.1.4.1, respectively) of + [SDO-ICANN-DAG]). + + o Names used by other organizations without following established + processes + + o Names that are unused and are available for assignment to one of + the previous categories + + + + + +Lemon, et al. Informational [Page 3] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + This document presents a list, derived from a variety of sources, + including discussion in the IETF DNSOP Working Group, of the problems + associated with the assignment of Special-Use Domain Names. The list + is intended to be an unfiltered compilation of issues. In support of + its analysis of the particular set of issues described here, the + document also includes descriptions of existing practice as it + relates to the use of domain names, a brief history of domain names, + and some observations by various IETF participants who have + experience with various aspects of the current situation. + +2. Terminology + + This document uses the terminology from RFC 7719 [RFC7719]. Other + terms used in this document are defined here: + + Domain Name: This document uses the term "domain name" as defined in + Section 2 of RFC 7719 [RFC7719]. + + Domain Namespace: The set of all possible domain names. + + Special-Use Domain Name: A domain name listed in the "Special-Use + Domain Names" registry [SDO-IANA-SUDR]. + + For the sake of brevity, this document uses some abbreviations, which + are expanded here: + + IANA: Internet Assigned Numbers Authority + + ICANN: Internet Corporation for Assigned Names and Numbers + + TLD: Top-Level Domain, as defined in Section 2 of RFC 7719 + [RFC7719] + + gTLD: Generic Top-Level Domain (see Section 2 of RFC 2352 + [RFC2352]) + +3. Problems Associated with Special-Use Domain Names + + This section presents a list of problems that have been identified + with respect to the assignment of Special-Use Domain Names. + Solutions to these problems, including their costs or trade-offs, are + out of scope for this document and will be covered in a separate + document. New problems that might be created in the process of + solving problems described in this document are also out of scope: + these problems are expected to be addressed in the process of + evaluating potential solutions. + + + + + +Lemon, et al. Informational [Page 4] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + Special-Use Domain Names exist to solve a variety of problems. This + document has two goals: enumerate all of the problems that have been + identified to which Special-Use Domain Names are a solution and + enumerate all of the problems that have been raised in the process of + trying to use RFC 6761 as it was intended. As some of those problems + may fall into both categories, this document makes no attempt to + categorize the problems. + + There is a broad diversity of opinion about this set of problems. + Not every participant agrees that each of the problems enumerated in + this document is actually a problem. This document takes no position + on the relative validity of the various problems that have been + enumerated, nor on the organization responsible for addressing each + individual problem, if it is to be addressed. This document only + enumerates the problems, provides the reader with context for + thinking about them, and provides a context for future discussion of + solutions, regardless of whether such solutions may work for IETF, + ICANN, IANA, or some other group. + + The list of problems is not presented in order of importance; numbers + are assigned so that each problem can easily be referenced by number, + not to indicate priority. The list of problems is as follows: + + 1. Although the IETF and ICANN have a liaison relationship through + which special-use allocations can be discussed, there exists no + formal process for coordinating these allocations (see + Section 4.1.3). The lack of coordination complicates the + management of the root of the Domain Namespace and could lead to + conflicts in name assignments [SDO-ICANN-SAC090]. + + 2. There is no explicit scoping as to what can constitute a + "technical use" [RFC2860] and what cannot; there is also no + consensus within the IETF as to what this term means. + + 3. Not all developers of protocols on the Internet agree that + authority over the entire Domain Namespace should reside solely + with the IETF and ICANN. + + 4. Although the IETF and ICANN nominally have authority over this + namespace, neither organization can enforce that authority over + any third party who wants to just start using a subset of the + namespace. Such parties may observe that the IETF has never + asserted control or authority over what protocols are "allowed" + on the Internet, and that the principle of "permissionless + innovation" suggests there should be a way for people to include + new uses of domain names in new protocols and applications. + + + + + +Lemon, et al. Informational [Page 5] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + 5. Organizations do in fact sometimes use subsets of the Domain + Namespace without following established processes. Reasons a + third party might do this include: + + 1. Lack of knowledge that a process exists for assigning such + names. + + 2. Intended use is covered by the gTLD process [SDO-ICANN-DAG], + but no gTLD process is ongoing. + + 3. Intended use is covered by the gTLD process, but the third + party doesn't want to pay a fee. + + 4. Intended use is covered by some IETF process, but the third + party doesn't want to follow the process. + + 5. Intended use is covered by an ICANN or IETF process, but the + third party expects that the outcome will be refusal or non- + action. + + 6. Lack of knowledge that a name intended to be used only + locally may nevertheless leak. + + 7. Lack of knowledge that a name used locally with informal + allocation may subsequently be allocated formally, creating + operational problems. + + 6. There is demand for more than one name resolution protocol for + domain names. Domain names contain no metadata to indicate + which protocol to use to resolve them. Domain name resolution + APIs do not provide a way to specify which protocol to use. + + 7. When a Special-Use Domain Name is added to the "Special-Use + Domain Names" registry, not all software that processes such + names will understand the special use of that name. In many + cases, name resolution software will use the Domain Name System + for resolution of names not known to have a special use. + Consequently, any such use will result in queries for Special- + Use Domain Names being sent to Domain Name System authoritative + servers. These queries may constitute an operational problem + for operators of root zone authoritative name servers. These + queries may also inadvertently reveal private information + through the contents of the query, which is a privacy + consideration. + + + + + + + +Lemon, et al. Informational [Page 6] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + 8. Some protocol developers have assumed that they could not + succeed in getting a name assigned through the IETF using the + process defined in RFC 6761. This is because when the IETF has + attempted to follow the process defined in RFC 6761, it has been + slow and uncertain. For example, the process of assigning the + first new name ('.local') using the process defined in RFC 6761 + took more than ten years from beginning to end: longer by a + factor of ten than any other part of the protocol development + process (largely because this ten years included time to develop + the process as well as use it). Other uses of the process have + proceeded more smoothly, but there is a reasonably justified + perception that using this process is likely to be slow and + difficult, with an uncertain outcome. + + 9. There is strong resistance within the IETF to assigning domain + names to resolution systems outside of the DNS, for a variety of + reasons: + + 1. It requires a mechanism for identifying which set of + resolution processes is required in order to resolve a + particular name. + + 2. Assertion of authority: there is a sense that the Domain + Namespace is "owned" by the IETF or by ICANN, so, if a name + is claimed without following their processes, the person or + entity that claimed that name should suffer some consequence + that would, presumably, deter future circumvention of the + official processes. + + 3. More than one name resolution protocol is bad, in the sense + that a single protocol is less complicated to implement and + deploy. + + 4. The semantics of alternative resolution protocols may differ + from the DNS protocol; DNS has the concept of RRtypes, + whereas other protocols may not support RRtypes or may + support some entirely different data structuring mechanism. + + 5. If there is an IETF process through which a TLD can be + assigned at zero cost other than time, this process will be + used as an alternative to the more costly process of getting + the name registered through ICANN. + + 6. A name might be assigned for a particular purpose when a + more general use of the name would be more beneficial. + + + + + + +Lemon, et al. Informational [Page 7] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + 7. If the IETF assigns a name that some third party or parties + believe belongs to them in some way, the IETF could become + embroiled in an expensive dispute with those parties. + + 10. If there were no process for assigning names for technical use + through the IETF, there is a concern that protocols that require + such names would not be able to get them. + + 11. In some cases where the IETF has made assignments through the + process defined in RFC 6761, technical mistakes have been made + due to misunderstandings as to the actual process that RFC 6761 + specifies (e.g., treating the list of suggested considerations + for assigning a name as a set of requirements, all of which must + be met). In other cases, the IETF has made de facto assignments + of Special-Use Domain Names without following the process in RFC + 6761 (see [RFC7050] and [RFC7788]). + + 12. There are several Top-Level Domain Names that are in use without + due process for a variety of purposes. The status of these + names need to be clarified and recorded to avoid future disputes + about their use [SDO-ICANN-COLL]. + + 13. In principle, the process defined in RFC 6761 could be used to + document the existence of domain names that are not safe to + assign and provide information on how those names are used in + practice. However, attempts to use RFC 6761 to accomplish this + documentation have not been successful (for example, see + "Additional Reserved Top Level Domains" [RESERVED-TLDS] and + Section 4.2.7 of this document). One side effect of the lack of + documentation is that any mitigation effect on the root name + servers or on privacy considerations has been missed. + + 14. A domain name can be identified as either a DNS name by placing + it in the DNS zone(s) or a Special-Use Domain Name by adding it + to the IANA registry. Some names are in both places; for + example, some locally served zone names are in DNS zones and + documented in the "Special-Use Domain Names" registry. At + present, the only way a domain name can be added to the + "Special-Use Domain Name" registry is for the IETF to take + responsibility for the name and designate it for "technical + use". There are other potential uses for domain names that + should be recorded in the registry, but for which the IETF + should not take responsibility. + + 15. In some cases, the IETF may see the need to document that a name + is in use without claiming that the use of the name is the + IETF's particular use of the name. No mechanism exists in the + current registry to mark names in this way. + + + +Lemon, et al. Informational [Page 8] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + 16. During any of the review stages of a document, there is no + formal process in which a check is made to ensure that the + document does not unintentionally violate the IETF process for + adding Special-Use Domain Names to the registry, as was the + case, for example, in RFC 7788 [RFC7788]. + + 17. Use of the registry is inconsistent -- some Special-Use Domain + Name RFCs specifically add registry entries, some don't; some + specify how and whether special-use name delegations should be + done, some don't. + + 18. There exists no safe, non-process-violating mechanism for ad hoc + assignment of Special-Use Domain Names. + + 19. It is generally assumed that protocols that need a Special-Use + Domain Name need a mnemonic, single-label, human-readable + Special-Use Domain Name for use in user interfaces such as + command lines or URL entry fields. While this assumption is + correct in some cases, it is likely not correct in all cases, + for example, in applications where the domain name is never + visible to a user. + + 20. RFC 6761 uses the term "domain name" to describe the thing for + which special uses are registered. This creates a great deal of + confusion because some readers take "domain name" to imply the + use of the DNS protocol. + + 21. The use of DNSSEC with Special-Use Domain Names is an open + issue. There is no consensus or guidance about how to use + DNSSEC with various classes of Special-Use Domain Names. + Considerations in the use of DNSSEC with Special-Use Domain + Names include: + + 1. What class of Special-Use Domain Name is under + consideration: non-DNS, locally served zone, or other? + + 2. Does the Special-Use Domain Name require a delegation in the + root zone; if so, should that delegation be signed or not? + If there is no delegation, then this will be treated by + validating resolvers as a secure denial of existence for + that zone. This would not be appropriate for a name being + resolved using the DNS protocol. + + 3. A process would be required through which the IETF can cause + a delegation in the root zone to be instantiated. + + 4. What are the recommended practices for using DNS with the + specific Special-Use Domain Name? + + + +Lemon, et al. Informational [Page 9] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + The above list represents the current understanding of the authors 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 related to these problems. + +4. Existing Practice regarding Special-Use Domain Names + + There are three primary (see Section 4.1) and numerous secondary + (Section 4.2) documents to consider when thinking about the Special- + Use Domain Names process. + + How names are resolved is ambiguous, in the sense that some names are + Special-Use Domain 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. The IETF has authority in some cases, but only + with respect to "technical uses". At present, ICANN is the + designated administrator of the root zone; but generally not of zones + other than the root zone. Neither of these authorities can, in any + practical sense, exclude the practice of ad hoc use of names. + Unauthorized use of domain names can be accomplished by any entity + that has control over one or more name servers or resolvers, in the + context of any hosts and services that entity operates. It can also + be accomplished by authors of software who decide that a Special-Use + Domain Name is the right way to indicate the use of an alternate + resolution mechanism. + +4.1. Primary Special-Use Domain Name Documents + + 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. + +4.1.1. IAB Technical Comment on the Unique DNS Root + + [RFC2826] is not an IETF consensus document, and it appears to have + been written to address a different problem than the Special-Use + Domain Name problem. However, it speaks directly to several of the + key issues that must be considered, and, 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 + Special-Use Domain Names. The main points that appear relevant to + the Special-Use Domain Names problem are: + + + +Lemon, et al. Informational [Page 10] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + o The Internet requires a globally unique namespace: a namespace in + which any given name refers to the same information (has the same + meaning) no matter who requests that information and no matter + from which specific name server they request it. + + o Private networks may operate private namespaces, with names that + have meanings only locally (within the private network), but they + still require that names in the public namespace be globally + unique. + + o The Domain Name System [RFC1035] is not the only protocol that may + be used for resolving domain names. + + o Users cannot be assumed to know how to distinguish between + symbolic references that have local meaning and references that + have global meaning. Therefore, users may share references that + incorporate domain names with no global meaning (for example, a + URL of 'http://mysite.example.corp', where 'example.corp' is a + domain used privately and informally as described in + [SDO-ICANN-COLL]). + + o While such a reference in the user's context refers to the object + the user wishes to share, when the reference is used in a + different context, it could refer either to some different object + in the recipient's context or to no object at all. The effect of + this reference escaping the context in which it is valid is that + the user's intended communication will not be able to be + understood by the recipients of the communication. + + This same problem can also occur when a single user copies a name + from one context in which it has one meaning into a different + context in which it has a different meaning -- for example, + copying a '.onion' domain name out of a Tor Browser [TOR], where + it has meaning, and pasting this name into an SSH client that + doesn't support connecting over the Tor network. + + We can summarize the advice in this document as follows: + + o Domain names with unambiguous global meaning are preferable to + domain names with local meaning that will be ambiguous. + Nevertheless, both globally meaningful and locally special names + are in use and must be supported. + + o At the time of the writing of this document, the IAB was of the + opinion that there might well be more than one name resolution + protocol used to resolve domain names. + + + + + +Lemon, et al. Informational [Page 11] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + +4.1.2. Special-Use Domain Names + + The second important document is "Special-Use Domain Names" + [RFC6761]. RFC 6761 represents the current IETF consensus on + designating and recording Special-Use Domain Names. The IETF has + experienced problems with the designation process described in RFC + 6761; these concerns motivate this document. Familiarity with RFC + 6761 is a prerequisite for having an informed opinion on the topic of + Special-Use Domain Names. + + RFC 6761 defines two aspects of Special-Use Domain Names: 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 (RFC 6761, Section 4): + + If it is determined that special handling of a name is required in + order to implement some desired new functionality, then an IETF + "Standards Action" or "IESG Approval" specification [RFC5226] MUST + be published describing the new functionality. + + This sentence requires that any designation of a Special-Use Domain + 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 Domain 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. + + RFC 6761 provides the process whereby "Multicast DNS" [RFC6762] + designated '.local' as a Special-Use Domain Name and included it in + the "Special-Use Domain Names" registry. RFC 6761 also enumerates a + set of names that were previously used or defined to have special + uses prior to its publication. 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. + + Several important points to think about with respect to RFC 6761 are: + + o A Special-Use Domain Name may be a name that should be resolved + using the DNS protocol with no special handling. An example of + this is 'in-addr.arpa' (which is an example of a Special-Use + Domain Name that is not a TLD). + + + + + + + +Lemon, et al. Informational [Page 12] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + o A Special-Use Domain Name may be a name that is resolved using the + DNS protocol and that requires no special handling in the stub + resolver but that requires special handling in the recursive + resolver. An example of this would be '10.in-addr.arpa.'. + + o A Special-Use Domain Name may be a name that requires special + handling in the stub resolver. An example would be a Special-Use + Top-Level Domain Name like '.local', which acts as a signal to + indicate that the local stub resolver should use a non-DNS + protocol for name resolution. + + o The current IETF consensus (from a process perspective, not + necessarily from the perspective of what would be consensus if the + IETF were to attempt to produce a new consensus document) is that + all of these purposes for Special-Use Domain Names are valid. + + In this case, the term "stub resolver" 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; however, 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 a local database of some sort is made. + + RFC 6761 does not limit Special-Use Domain Names to TLDs. However, + at present, all Special-Use Domain Names registered in the "Special- + Use Domain Names" registry [SDO-IANA-SUDR] either are intended to be + resolved using the DNS protocol, are TLDs, or are both. That is, at + present there exist no Special-Use Domain Names that 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 + RFC 6762 that when a stub resolver encounters the special label, + 'local' as the rightmost label of a domain name, it can only use the + Multicast DNS (mDNS) protocol to resolve that domain name. + +4.1.3. MoU Concerning the Technical Work of IANA + + There exists a Memorandum of Understanding (MoU) [RFC2860] between + the IETF and ICANN that discusses how names and numbers will be + managed through IANA. This document is important to the discussion + of Special-Use Domain Names because, while it delegates authority for + managing the DNS Namespace generally to ICANN, it reserves to the + IETF the authority that is then formalized in RFC 6761. RFC 2860 + specifically states: + + + + + +Lemon, et al. Informational [Page 13] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + Note that (a) assignments of domain names for technical uses (such + as domain names for inverse DNS lookup), (b) assignments of + specialised 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 above text is an addendum to the following: + + Two particular assigned spaces present policy issues in addition + to the technical considerations specified by the IETF: the + assignment of domain names, and the assignment of IP address + blocks. These policy issues are outside the scope of this MOU. + + The assignment of names in the DNS root zone, and the management of + the Domain Namespace, is by default 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. + + Implicit in the MoU is the fact that the IETF and ICANN retain, + between them, sole authority for assigning any names from the Domain + Namespace. Both the IETF and ICANN have internal processes for + making such assignments. + + 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. + +4.1.4. Liaison Statement on Technical Use of Domain Names + + When the IETF received processing requests to add names to the + "Special-Use Domain Names" registry, as documented in [RESERVED-TLDS] + and [P2P-DOMAIN-NAMES], the IETF chartered a review of the process + defined in RFC 6761 for adding names to the registry (as explained + earlier). The IETF sent a liaison statement [SDO-IAB-ICANN-LS] to + ICANN to notify them of the review, affirm that the discussion would + be "open and transparent to participation by interested parties", and + explicitly invite members of the ICANN community to participate. + + + + + + + + + + + +Lemon, et al. Informational [Page 14] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + +4.1.5. IAB Statement on the Registration of Special Use Names in the + ARPA Domain + + As part of the process of resolving the controversy mentioned in + Section 4.2.7, the IAB issued a statement saying, in part: + + There is currently no process defined with ICANN for special use + names to be delegated in the root zone; it has seemed likely to take + significant effort to create one. The IAB has noted that .arpa can + be used "for technical infrastructure established by IETF standards" + [SDO-IAB-SUDN-REG]. + + Given the lack of an established process with ICANN, IETF documents + cannot reserve names in the root of the DNS namespace if those names + are to be delegated (that is, used by the DNS protocol). It would be + possible to work with ICANN to develop a process for such + delegations, but the success of that joint work, and the amount of + time it would take, would still be uncertain. + +4.2. Secondary Documents Relating to the Special-Use Domain Name + Question + + In addition to these documents, there are several others with which + participants in this discussion should be familiar. + +4.2.1. Multicast DNS + + Multicast DNS [RFC6762] defines the Multicast DNS protocol, which + uses the '.local' Special-Use Top-Level Domain Name. Section 3 + describes the semantics of "multicast DNS names". It is of + considerable historical importance to note that the -00 version of + the document that eventually became RFC 6762, an individual + submission, was published in July of 2001. The version posted at + that time contains substantially the same text in Section 3 as RFC + 6762 did when published and was discussed in the DNSEXT Working Group + at IETF 51 in August of 2001 [IETF-PRO-51]. The July 2001 draft + designated '.local.arpa' as the Special-Use Domain 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 of RFC 6762; some notable milestones include the initial + proposal to replace AppleTalk's Name Binding Protocol (NBP) in July + 1997, the chartering of the Zeroconf Working Group in September 1999, + and the 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. + + + +Lemon, et al. Informational [Page 15] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + 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. + +4.2.2. The '.onion' Special-Use Top-Level Domain Name + + The '.onion' Special-Use Top-Level Domain Name [RFC7686] is important + because it is the most recent IETF action on the topic of Special-Use + Domain Names; although it does not set a new policy, the mere fact of + its publication is worth thinking about. + + Two important points to consider about this document are that: + + o The IETF gained consensus to publish it. + + o Devising a resolution to the situation was constrained by at least + two factors. First, there was no process for allocating Special- + Use Domain Names at the time that the '.onion' project started + using the name; at the time, and since the scope of use of the + name was expected to be very constrained, the developers chose to + allocate it unilaterally rather than asking the IETF or some other + Standards Development Organization (SDO) to create a new process. + + Second, for some time, the CA/Browser Forum [SDO-CABF] had been + issuing certificates for what they referred to as "internal + names". Internal names are names allocated unilaterally for use + in site-specific contexts. Issuing certificates for such names + came to be considered problematic, since no formal process for + testing the validity of such names existed. Consequently, the CA/ + Browser Forum decided to phase out the use of such names in + certificates [SDO-CABF-INT] and set a deadline after which no new + certificates for such names would be issued [SDO-CABF-DEADLINE]. + Because the '.onion' domain was allocated unilaterally, this would + mean that certificates for subdomains of '.onion' could no longer + be issued. + + The IETF's designation of '.onion' as a Special-Use Top-Level + Domain Name was needed to facilitate the development of a + certificate issuance process specific to '.onion' domain names + [SDO-CABF-BALLOT144]. + +4.2.3. Locally Served DNS Zones + + "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], + + + +Lemon, et al. Informational [Page 16] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + "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 Special-Use Domain + Names like '.local' and '.onion' in that the names are resolved using + the DNS protocol (but they do require extensions or exceptions to the + usual DNS resolution to enforce resolution in a local context rather + than the global DNS context). It shares the problem that such names + can be assumed neither to be unique across all contexts nor + functional for all Internet-connected hosts. + +4.2.4. Name Collision in the DNS + + "Name Collision in the DNS" [SDO-ICANN-COLL] is a study that was + commissioned by ICANN in an attempt to characterize the potential + risk to the Internet of adding global DNS delegations for names that + were not previously delegated in the DNS and were not reserved under + any RFC, but were also known to be (in the case of '.home') or + surmised to be (in the case of '.corp') in significant use for + Special-Use-type reasons (local scope DNS or other resolution + protocols altogether). + +4.2.5. SSAC Advisory on the Stability of the Domain Namespace + + The ICANN Security and Stability Advisory Committee (SSAC) + [SDO-ICANN-SSAC] specification "SSAC Advisory on the Stability of the + Domain Namespace" [SDO-ICANN-SAC090] reports on some issues + surrounding the conflicting uses, interested parties, and processes + related to the Domain Namespace. The specification recommends the + development of collaborative processes among the various interested + parties to coordinate their activities related to the Domain + Namespace. + +4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis + + "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" + [RFC7050] is an example of a document that successfully used the + process in RFC 6761 to designate '.ipv4only.arpa' as a Special-Use + Domain 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 document did not explicitly request the addition + of an entry for 'ipv4only.arpa' in the "Special-Use Domain Names" + + + +Lemon, et al. Informational [Page 17] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + registry. This is an illustration of one of the problems that we + have with the process in RFC 6761: it is apparently fairly easy to + miss the step of adding the name to the registry. + +4.2.7. Additional Reserved Top-Level Domains + + "Additional Reserved Top Level Domains" [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 the aforementioned document failed to gain consensus to be + published, the need it was intended to fill still exists. + Unfortunately, although a fair amount is known about the use of these + names, no RFC exists that describes 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. + + RFC 7788 [RFC7788] defines the Top-Level Domain Name '.home' for use + as the default name for name resolution relative to a home network + context. Although, as defined in RFC 7788, '.home' is a Special-Use + Domain Name, RFC 7788 did not follow the process specified in RFC + 6761: it did not request that '.home' be added to the "Special-Use + Domain Names" registry. This was recognized as a mistake and + resulted in the posting of an errata report [Err4677]. Additionally, + '.home' is an example of an attempt to reuse a domain name that has + already been put into use for other purposes without following + established processes [SDO-ICANN-COLL], which further complicates the + situation. At the time RFC 8244 was written, the IETF was developing + a solution to this problem. + +5. History + + A newcomer to the problem of resolving domain names may be under the + impression that the DNS sprang fully formed directly from Paul + Mockapetris' head (as was the birth of Athena in Greek Mythology). + This is not the case. At the time the IAB technical document was + written [RFC2826], memories would have been fresh of the evolutionary + process that led to 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) + + + + +Lemon, et al. Informational [Page 18] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + [RFC959]. The inefficiency of this process is cited as a reason for + the development of the DNS [RFC882] [RFC883] in 1983. + + However, the transition from HOSTS.TXT to the DNS was not smooth. + For example, Sun Microsystems' Network Information System (NIS) + [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 the NIS or WINS. + Most have the capability to resolve names using mDNS by recognizing + the special meaning of the '.local' Special-Use Top-Level Domain + Name. + + 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" + TLD 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 apparently unused TLD 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 + Domain 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. + + + + +Lemon, et al. Informational [Page 19] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + +6. Security Considerations + + This document mentions various security and privacy considerations in + the text. However, this document creates no new security or privacy + concerns. + +7. IANA Considerations + + This document does not require any IANA actions. + +8. Informative References + + [CORP-SUN-NIS] + Wikipedia, "Network Information Service", August 2017, + . + + [DOMAIN-NAMES] + Lewis, E., "Domain Names, A Case for Clarifying", Work in + Progress, draft-lewis-domain-names-09, August 2017. + + [Err4677] RFC Errata, "Erratum ID 4677", RFC 7788, + . + + [IETF-PRO-51] + IETF, "Proceedings of the 51st IETF Meeting", August 2001, + . + + [P2P-DOMAIN-NAMES] + Grothoff, C., Wachs, M., Wolf, H., Ed., Appelbaum, J., and + L. Ryge, "Special-Use Domain Names of Peer-to-Peer + Systems", Work in Progress, draft-grothoff-iesg-special- + use-p2p-names-04, January 2015. + + [PROBLEM-SPECIAL-NAMES] + Huston, G., Koch, P., Durand, A., and W. Kumari, "Problem + Statement for the Reservation of Special-Use Domain Names + using RFC6761", Work in Progress, draft-adpkja-dnsop- + special-names-problem-06, September 2016. + + [RESERVED-TLDS] + Chapin, L. and M. McFadden, "Additional Reserved Top Level + Domains", Work in Progress, draft-chapin-additional- + reserved-tlds-02, March 2015. + + + + + + + +Lemon, et al. Informational [Page 20] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + [RFC882] Mockapetris, P., "Domain names: Concepts and facilities", + RFC 882, DOI 10.17487/RFC0882, November 1983, + . + + [RFC883] Mockapetris, P., "Domain names: Implementation + specification", RFC 883, DOI 10.17487/RFC0883, November + 1983, . + + [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", + STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, + . + + [RFC1002] NetBIOS Working Group in the Defense Advanced Research + Projects Agency, Internet Activities Board, and End-to-End + Services Task Force, "Protocol standard for a NetBIOS + service on a TCP/UDP transport: Detailed specifications", + STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, + . + + [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, . + + [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, + . + + [RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain + Names", RFC 2352, DOI 10.17487/RFC2352, May 1998, + . + + [RFC2826] Internet Architecture Board, "IAB Technical Comment on the + Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May + 2000, . + + [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, + . + + + + + + +Lemon, et al. Informational [Page 21] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, + . + + [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, + RFC 6303, DOI 10.17487/RFC6303, July 2011, + . + + [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and + M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address + Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April + 2012, . + + [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol + to Replace the AppleTalk Name Binding Protocol (NBP)", + RFC 6760, DOI 10.17487/RFC6760, February 2013, + . + + [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", + RFC 6761, DOI 10.17487/RFC6761, February 2013, + . + + [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, + DOI 10.17487/RFC6762, February 2013, + . + + [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of + the IPv6 Prefix Used for IPv6 Address Synthesis", + RFC 7050, DOI 10.17487/RFC7050, November 2013, + . + + [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use + Domain Name", RFC 7686, DOI 10.17487/RFC7686, October + 2015, . + + [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", RFC 7719, DOI 10.17487/RFC7719, December + 2015, . + + [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking + Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April + 2016, . + + [SDO-CABF] CA/Browser Forum, "CA/Browser Forum Home Page", + . + + + + + + +Lemon, et al. Informational [Page 22] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + [SDO-CABF-BALLOT144] + CA/Browser Forum, "Ballot 144 - Validation Rules for + .onion Names", February 2015, . + + [SDO-CABF-DEADLINE] + CA/Browser Forum, "SSL Certificates for Internal Server + Names", January 2013, + . + + [SDO-CABF-INT] + CA/Browser Forum, "Guidance on the Deprecation of Internal + Server Names and Reserved IP Addresses", June 2012, + . + + [SDO-IAB-ICANN-LS] + IETF, "Liaison Statement from the IAB to the ICANN Board + on Technical Use of Domain Names", September 2014, + . + + [SDO-IAB-SUDN-REG] + IAB, "Internet Architecture Board statement on the + registration of special use names in the ARPA domain", + March 2017, . + + [SDO-IANA-SUDR] + IANA, "Special-Use Domain Names", . + + [SDO-ICANN-COLL] + Interisle Consulting Group, LLC, "Name Collision in the + DNS", Version 1.5, August 2013, . + + [SDO-ICANN-DAG] + ICANN, "gTLD Applicant Guidebook", Version 2012-06-04, + June 2012, . + + [SDO-ICANN-SAC090] + ICANN Security and Stability Advisory Committee, "SSAC + Advisory on the Stability of the Domain Namespace", + ICANN SAC090, December 2016, . + + + + +Lemon, et al. Informational [Page 23] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + + [SDO-ICANN-SSAC] + ICANN, "Security and Stability Advisory Committee (SSAC)", + December 2016, . + + [TOR] Tor, "Tor - Anonymity Online", + . + +Contributors + + Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron + Falk, and Suzanne Woolf 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. + + Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ + Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr + Spacek, and others provided significant review and/or useful + comments. + + This document also owes a great deal to Ed Lewis' excellent work on + what a "domain name" is [DOMAIN-NAMES]. + + We would also like to acknowledge the authors of + [PROBLEM-SPECIAL-NAMES], including Alain Durand, Geoff Huston, Peter + Koch, and Joe Abley, for their efforts to frame the issues and engage + the working group, as well as their contributions to the list of + issues from their document [PROBLEM-SPECIAL-NAMES]. + + + + + + + + + + + + + + + + + + + + + + +Lemon, et al. Informational [Page 24] + +RFC 8244 Special-Use Domain Names Problem October 2017 + + +Authors' Addresses + + Ted Lemon + Nominum, Inc. + 800 Bridge Parkway + Redwood City, CA 94065 + United States of America + + Phone: +1 650 381 6000 + Email: ted.lemon@nominum.com + + + Ralph Droms + + Email: rdroms.ietf@gmail.com + + + Warren Kumari + Google + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States of America + + Email: warren@kumari.net + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lemon, et al. Informational [Page 25] + -- cgit v1.2.3