Network Working Group T. Lemon
Internet-Draft Nominum, Inc.
Intended status: Informational R. Droms
Expires: May 3, 2017
W. Kumari
Google
October 30, 2016
Special-Use Names Problem Statement
draft-ietf-dnsop-sutld-ps-00
Abstract
The Special-Use Domain Names IANA registry policy defined in RFC 6761
has been shown through experience to present unanticipated
challenges. This memo presents a list, intended to be comprehensive,
of the problems that have been identified. In addition it reviews
the history of Domain Names and summarizes current IETF publications
and some publications from other standards organizations relating to
special-use domain names.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Lemon, et al. Expires May 3, 2017 [Page 1]
Internet-Draft Special-Use Names Problem October 2016
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problems associated with Special-Use Domain Names . . . . . . 3
4. Existing Practice Regarding SUDNs . . . . . . . . . . . . . . 7
4.1. Primary SUDN Documents . . . . . . . . . . . . . . . . . 7
4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 7
4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 8
4.1.3. MoU Concerning the Technical Work of the IANA . . . . 10
4.2. Secondary documents relating to the SUTLDN question . . . 11
4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 11
4.2.2. The .onion Special-Use TLD . . . . . . . . . . . . . 11
4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 12
4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 12
4.2.5. Discovery of the IPv6 Prefix Used for IPv6 Address
Synthesis . . . . . . . . . . . . . . . . . . . . . . 12
4.2.6. Additional Reserved Top Level Domains . . . . . . . . 13
4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Informative References . . . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 to not assume that the term Domain Name implies the
particular protocol for resolving these names, the Domain Name System
[RFC1034]. An excellent presentation on this topic can be found in
Domain Names [I-D.lewis-domain-names].
Special-Use Domain Names [RFC6761] created an IANA registry for
special-use domain names [SDO-IANA-SUDR], defined policies for adding
to the registry, and made some suggestions about how that policy
might be implemented. Since the publication of RFC 6761, the IETF
has been asked to designate several new special-use Domain Names in
Lemon, et al. Expires May 3, 2017 [Page 2]
Internet-Draft Special-Use Names Problem October 2016
this registry. During the evaluation process for these special-use
Domain Names, the IETF encountered several different sorts of issues.
Because of this, the IETF has decided to investigate the problem and
decide if and how the RFC 6761 process can be improved, or whether it
should be deprecated.
This document presents a list, believed to be complete, of the
problems associated with the assignment of special-use names. In
support of the particular set of problems described here, the
document also includes documentation of existing practice as it
relates to the use of Domain Names, as well as a brief history of
domain names, and finally to describe the set of problems that exist
as reported by various IETF participants with experience in the
various aspects of the problem.
2. Terminology
For the sake of brevity this document uses a number of abbreviations.
These are expanded here:
Domain Name A name which serves as input to a name resolution
process, for example 'EXAMPLE.ORG'.
SUDN Special Use Domain Name
SUTLDN Special-Use Top-Level Domain Name
IANA Internet Assigned Numbers Authority
ICANN Internet Corporation for Assigned Names and Numbers
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 names. Solutions to
these problems are out of scope for this document. Because of that,
problems with solutions to these problems are also out of scope for
this document, and will be covered in a separate document.
No assertion is made that any of these problems is more or less
important than any other. The point of this is simply to enumerate
and briefly describe the problems that have been raised during
discussions of the special-use name problem. The degree of detail is
intended to be sufficient that that participants in the discussion
can agree that the problems they've raised have been adequately
described, and no more. These problems should not appear to every
reader to all be problems: we intend to cover any problem that any
Lemon, et al. Expires May 3, 2017 [Page 3]
Internet-Draft Special-Use Names Problem October 2016
participant considers a problem, not just those problems that
everyone agrees are problems.
In addition, no assertion is made that all of these problems must be
addressed, or that, if we think they should be addressed, the IETF is
the organization with competence to address them. While each problem
has one or more solutions, the solutions may in some cases be
mutually contradictory, or may come with costs that do not justify
the benefit that would be obtained from solving them.
This is the list of problems:
o ICANN is responsible for managing the public DNS root, which is
the root from which all DNS protocol resolution starts. At the
same time, IETF has authority to reserve domain names for
technical purposes, including domain names that would otherwise be
included in the public root. No formal coordination process
exists. This complicates the coordination particularly of
assignments of single-label (top-level) special-use domain names.
o The term "technical use" in the MoU is considered by some to be
too inclusive.
o The IETF and ICANN have administrative authority over some parts
of the domain name namespace. Not all developers of protocols on
the internet agree that this authority should reside with the IETF
and ICANN.
o Although 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.
o Organizations do in fact sometimes commandeer subsets of the
namespace. Reasons a third party might do this include:
* Unaware that a process exists for assigning such names
* Intended use is covered by gTLD process, but no gTLD process is
ongoing
* Intended use is covered by gTLD process, don't want to pay fee
* Intended use is covered by some IETF process, but don't want to
follow process
* Intended use is covered by ICANN or IETF process, but expected
outcome is refusal or non-action
Lemon, et al. Expires May 3, 2017 [Page 4]
Internet-Draft Special-Use Names Problem October 2016
o There is demand for more than one name resolution protocol for
Domain Names, but Domain Names contain no metadata to indicate
which protocol to use to resolve them.
o 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. Consequently, any such
use will result in queries for that name being sent to
authoritative servers. This constitutes an operational problem
for operators of root zone authoritative name servers.
o The RFC6761 process is sufficiently uncertain that some protocol
developers have assumed they could not get a name assigned; the
process of assigning the first new name ('.local') using the RFC
6761 process took more than ten years from beginning to end:
longer by a factor of ten than any other part of the protocol
development process. 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.
o There is strong resistance within the IETF to assigning names to
things outside of the DNS, for a variety of reasons:
* Requires a mechanism for identifying which of a set of
resolution processes is required in order to resolve a
particular name.
* Assertion of authority: there is a sense that the namespace is
"owned" by the IETF or by ICANN, and so, if a name is claimed
outside of that process, the person or entity that claimed that
name should suffer some consequence that would, presumably,
deter future circumvention of the official process.
* 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; other
protocols may not support RRtypes, or may support some entirely
different data structuring mechanism.
* If there is an IETF process through which a name can be
assigned at zero cost other than time, this process will be
used as an alternative to purchasing the name through ICANN.
Lemon, et al. Expires May 3, 2017 [Page 5]
Internet-Draft Special-Use Names Problem October 2016
* Some names that might be assigned would be sufficiently generic
that other legitimate uses of those names would overlap with a
proposed use, so that assigning the name would preclude some
future, better use of it.
* If the IETF assigns a name that some third party or parties
believes belongs to them in some way, the IETF could become
embroiled in an expensive dispute with those parties.
o 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.
o In cases where the IETF has made assignments through the RFC 6761
process, technical mistakes have been made due either 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), or to a
failure to follow the process that was defined in RFC 6761.
o In principle, the RFC 6761 process 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 RFC6761 to accomplish this
[I-D.chapin-additional-reserved-tlds] have not been successful.
One side effect of this is that any mitigation effect on the root
name servers has been missed.
o No mechanism exists for adding a name to the registry without
claiming that the IETF is responsible for that name, nor is it
possible to state a precedence for the name, e.g. "if ICANN
delegates this name, ICANN's delegation takes precedence."
o No process exists for checking documents to make sure they don't
accidentally assign names (e.g. RFC 7788).
o Use of the registry is inconsistent--some SUTLDN RFCs specify
registry entries, some don't; some specify delegation, some don't.
o There exists no safe, non-process-violating mechanism for ad-hoc
assignment of special-use names.
o It is generally assumed that protocols that need a special-use
name need a human-readable special-use name. This assumption may
not be warranted in all cases.
o RFC 6761 uses the term "Domain Name" to describe the thing for
which special uses are registered. This creates a great deal of
Lemon, et al. Expires May 3, 2017 [Page 6]
Internet-Draft Special-Use Names Problem October 2016
confusion because some readers take "Domain Name" to imply the use
of the DNS protocol.
The problems we have stated here represent the current understanding
of the authors of the document as to the complete set of problems
that have been identified during discussion by the working group on
this topic. The remainder of this document provides additional
context that will be needed for reasoning about these problems.
4. Existing Practice Regarding SUDNs
There are three primary and numerous secondary documents to consider
when thinking about the Special-Use Domain Names process.
4.1. Primary SUDN 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. Only one
of these documents is an IETF consensus document.
4.1.1. IAB Technical Comment on the Unique DNS Root
This document [RFC2826] is not an IETF consensus document, and
appears to have been written to address a different problem than the
SUDN problem. However, it speaks directly to several of the key
issues that must be considered, and of course coming as it does from
the IAB, it is rightly treated as having significant authority
despite not being an IETF consensus document.
This document should be considered required reading for IETF
participants who wish to express an informed opinion on the topic of
SUDNs. The main points that appear relevant to the special use names
problem are:
o The Internet requires a globally unique namespace
o Private networks may operate private namespaces, but 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 referebces that
have global meaning. Users may therefore share references that
incorporate domain names with no global meaning (for example, a
URL of 'http://mysite.example.corp', where 'example.corp' is a
Lemon, et al. Expires May 3, 2017 [Page 7]
Internet-Draft Special-Use Names Problem October 2016
domain used privately and informally as described in
[SDO-ICANN-COLL]).
o Such references might refer to the object the user intends to
share within that user's context, but either refer to some other
object any recipient's context, or might not refer to any object
at all in a recipient's context. The effect of this is that the
user's intended communication will not be able to be understood by
the recipients of the communication.
o This same problem can also occur simply because 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 TOR.
To boil this down even further, we can take the following advice from
this document:
o Domain names with unambiguous global meaning are preferable to
domain names with local meaning which 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.
4.1.2. Special-Use Domain Names
The second important document is Special-Use Domain Names [RFC6761].
RFC6761 represents the current IETF consensus on designating and
recording SUDNs. The IETF has experienced problems with the
designation process described in RFC6761; these concerns motivate
this document. Again, familiarity with RFC6761 is a prerequisite for
having an informed opinion on the topic of SUDNs.
RFC 6761 defines two aspects of SUDNs: designating a domain name to
have a special purpose and registering that special use in the
Special-Use Domain Names registry. The designation process is
defined in a single sentence (RFC6761, section 4):
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.
Lemon, et al. Expires May 3, 2017 [Page 8]
Internet-Draft Special-Use Names Problem October 2016
This sentence implies that any designation of a special-use name is
subject to the same open review and consensus process as used to
produce and publish all other IETF specifications.
The registration process is a purely mechanical process, in which the
existence of the newly designated special use name is recorded, with
a pointer to a section in the relevant specification document that
defines the ways in which special handling is to be applied to the
name.
RFC6761 provided the process whereby Multicast DNS [RFC6762]
designated ".local" as a special-use name and included it in the
Special-Use Names registry. It itself also enumerated a set of names
that had been previously used or defined to have special uses prior
to the publication of RFC6761. Since there had been no registry for
these names prior to the publication of RFC 6761, the documents
defining these names could not have added them to the registry.
There are at least several important points to think of with respect
to the RFC6761:
o A special-use 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.'
o A special-use name may be a name that is resolved using the DNS
protocol, requires no special handling in the stub resolver, but
requires special handling in the recursive resolver. An example
of this would be "10.in-addr.arpa."
o A special-use name may be a name that requires special handling in
the stub resolver. An example would be a special-use top-level
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 names are valid.
The term "stub resolver" in this case does not mean "DNS protocol
stub resolver." The stub resolver is the entity within a particular
software stack that takes a question about a Domain name and answers
it. One way a stub resolver can answer such a question is using the
DNS protocol, but it is in the stub resolver, as we are using the
term here, that the decision as to whether to use a protocol, and if
Lemon, et al. Expires May 3, 2017 [Page 9]
Internet-Draft Special-Use Names Problem October 2016
so which protocol, or whether to use a local database of some sort,
is made.
RFC6761 does not limit special-use names to TLDs. However, at
present, all special-use names registered in the IANA Special-Use
Domain Names registry [SDO-IANA-SUDR] are either intended to be
resolved using the DNS protocol, or are top-level domains, or both.
That is, at present there exist no special-use names which require
special handling by stub resolvers and which are not at the top level
of the naming hierarchy.
One point to take from this is that there is already a requirement in
RFC6762 that when stub resolvers encounter the special label,
'.LOCAL' at the top level of a domain name, they can only use the
mDNS protocol be used for resolving that domain name.
4.1.3. MoU Concerning the Technical Work of the IANA
There exists a Memorandum of Understanding[RFC2860] between the IETF
and ICANN (Internet Corporation for Assigned Names and Numbers) which
discusses how names and numbers will be managed through the IANA
(Internet Assigned Numbers Authority). This document is important to
the discussion of SUDNs because, while it delegates authority for
managing the Domain Name System Namespace generally to ICANN, it
reserves to the IETF the authority that RFC 6761 formalizes:
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.
In general, then, the assignment of names in the DNS root zone, and
the management of the DNS namespace, is a function that is performed
by ICANN. However, the MoU specifically exempts domain names
assigned for technical use, and uses the example of domains used for
inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the
special-use domain names registry.
Lemon, et al. Expires May 3, 2017 [Page 10]
Internet-Draft Special-Use Names Problem October 2016
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.2. Secondary documents relating to the SUTLDN 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' SUTLDN. Section 3 describes the semantics of
"multicast DNS names." It is of considerable historical importance
to note that the -00 version of this document, an individual
submission, was published in July of 2001. This version contains
substantially the same text in section 3, and was discussed in the
DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51]. The
first version of this document designated '.LOCAL.ARPA' as the
special-use name. This idea was strongly opposed by DNSEXT working
group participants, and as a result the author eventually switched to
using '.LOCAL'.
The history of RFC 6762 is documented in substantial detail in
Appendix H; some notable milestones include the initial proposal to
replace Appletalk's NBP in July 1997, the chartering of the Zeroconf
working group in September 1999, assignment of a multicast address
for link-local name discovery in April of 2000. A companion
requirements document, eventually published as [RFC6760] was first
published in September of 2001.
The point of mentioning these dates is so that discussions involving
the time when the '.LOCAL' domain was first deployed, and the context
in which it was deployed, may be properly informed.
4.2.2. The .onion Special-Use TLD
The .onion Special Use TLD [RFC7686] is important because it is the
most recent IETF action on the topic of SUTLDNs; although it does not
set new policy, the mere fact of its publication is worth thinking
about.
Two important points to consider about this document are that:
o The IETF gained consensus to publish it
o The situation was somewhat forced, both by the fact of its
unilateral use by the TOR project without following the RFC 6761
Lemon, et al. Expires May 3, 2017 [Page 11]
Internet-Draft Special-Use Names Problem October 2016
process, and because a deadline had been set by the CA/Browser
Forum [SDO-CABF-INT] after which all .onion PKI certificates would
expire and no new certificates would be issued, unless the .onion
SUTLDN were to be recognized by the IETF.
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],
Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice
was first described) and IANA-Reserved IPv4 Prefix for Shared Address
Space [RFC6598].
This use case is distinct from the use-case for SUTLDNs like '.local'
and '.onion' in that the names are resolved using the DNS protocol.
But it shares the problem that such names cannot be assumed either to
be unique or to be functional in all contexts for all Internet-
connected hosts.
4.2.4. Name Collision in the DNS
Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by
ICANN that attempts to characterize the potential risk to the
Internet of adding global DNS delegations for names that were not
previously delegated in the DNS, not reserved under any RFC, but also
known to be (.home) or surmised to be (.corp) in significant use for
special-use-type reasons (local scope DNS, or other resolution
protocols altogether).
4.2.5. 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 RFC
6761 process to designate '.ipv4only.arpa' as a special-use name; in
this case the process worked smoothly and without controversy.
Unfortunately, while the IETF process worked smoothly, in the sense
that there was little controversy or delay in approving the new use,
it did not work correctly: the name 'ipv4only.arpa' was never added
to the special-use domain names registry. This appears to have
happened because the IAB was able to simply add the name to the .ARPA
zone, which the IAB administers. This is an illustration of one of
the problems that we have with the 6761 process: it is apparently
fairly easy to miss the step of adding the name to the registry.
Lemon, et al. Expires May 3, 2017 [Page 12]
Internet-Draft Special-Use Names Problem October 2016
4.2.6. Additional Reserved Top Level Domains
Additional Reserved Top Level Domains
[I-D.chapin-additional-reserved-tlds] is an example of a document
that attempted to reserve several TLDs identified by ICANN as
particularly at risk for collision as special-use domain names with
no documented use. This attempt failed.
Although this document failed to gain consensus to publish, the need
it was intended to fill still exists. Unfortunately, although a fair
amount is known about the use of these names, no document exists that
documents how they are used, and why it would be a problem to
delegate them. Additionally, to the extent that the uses being made
of these names are valid, no document exists indicating when it might
make sense to use them, and when it would not make sense to use them.
4.3. Summary
How names are resolved is ambiguous, in the sense that some names are
special-use names that require special handling, and some names can
be resolved using the DNS protocol with no special handling.
The assignment of Internet Names is not under the sole control of any
one organization. IETF has authority in some cases, but only with
respect to "technical uses." ICANN at present is the designated
administrator of the root zone, but generally not of zones other than
the root zone. And neither of these authorities can in any practical
sense exclude the practice of ad-hoc use of names. This can be done
by any entity that has control over one or more name servers or
resolvers, in the context of any hosts and services that that entity
operates. It can also be done by authors of software who decide that
a special-use name is the right way to indicate the use of an
alternate resolution mechanism.
5. History
Newcomers to the problem of resolving domain names may be under the
mistaken impression that the DNS sprang, as in the Greek legend of
Athena, directly from Paul Mockapetris' forehead. This is not the
case. At the time of the writing of the IAB technical document,
memories would have been fresh of the evolutionary process that led
to the DNS' dominance as a protocol for domain name resolution.
In fact, in the early days of the Internet, hostnames were resolved
using a text file, HOSTS.TXT, which was maintained by a central
authority, the Network Information Center, and distributed to all
hosts on the Internet using the File Transfer Protocol (FTP)
Lemon, et al. Expires May 3, 2017 [Page 13]
Internet-Draft Special-Use Names Problem October 2016
[RFC0959]. The inefficiency of this process is cited as a reason for
the development of the DNS [RFC0882] [RFC0883] in 1983.
However, the transition from HOSTS.TXT to the DNS was not smooth.
For example, Sun Microsystems's Network Information System
[CORP-SUN-NIS], at the time known as Yellow Pages, was an active
competitor to the DNS, although it failed to provide a complete
solution to the global naming problem.
Another example was NetBIOS Name Service, also known as WINS
[RFC1002]. This protocol was used mostly by Microsoft Windows
machines, but also by open source BSD and Linux operating systems to
do name resolution using Microsoft's own name resolution protocol.
Most modern operating systems can still use the '/etc/hosts' file for
name resolution. Many still have a name service switch that can be
configured on the host to resolve some domains using NIS or WINS.
Most have the capability to resolve names using mDNS by recognizing
the special meaning of the '.local' SUTLDN.
The Sun Microsystems model of having private domains within a
corporate site, while supporting the global domain name system for
off-site, persisted even after the NIS protocol fell into disuse.
Microsoft used to recommend that site administrators use a "private"
top-level domain for internal use, and this practice was very much a
part of the zeitgeist at the time (see section 5.1 of
[SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at
the root of the widespread practice of simply picking an unused top-
level domain and using it for experimental purposes, which persists
even at the time of writing of this memo.
This history is being presented because discussions about special-use
names in the IETF often come down to the question of why users of new
name resolution protocols choose to use Domain names, rather than
using some other naming concept that doesn't overlap with the
namespace that, in modern times is, by default, resolved using the
DNS.
The answer is that as a consequence of this long history of resolving
Domain Names using a wide variety of name resolution systems, Domain
Names are required in a large variety of contexts in user interfaces
and applications programming interfaces. Any name that appears in
such a context is a Domain Name. So developers of new name
resolution systems that must work in existing contexts actually have
no choice: they must use a special-use Domain Name to segregate a
portion of the namespace for use with their system.
Lemon, et al. Expires May 3, 2017 [Page 14]
Internet-Draft Special-Use Names Problem October 2016
6. Contributors
This document came about as a result of conversations that occurred
in the conference hotel lobby, the weekend before IETF 95, when the
original author, Ted Lemon, was trying to come up with a better
problem statement. Stuart Cheshire, Mark Andrews, David Conrad, Paul
Ebersman and Aaron Falk all made helpful and insightful observations
or patiently answered questions. This should not be taken as an
indication that any of these folks actually agree with what the
document says, but their generosity with time and thought are
appreciated in any case.
Ralph started out as an innocent bystander, but discussion with him
was the key motivating factor in the writing of this document, and he
agreed to co-author it without too much arm-twisting. Warren spent a
lot of time working with us on this document after it was first
published, and joined as an author in order to make sure that the
work got finished; without him the -01 and -02 versions might not
have happened.
This document also owes a great deal to Ed Lewis' excellent work on
what a "domain name" is [I-D.lewis-domain-names].
7. Informative References
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983,
<http://www.rfc-editor.org/info/rfc882>.
[RFC0883] Mockapetris, P., "Domain names: Implementation
specification", RFC 883, DOI 10.17487/RFC0883, November
1983, <http://www.rfc-editor.org/info/rfc883>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<http://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,
<http://www.rfc-editor.org/info/rfc1002>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
Lemon, et al. Expires May 3, 2017 [Page 15]
Internet-Draft Special-Use Names Problem October 2016
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
2000, <http://www.rfc-editor.org/info/rfc2826>.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860,
DOI 10.17487/RFC2860, June 2000,
<http://www.rfc-editor.org/info/rfc2860>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011,
<http://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, <http://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,
<http://www.rfc-editor.org/info/rfc6760>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
Lemon, et al. Expires May 3, 2017 [Page 16]
Internet-Draft Special-Use Names Problem October 2016
[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,
<http://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, <http://www.rfc-editor.org/info/rfc7686>.
[I-D.chapin-additional-reserved-tlds]
Chapin, L. and M. McFadden, "Additional Reserved Top Level
Domains", draft-chapin-additional-reserved-tlds-02 (work
in progress), March 2015.
[I-D.lewis-domain-names]
Lewis, E., "Domain Names", draft-lewis-domain-names-04
(work in progress), September 2016.
[SDO-CABF-INT]
CA/Browser Forum, "Guidance on the Deprecation of Internal
Server Names and Reserved IP Addresses", June 2012,
<https://www.digicert.com/internal-names.htm>.
[SDO-ICANN-COLL]
Interisle Consulting Group, LLC, "Name Collisions in the
DNS", August 2013,
<https://www.icann.org/en/system/files/files/name-
collision-02aug13-en.pdf>.
[SDO-IANA-SUDR]
Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015,
<http://www.iana.org/assignments/special-use-domain-names/
special-use-domain-names.xhtml>.
[CORP-SUN-NIS]
Sun Microsystems, "Large System and Network
Administration", March 1990.
[IETF-PRO-51]
Internet Engineering Task Force, "Proceedings of the 51st
IETF", August 2001,
<http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
Lemon, et al. Expires May 3, 2017 [Page 17]
Internet-Draft Special-Use Names Problem October 2016
Appendix A. Change Log.
-03 to -04:
o Replaced 'Internet Names' with 'Domain Names' - suggestion by John
Levine.
-02 to -03:
o Readability fixes, small grammar updates.
-01 to -02:
o Cleaned up the abstract.
o Fixed the case of Internet
o Reference to Ed Lewis' "domain names"
o Fleshed out the problems, primarily the coordination, collisions
ones.
-00 to -01:
o Large refactoring, basically a rewrite. Incorporated comments,
removed a bunch of unneeded text, etc.
Authors' Addresses
Ted Lemon
Nominum, Inc.
800 Bridge Parkway
Redwood City, California 94065
United States of America
Phone: +1 650 381 6000
Email: ted.lemon@nominum.com
Ralph Droms
Email: rdroms.ietf@gmail.com
Lemon, et al. Expires May 3, 2017 [Page 18]
Internet-Draft Special-Use Names Problem October 2016
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: warren@kumari.net
Lemon, et al. Expires May 3, 2017 [Page 19]
