RFC 8244

Special-Use Domain Names Problem Statement

📅 published October 2017, from ietf

RFC 8244: Special-Use Domain Names Problem Statement 🎀

okay so this one is from October 2017, it's Informational (not a Standards Track thing, just published so everyone can see it 🫶), and it's from the IETF 💅 The authors are T. Lemon (Nominum, Inc.), R. Droms, and W. Kumari (Google). The ISSN is 2070-1721. This header doesn't list anything it obsoletes or updates, so there's nothing to track there ✨

Abstract 🦋

bestie, this is the tea. The policy in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry turned out to have problems nobody saw coming when 6761 was written 😭 This memo gathers a list that's meant to be complete 📝 of the problems people have spotted since then. It also goes through the history of domain names and sums up current IETF publications, plus some from other orgs, about Special-Use Domain Names 🌸

This doc is basically required reading if you want to have an informed opinion on Special-Use Domain Names 💀✨

Status of This Memo 💜

This document is not an Internet Standards Track specification. It's published for informational purposes 🍓

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🧚

For the current status, errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8244 🔥

Copyright Notice 💖

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Code Components pulled from this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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

1. Introduction 🌸

okay so one of the key services you need to use the Internet is name resolution 💅 It's the process of turning a symbolic name into whatever object or objects it points to, most often one or more IP addresses. These names are usually called "domain names" 🎀 When you read this doc, don't assume that "domain name" means you're using the Domain Name System [RFC1034] to resolve them 👀 There's a great write-up on this in Domain Names [DOMAIN-NAMES] 🧚

"Special-Use Domain Names" [RFC6761] created the "Special-Use Domain Names" IANA registry [SDO-IANA-SUDR], set policies for adding to it, and suggested how those policies might be put into practice ✨ Since RFC 6761 came out, the IETF keeps getting asked to designate new Special-Use Domain Names in this registry 📝 While evaluating those, the IETF ran into several different kinds of issues 😭 So the IETF decided to investigate the problem and figure out whether the RFC 6761 process can be improved, or whether it should be deprecated 💖 The IETF DNSOP Working Group charter was extended to include a review of the process for adding names to the registry that RFC 6761 defines, and this document is the product of that review 🫶

Based on current ICANN and IETF practice, including RFC 6761, there are a few different types of names in the root of the Domain Namespace 🌈

Names reserved by the IETF for technical purposes
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
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]).
Names used by other organizations without following established processes
Names that are unused and are available for assignment to one of the previous categories

This document presents a list, pulled from a bunch of sources including discussion in the IETF DNSOP Working Group, of the problems tied to assigning Special-Use Domain Names 🔥 The list is meant to be an unfiltered compilation of issues 🙈 To back up its analysis, the document also describes existing practice around domain names, gives a brief history of them, and shares some observations from IETF participants who know various parts of the current situation 💜

2. Terminology 🦋

This document uses the terminology from RFC 7719 [RFC7719] 💅 Other terms used here are defined below ✨

Domain Name: this doc uses "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 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 lists the problems that have been identified with assigning Special-Use Domain Names 🧚 Solutions to these problems, including their costs and trade-offs, are out of scope for this document and will be covered in a separate document 🫶 New problems that might pop up while solving the problems described here are also out of scope 🙈 Those are expected to get handled while evaluating potential solutions, obviously 💅

Special-Use Domain Names exist to solve a variety of problems 🌈 This document has two goals: list every problem that's been identified that Special-Use Domain Names are a solution for, and list every problem that's been raised while trying to use RFC 6761 the way it was meant to be used 🔥 Some problems may fall into both groups, so this doc doesn't try to sort them into categories 💖

Not everyone in the discussion agrees on this set of problems 😭 Not every participant thinks each of the listed problems is actually a problem ✨ This document takes no position on how valid each problem is, or on which organization should handle any given problem if it does get addressed 🍓 It just lists the problems, gives readers context for thinking about them, and sets up future discussion of solutions, whether those solutions end up working for the IETF, ICANN, IANA, or some other group 🦋

