Special-Use Domain Names
Problem Statement
Nominum, Inc.
800 Bridge Parkway
Redwood City
CA
United States of America
94065
+1 650 381 6000
ted.lemon@nominum.com
rdroms.ietf@gmail.com
Google
1600 Amphitheatre Parkway
Mountain View
CA
94043
United States of America
warren@kumari.net
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.
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 for resolving these names. An
excellent presentation on this topic can be found in Domain Names.
"Special-Use Domain Names" created the "Special-Use Domain
Names" IANA registry, 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:
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 ).
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, 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.
This document uses the terminology from RFC
7719. Other terms used in this document are defined here:
This document uses the term "domain name"
as defined in Section 2 of RFC
7719.
The set of all possible domain
names.
A domain name listed in the
"Special-Use Domain Names" registry .
For the sake of brevity, this document uses some abbreviations, which
are expanded here:
Internet Assigned Numbers Authority
Internet Corporation for Assigned Names and
Numbers
Top-Level Domain, as defined in Section 2 of RFC 7719
Generic Top-Level Domain (see Section 2 of RFC 2352)
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.
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:
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 ). The lack of coordination complicates the management
of the root of the Domain Namespace and could lead to conflicts in name
assignments .
There is no explicit scoping as to what can constitute a "technical use" and what cannot; there
is also no consensus within the IETF as to what this term means.
Not all developers of protocols on the Internet agree that
authority over the entire Domain Namespace should reside solely with
the IETF and ICANN.
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.
Organizations do in fact sometimes use subsets of the Domain
Namespace without following established processes. Reasons a third
party might do this include:
Lack of knowledge that a process exists for assigning such names.
Intended use is covered by the gTLD process , 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.
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.
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.
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.
There is strong resistance within the IETF to assigning domain
names to resolution systems outside of the DNS, for a variety of
reasons:
It requires a mechanism for identifying which set of
resolution processes is required in order to resolve a
particular name.
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.
More than one name resolution protocol is bad, in the sense
that a single protocol is less complicated to implement and
deploy.
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.
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.
A name might be assigned for a particular purpose when a more
general use of the name would be more beneficial.
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 is a concern that protocols that require
such names would not be able to get them.
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 and ).
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
.
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" and
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.
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.
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.
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 .
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.
There exists no safe, non-process-violating mechanism for ad hoc
assignment of Special-Use Domain Names.
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.
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.
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:
What class of Special-Use Domain Name is under consideration:
non-DNS, locally served zone, or other?
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.
A process would be required through which the IETF can cause
a delegation in the root zone to be instantiated.
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 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.
There are three primary (see ) and
numerous secondary () 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.
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.
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:
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.
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.
The Domain Name System is not
the only protocol that may be used for resolving domain
names.
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 ).
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
, 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:
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 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.
The second important document is
"Special-Use Domain Names". 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,
):
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" 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:
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 requires 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 to
indicate 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 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 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.
There exists a Memorandum of Understanding (MoU) 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:
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.
When the IETF received processing requests to add names to the
"Special-Use Domain Names" registry, as documented in and , 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 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.
As part of the process of resolving the controversy mentioned in , 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" .
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.
In addition to these documents, there are several others with which
participants in this discussion should be familiar.
Multicast DNS 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 . 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 , was first published in September of 2001.
The point of mentioning these dates is so that discussions
involving the time when the '.local' domain was first deployed, and
the context in which it was deployed, may be properly informed.
The '.onion' Special-Use Top-Level Domain
Name 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:
The IETF gained consensus to publish it.
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 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 and set a deadline after which no new
certificates for such names would be issued . 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 .
"Locally Served DNS Zones" 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, "Unique Local IPv6 Unicast Addresses" (in
which this practice was first described), and "IANA-Reserved IPv4 Prefix for Shared Address
Space".
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.
"Name Collision in the DNS" 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).
The ICANN Security and Stability Advisory Committee (SSAC) specification "SSAC Advisory on the Stability of the Domain Namespace"
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.
"Discovery of the IPv6 Prefix Used for IPv6
Address Synthesis" 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" 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.
"Additional
Reserved Top Level Domains" 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 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 . 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 , which further complicates the situation.
At the time [RFCXXXX] was written, the IETF was developing a
solution to this problem.
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 , 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).
The inefficiency of this process is cited as a reason for
the development of the DNS in 1983.
However, the transition from HOSTS.TXT to the DNS was not smooth. For
example, Sun Microsystems' Network
Information System (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 . 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 and Appendix G of ).
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.
This document mentions various security and privacy considerations in
the text. However, this document creates no new security or privacy
concerns.
This document does not require any IANA actions.
Additional Reserved Top Level Domains
Special-Use Domain Names of Peer-to-Peer Systems
Domain Names, A Case for Clarifying
Guidance on the Deprecation of Internal Server Names and
Reserved IP Addresses
CA/Browser Forum
SSL Certificates for Internal Server Names
CA/Browser Forum
CA/Browser Forum Home Page
CA/Browser Forum
Ballot 144 - Validation Rules for .onion Names
CA/Browser Forum
Name Collision in the DNS
Interisle Consulting Group, LLC
SSAC Advisory on the Stability of the Domain
Namespace
ICANN Security and Stability Advisory
Committee
Security and Stability Advisory Committee (SSAC)
ICANN
Special-Use Domain Names
IANA
gTLD Applicant Guidebook
ICANN
Liaison Statement from the IAB to the ICANN Board on
Technical Use of Domain Names
IETF
Erratum ID 4677
RFC Errata
Network Information Service
Wikipedia
Proceedings of the 51st IETF Meeting
IETF
Tor - Anonymity Online
Tor
Problem Statement for the Reservation of Special-Use Domain Names using RFC6761
Internet Architecture Board statement on the registration of special use names in the ARPA domain
IAB
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.
We would also like to acknowledge the authors of
, 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
.