The list isn't in order of importance 📝 The numbers are there so each problem is easy to reference, not to show priority 🎀 Here's the list 👑

Although the IETF and ICANN have a liaison relationship through which special-use allocations can be discussed, there's no formal process for coordinating these allocations (see Section 4.1.3). The lack of coordination makes managing the root of the Domain Namespace messy and could lead to conflicts in name assignments [SDO-ICANN-SAC090].
There's no explicit scoping for what can count as a "technical use" [RFC2860] and what can't, and there's also no consensus within the IETF on what the term means 🤷‍♀️
Not every developer of Internet protocols agrees that authority over the entire Domain Namespace should belong solely to the IETF and ICANN 🌸
Although the IETF and ICANN nominally have authority over this namespace, neither organization can enforce that authority over a third party who just wants to start using a subset of the namespace 😤 Those parties might point out that the IETF has never claimed control over what protocols are "allowed" on the Internet, and that the principle of "permissionless innovation" suggests there should be a way for people to bring new uses of domain names into new protocols and applications 🧚
Organizations do sometimes use subsets of the Domain Namespace without following established processes 👀 Reasons a third party might do this include:
1. Not knowing that a process exists for assigning such names.
2. The intended use is covered by the gTLD process [SDO-ICANN-DAG], but no gTLD process is ongoing.
Intended use is covered by the gTLD process, but the third party doesn't want to pay a fee. 💸
Intended use is covered by some IETF process, but the third party doesn't want to follow the process. 🙄
Intended use is covered by an ICANN or IETF process, but the third party expects that the outcome will be refusal or non-action. 💀
Lack of knowledge that a name intended to be used only locally may nevertheless leak. 🫣
Lack of knowledge that a name used locally with informal allocation may subsequently be allocated formally, creating operational problems. 😭
Okay so there's demand for more than one name resolution protocol for domain names, and that's a whole thing. 🦋 Domain names carry no metadata that says which protocol should be used to resolve them, and domain name resolution APIs don't give you a way to specify a protocol either. Main character problem, honestly. 💅
When a Special-Use Domain Name gets added to the "Special-Use Domain Names" registry, not all software that handles these names will know about the special use. 🥺 In a lot of cases, name resolution software just sends names with no known special use to the DNS. So any use of these names ends up with queries for Special-Use Domain Names going to Domain Name System authoritative servers. 😬 Those queries may be an operational problem for operators of root zone authoritative name servers, and they may also accidentally reveal private information in what the query contains. That's a privacy consideration, and it's giving "why is this leaking" energy. 🔒
Some protocol developers have assumed they couldn't get a name assigned through the IETF using the process defined in RFC 6761. 😩 That's because when the IETF has tried to follow that process, it has been slow and uncertain. For example, assigning the first new name (.local) through the RFC 6761 process took more than ten years from start to finish. That's longer by a factor of ten than any other part of the protocol development process, though a lot of that ten years was spent developing the process itself as well as using it. 🕰️ Other uses of the process have gone more smoothly, but there's a reasonably justified perception that using it is likely to be slow and difficult, with an uncertain outcome. Not ideal, bestie. 🙃
There is strong resistance within the IETF to assigning domain names to resolution systems outside of the DNS. 🚫 The reasons are pretty varied:
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's a sense that the Domain Namespace is "owned" by the IETF or by ICANN. So if someone claims a name without following their processes, the person or entity that claimed it should face some consequence that would, presumably, discourage 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's 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. 💸 Everyone's gonna take the free route, periodt.
6. A name might be assigned for a particular purpose when a more general use of the name would be more beneficial. 🎯
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. 🥊
If there were no process for assigning names for technical use through the IETF, there's a concern that protocols that require such names wouldn't be able to get them. 😢
In some cases where the IETF has made assignments through the process defined in RFC 6761, technical mistakes have happened because of misunderstandings about what RFC 6761 actually specifies. 🤦 One example is treating the list of suggested considerations for assigning a name as a set of requirements that all have to 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]). Oops. 🙈
There are several Top-Level Domain Names that are in use without due process for a variety of purposes. 🌀 The status of these names needs to be clarified and recorded to avoid future disputes about their use [SDO-ICANN-COLL]. 📝
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 to provide information on how those names are used in practice. 📚 However, attempts to use RFC 6761 for this documentation haven't been successful. See "Additional Reserved Top Level Domains" [RESERVED-TLDS] and Section 4.2.7 of this document for examples. 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. 👀
A domain name can be identified as either a DNS name, by placing it in the DNS zone(s), or as 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. Right now, 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 the IETF shouldn't take responsibility for them. 🫠
Sometimes the IETF may need to document that a name is in use without claiming that the use of the name is the IETF's particular use of it. 🙋 No mechanism exists in the current registry to mark names in this way. 🚧
During any of the review stages of a document, there's no formal process to check that the document doesn't unintentionally violate the IETF process for adding Special-Use Domain Names to the registry. That's what happened, for example, in RFC 7788 [RFC7788]. 😵‍💫
Use of the registry is inconsistent. Some Special-Use Domain Name RFCs specifically add registry entries and some don't. Some specify how and whether special-use name delegations should be done, and some don't. 🎢
There's no safe, non-process-violating mechanism for ad hoc assignment of Special-Use Domain Names. 🚷
It's generally assumed that protocols that need a Special-Use Domain Name need a mnemonic, single-label, human-readable name for use in user interfaces such as command lines or URL entry fields. ⌨️ That's correct in some cases, but likely not in all of them, for example in applications where the domain name is never visible to a user. 👻
RFC 6761 uses the term "domain name" to describe the thing for which special uses are registered. This causes a lot of confusion, because some readers take "domain name" to mean the use of the DNS protocol. 🌪️
The use of DNSSEC with Special-Use Domain Names is an open issue. 🔐 There's no consensus or guidance on how to use DNSSEC with the different classes of Special-Use Domain Names. Considerations 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, validating resolvers will treat this as a secure denial of existence for that zone. That wouldn't 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? 🤔

The above list represents the current understanding of the authors as to the complete set of problems identified during discussion by the working group on this topic. The rest of this document gives extra context that will be needed for reasoning about 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 get resolved is a little ambiguous, in the sense that some names are Special-Use Domain Names that need special handling, while other names can be resolved using the DNS protocol with no special handling. 🌫️

The assignment of Internet Names isn't under the sole control of any one organization. The IETF has authority in some cases, but only with respect to "technical uses". Right now, 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, stop the ad hoc use of names. Unauthorized use of domain names can be carried out by any entity that controls one or more name servers or resolvers, in the context of any hosts and services that entity operates. It can also happen when software authors 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, bestie 💅. It seems to have been written to tackle a different problem than the Special-Use Domain Name one 🙈. BUT it speaks directly to several of the key issues we need to think about, and since it came from the IAB, it's rightly treated as having serious authority even though it isn't a consensus doc 👑✨.

This document should be considered required reading 📚 for IETF folks who want to have an informed opinion on Special-Use Domain Names. The main points that seem relevant to the Special-Use Domain Names problem are:

The Internet needs a globally unique namespace 🌍: a namespace where any given name refers to the same information (has the same meaning) no matter who asks for it and no matter which specific name server they ask.
Private networks may run private namespaces 🔒, with names that only mean something locally (inside the private network). They still need names in the public namespace to be globally unique, though.
The Domain Name System [RFC1035] is not the only protocol that may be used for resolving domain names 🧚.
Users can't be assumed to know how to tell apart symbolic references with local meaning from references with global meaning 🤔. So users may share references that include domain names with no global meaning, like a URL of http://mysite.example.corp, where example.corp is a domain used privately and informally as described in [SDO-ICANN-COLL].
While such a reference works in the user's context and points to the object they want to share, when it's used in a different context it could refer to some different object in the recipient's context, or to no object at all 😬. The effect of this reference escaping the context where it's valid is that the user's intended communication won't be understood by the recipients.

This same problem can also happen when a single user copies a name from one context, where it has one meaning, into a different context where it means something else. For example, copying a .onion domain name out of a Tor Browser [TOR], where it has meaning, and pasting it into an SSH client that doesn't support connecting over the Tor network 💀.

We can summarize the advice in this document as follows:

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.
At the time this document was written, the IAB was of the opinion that there might well be more than one name resolution protocol used to resolve domain names 🦋.

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 had problems with the designation process described in RFC 6761, and those concerns are what motivate this document 😤. Being familiar with RFC 6761 is a prerequisite for having an informed opinion on Special-Use Domain Names, so go read it first, babe 📖.

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 means that any designation of a Special-Use Domain Name goes through the same open review and consensus process used to produce and publish all other IETF specifications 🫶.

The registration process is a purely mechanical process 🤖. The existence of the newly designated Special-Use Domain Name gets recorded, along with a pointer to a section in the relevant specification document that defines how special handling is to be applied to the name.

RFC 6761 is 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 lists a set of names that were previously used or defined to have special uses before it was published. Since there was no registry for these names before RFC 6761 came out, the documents defining these names couldn't have added them to the registry 🥲.

Several important points to think about with respect to RFC 6761 are:

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) 🔍.
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 does require special handling in the recursive resolver. An example of this would be 10.in-addr.arpa. 🧠.
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 that the local stub resolver should use a non-DNS protocol for name resolution 🍓.
The current IETF consensus (from a process perspective, not necessarily from the perspective of what would be consensus if the IETF tried 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 by using the DNS protocol. However, the decision about whether to use a protocol (and if so, which one) or a local database of some sort is made inside the stub resolver, as we're using the term here 🧚‍♀️.

RFC 6761 does not limit Special-Use Domain Names to TLDs. However, at present, every Special-Use Domain Name registered in the "Special-Use Domain Names" registry [SDO-IANA-SUDR] is either intended to be resolved using the DNS protocol, is a TLD, or is both. In other words, right now there are no Special-Use Domain Names that require special handling by stub resolvers and that aren't at the top level of the naming hierarchy 🌸.

One point to take from this is that RFC 6762 already has a requirement: 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 is a Memorandum of Understanding (MoU) [RFC2860] between the IETF and ICANN that discusses how names and numbers will be managed through IANA. This document matters to the Special-Use Domain Names discussion because, while it hands 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 says:

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.

Assigning names in the DNS root zone, and managing the Domain Namespace, is by default something ICANN does 🌐. But the MoU specifically exempts domain names assigned for technical use, and uses domains used for inverse DNS lookup as its example. Both in-addr.arpa and ip6.arpa are in the "Special-Use Domain Names" registry 🔥.

What's implicit in the MoU is that the IETF and ICANN keep, between them, sole authority for assigning any names from the Domain Namespace. Both the IETF and ICANN have internal processes for making those assignments 🤝.

The point here isn't to say what the implications of this statement in the MoU are. It's to call the reader's attention to the fact that the statement exists 👀✨.

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 🫂.

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 that participants in this discussion should be familiar with 📚🧚.

4.2.1. Multicast DNS 💖

okay so [RFC6762] is the Multicast DNS protocol, and it uses the .local Special-Use Top-Level Domain Name 🌸 Section 3 of that doc explains what "multicast DNS names" actually mean. Here's the bit I'm obsessed with: the -00 version of the document that eventually became RFC 6762, which was an individual submission, was published in July of 2001 🦋 The version posted back then has substantially the same text in Section 3 as RFC 6762 did when it was published, and it got discussed in the DNSEXT Working Group at IETF 51 in August of 2001 [IETF-PRO-51]. ✨ The July 2001 draft named .local.arpa as the Special-Use Domain Name, but DNSEXT Working Group participants strongly opposed that idea, so the author eventually switched to .local. Not me being dramatic, but that's a whole plot twist 😭

The history of RFC 6762 is documented in a lot of detail in Appendix H of RFC 6762 🍓 A few highlights: the initial proposal to replace AppleTalk's Name Binding Protocol (NBP) came in July 1997, the Zeroconf Working Group got chartered in September 1999, and a multicast address for link-local name discovery was assigned in April of 2000. A companion requirements document, eventually published as [RFC6760], was first published in September of 2001 🎀

Why do we care about these dates? Because discussions about the time when the .local domain was first deployed, and the context it was deployed in, need to be properly informed 🧚

4.2.2. The `.onion` Special-Use Top-Level Domain Name 🧅

The .onion Special-Use Top-Level Domain Name [RFC7686] is a big deal because it's the most recent IETF action on Special-Use Domain Names 👑 It doesn't set a new policy, but the fact that it got published is still worth thinking about, fr fr.

Two important points about this document:

The IETF gained consensus to publish it. 💅
Coming up with a resolution was constrained by at least two factors. 😭 First, there was no process for allocating Special-Use Domain Names at the time the .onion project started using the name. The scope of use was expected to be very constrained, so the developers chose to allocate it unilaterally instead of 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 called "internal names" 🙈 Internal names are names allocated unilaterally for use in site-specific contexts. Issuing certificates for them became problematic, since no formal process for testing the validity of such names existed. So 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 .onion was allocated unilaterally, this meant certificates for subdomains of .onion could no longer be issued. Major plot twist, bestie 💀

The IETF's designation of .onion as a Special-Use Top-Level Domain Name was needed to make it possible to develop 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 specific use case for zones that exist by definition and get resolved using the DNS protocol, but that can't have a global meaning because the host IP addresses they reference aren't unique 🦋 This covers a bunch of addresses, including private IPv4 addresses [RFC1918], "Unique Local IPv6 Unicast Addresses" [RFC4193] (which is where this practice was first described), and "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598].

This use case is different from the one for Special-Use Domain Names like .local and .onion. The names are resolved using the DNS protocol, but they do need extensions or exceptions to the usual DNS resolution so that resolution happens 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 ICANN commissioned to figure out the potential risk to the Internet of adding global DNS delegations for names that weren't previously delegated in the DNS and weren't reserved under any RFC 🙈 These names were also known to be in significant use (in the case of .home) or surmised to be in significant use (in the case of .corp) for Special-Use-type reasons, like 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] wrote the specification "SSAC Advisory on the Stability of the Domain Namespace" [SDO-ICANN-SAC090]. It reports on issues around conflicting uses, interested parties, and processes related to the Domain Namespace 🎀 It recommends developing collaborative processes among the various interested parties so they can 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, even though the IETF process worked smoothly (there was little controversy or delay in approving the new use), it didn't work correctly 😭 The name ipv4only.arpa was never added to the "Special-Use Domain Names" registry. This appears to have happened because the document didn't explicitly request the addition of an entry for ipv4only.arpa in that registry. It's an illustration of one of the problems we have with the process in RFC 6761: it's apparently pretty 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 tried to reserve several TLDs that ICANN identified as particularly at risk for collision as Special-Use Domain Names with no documented use. That attempt failed 💀

Even though that document didn't gain consensus to be published, the need it was meant to fill still exists 🌈 The problem is that, although a fair amount is known about how these names are used, no RFC describes how they're used or why it would be a problem to delegate them. And to the extent that the uses being made of these names are valid, no document says when it might make sense to use them and when it wouldn't 🦋

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 🏠 Even though RFC 7788 defines .home as a Special-Use Domain Name, it didn't follow the process specified in RFC 6761. It didn't request that .home be added to the "Special-Use Domain Names" registry. This was recognized as a mistake and led to an errata report [Err4677] 🙈 On top of that, .home is an example of an attempt to reuse a domain name that was already in use for other purposes without following established processes [SDO-ICANN-COLL], which makes the situation even messier 😭 When RFC 8244 was written, the IETF was developing a solution to this problem ✨

5. History 📜

A newcomer to the problem of resolving domain names might think the DNS sprang fully formed directly from Paul Mockapetris' head (like the birth of Athena in Greek Mythology) 🦉 That's not what happened. When the IAB technical document was written [RFC2826], memories were still fresh of the evolutionary process that led to DNS' dominance as a protocol for domain name resolution 🌸

In the early days of the Internet, hostnames were resolved using a text file, HOSTS.TXT, which a central authority, the Network Information Center, maintained. It was distributed to all hosts on the Internet using the File Transfer Protocol (FTP) [RFC959] 📁 The inefficiency of this process is cited as a reason for developing the DNS [RFC882] [RFC883] in 1983 🎀

The transition from HOSTS.TXT to the DNS wasn't smooth, though 😬 For example, Sun Microsystems' Network Information System (NIS) [CORP-SUN-NIS], which was known as Yellow Pages at the time, was an active competitor to the DNS. It failed to provide a complete solution to the global naming problem 💅

Another example is NetBIOS Name Service, also known as WINS [RFC1002] 🧚 This protocol was used mostly by Microsoft Windows machines, but open-source BSD and Linux operating systems also used it to do name resolution with 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 can also 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 use, 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 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 still persists 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 one question: why do users of new name resolution protocols choose to use domain names instead of some other naming concept that doesn't overlap with the namespace that, in modern times, is resolved by default using the DNS? 🤔

The answer is that, because of this long history of resolving domain names with a wide variety of name resolution systems, domain names are required in a large variety of contexts in user interfaces and application 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 🫶

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 🧾✨

okay bestie, this is where the receipts live 💅 these are all the outside docs and sources the RFC leans on for context. none of them are required reading to implement it, but they're the whole backstory 🫶

[CORP-SUN-NIS]
           Wikipedia, "Network Information Service", August 2017,
           <https://en.wikipedia.org/wiki/
           Network_Information_Service>.

[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,
           <https://www.rfc-editor.org/errata/eid4677>.

[IETF-PRO-51]
           IETF, "Proceedings of the 51st IETF Meeting", August 2001,
           <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.

[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.

[RFC882]   Mockapetris, P., "Domain names: Concepts and facilities",
           RFC 882, DOI 10.17487/RFC0882, November 1983,
           <https://www.rfc-editor.org/info/rfc882>.

[RFC883]   Mockapetris, P., "Domain names: Implementation
           specification", RFC 883, DOI 10.17487/RFC0883, November
           1983, <https://www.rfc-editor.org/info/rfc883>.

[RFC959]   Postel, J. and J. Reynolds, "File Transfer Protocol",
           STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
           <https://www.rfc-editor.org/info/rfc959>.

[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,
           <https://www.rfc-editor.org/info/rfc1002>.

[RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
           <https://www.rfc-editor.org/info/rfc1034>.

[RFC1035]  Mockapetris, P., "Domain names - implementation and
           specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
           November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[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,
           <https://www.rfc-editor.org/info/rfc1918>.

[RFC2352]  Vaughan, O., "A Convention For Using Legal Names as Domain
           Names", RFC 2352, DOI 10.17487/RFC2352, May 1998,
           <https://www.rfc-editor.org/info/rfc2352>.

[RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
           Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
           2000, <https://www.rfc-editor.org/info/rfc2826>.

[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,
           <https://www.rfc-editor.org/info/rfc2860>.

[RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
           Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
           <https://www.rfc-editor.org/info/rfc4193>.

[RFC6303]  Andrews, M., "Locally Served DNS Zones", BCP 163,
           RFC 6303, DOI 10.17487/RFC6303, July 2011,
           <https://www.rfc-editor.org/info/rfc6303>.

[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, <https://www.rfc-editor.org/info/rfc6598>.

[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,
           <https://www.rfc-editor.org/info/rfc6760>.

[RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
           RFC 6761, DOI 10.17487/RFC6761, February 2013,
           <https://www.rfc-editor.org/info/rfc6761>.

[RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
           DOI 10.17487/RFC6762, February 2013,
           <https://www.rfc-editor.org/info/rfc6762>.

[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,
           <https://www.rfc-editor.org/info/rfc7050>.

[RFC7686]  Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
           Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
           2015, <https://www.rfc-editor.org/info/rfc7686>.

[RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
           Terminology", RFC 7719, DOI 10.17487/RFC7719, December
           2015, <https://www.rfc-editor.org/info/rfc7719>.

[RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
           Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
           2016, <https://www.rfc-editor.org/info/rfc7788>.

[SDO-CABF] CA/Browser Forum, "CA/Browser Forum Home Page",
           <https://cabforum.org>.

[SDO-CABF-BALLOT144]
           CA/Browser Forum, "Ballot 144 - Validation Rules for
           .onion Names", February 2015, <https://cabforum.org/2015/
           02/18/ballot-144-validation-rules-dot-onion-names>.

[SDO-CABF-DEADLINE]
           CA/Browser Forum, "SSL Certificates for Internal Server
           Names", January 2013,
           <https://www.digicert.com/internal-names.htm>.

[SDO-CABF-INT]
           CA/Browser Forum, "Guidance on the Deprecation of Internal
           Server Names and Reserved IP Addresses", June 2012,
           <https://cabforum.org/internal-names/>.

[SDO-IAB-ICANN-LS]
           IETF, "Liaison Statement from the IAB to the ICANN Board
           on Technical Use of Domain Names", September 2014,
           <https://datatracker.ietf.org/liaison/1351>.

[SDO-IAB-SUDN-REG]
           IAB, "Internet Architecture Board statement on the
           registration of special use names in the ARPA domain",
           March 2017, <https://www.iab.org/documents/
           correspondence-reports-documents/2017-2/iab-statement-on-
           the-registration-of-special-use-names-in-the-arpa-
           domain/>.

[SDO-IANA-SUDR]
           IANA, "Special-Use Domain Names", <http://www.iana.org/
           assignments/special-use-domain-names>.

[SDO-ICANN-COLL]
           Interisle Consulting Group, LLC, "Name Collision in the
           DNS", Version 1.5, August 2013, <https://www.icann.org/
           en/system/files/files/name-collision-02aug13-en.pdf>.

[SDO-ICANN-DAG]
           ICANN, "gTLD Applicant Guidebook", Version 2012-06-04,
           June 2012, <https://newgtlds.icann.org/en/applicants/agb/
           guidebook-full-04jun12-en.pdf>.

[SDO-ICANN-SAC090]
           ICANN Security and Stability Advisory Committee, "SSAC
           Advisory on the Stability of the Domain Namespace",
           ICANN SAC090, December 2016, <https://www.icann.org/en/
           system/files/files/sac-090-en.pdf>.

[SDO-ICANN-SSAC]
           ICANN, "Security and Stability Advisory Committee (SSAC)",
           December 2016, <https://www.icann.org/groups/ssac>.

[TOR]      Tor, "Tor - Anonymity Online",
           <https://www.torproject.org>.

Contributors 🎀

big shoutout to Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron Falk, and Suzanne Woolf 🫶 they gave super helpful and insightful feedback or patiently answered our questions. quick disclaimer though: that does NOT mean they all agree with everything in here 😭 we're just really grateful for their time and brainpower anyway 💖

stephane bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr Spacek, and others gave major reviews and/or useful comments 🌸 literal legends, all of them ✨

this doc also owes a huge debt to Ed Lewis, whose excellent work on what a "domain name" actually is [DOMAIN-NAMES] 🧚

and we want to give a special thank-you to the authors of [PROBLEM-SPECIAL-NAMES], including Alain Durand, Geoff Huston, Peter Koch, and Joe Abley 💅 they helped frame the issues, engaged the working group, and contributed to the list of issues in their document [PROBLEM-SPECIAL-NAMES] 🙌

Authors' Addresses 💌

these are the people who wrote it, and how to reach them 🦋

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

📦 where this page comes from

ietf: rfc8244 2017-10
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms