Internet DRAFT - draft-lewis-domain-names
draft-lewis-domain-names
Network Working Group E. Lewis
Internet-Draft ICANN
Intended status: Informational August 6, 2019
Expires: February 7, 2020
RFC Origins of Domain Names
draft-lewis-domain-names-13
Abstract
Is the concept of Domain Names owned by the DNS protocol or does the
DNS protocol exist to support the concept of Domain Names? This
question has become pertinent in light of proposals to use Domain
Names in protocols in ways incompatible with the DNS protocol and the
operational environment built to run the protocol.
This document is intended to help answer this question by presenting
a look into the recorded history of relevant Requests for Comments.
This document comprises the research and views of the author and has
benefited from review and input from many IETF experts, but it does
not represent the consensus opinion of the IETF.
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 https://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 February 7, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
Lewis Expires February 7, 2020 [Page 1]
Internet-Draft RFC Origins of Domain Names August 2019
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Early RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Emergence of Domain Names . . . . . . . . . . . . . . . . . . 6
3.1. The Term "Domain Name" Itself . . . . . . . . . . . . . . 7
3.2. The Term "Resolve" . . . . . . . . . . . . . . . . . . . 8
3.3. Where Does It Start? . . . . . . . . . . . . . . . . . . 9
4. Dialects, So To Speak, of Domain Names . . . . . . . . . . . 10
4.1. Domain Names in the DNS . . . . . . . . . . . . . . . . . 10
4.2. Host Names . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. URI Authority and Domain Names . . . . . . . . . . . . . 12
4.4. Internet Protocol Address Literals . . . . . . . . . . . 12
4.5. Internationalized Domain Names in Applications . . . . . 12
4.6. Restricted for DNS Registration . . . . . . . . . . . . . 13
4.7. Tor Network Names . . . . . . . . . . . . . . . . . . . . 13
4.8. X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.9. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 14
4.10. /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . 14
4.11. Other Protocols . . . . . . . . . . . . . . . . . . . . . 14
4.12. Other Others . . . . . . . . . . . . . . . . . . . . . . 15
5. Interoperability Considerations . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. Informational References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
Which came first, the concept of Domain Names or the DNS? This
question is at the heart of whether or how Domain Names are put to
use in ways avoiding the DNS protocol.
The discussion leading to "The '.onion' Special-Use Domain Name"
[RFC7686], a document designating "onion" as a top-level domain in
the Special Use Domain Names registry (see "Special Use Domain Names"
[RFC6761]), opened the question of how to treat Domain Names that
were designed to be used external to the DNS. The history of Domain
Lewis Expires February 7, 2020 [Page 2]
Internet-Draft RFC Origins of Domain Names August 2019
Names and the DNS had become intertwined over time to the point that
what is essentially a case of permission-less innovation led to
contentious discussions on the IETF's DNS Operations (DNSOP) working
group mail list and an interim meeting of the DNSOP working
group[DNSOP].
A portion of the discussion centered around a seeming conflict among
processes to register Domain Names, such as the process launched from
"Memorandum of Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority" [RFC2860], for registering a
name in the global, public DNS and the process for registering a name
in the Special Use Domain Names registry. The latter process is
documented in "Special Use Domain Names" cited in the previous
paragraph.
To help establish a way forward, a look backward is thought to be a
good start. A document search, sticking to RFC documents, reveals
evidence of discussions on Domain Names prior to the DNS, with the
DNS protocol's base documents indicating that the DNS is based on
some simplifying assumptions, implying there is a larger concept in
play.
To help bolster the idea that Domain Names came first, a look at how
other protocols have treated identifying names, how Domain Names are
put to use, how what a name is further restricted for the protocol's
needs. From this it has become apparent that the concept of Domain
Names has drifted over time, which leads to some uncertainty when it
comes to looking forward.
During reviews of this document, documented studies of other
difficulties resulting from the uncertainty have surfaced. "IAB
Thoughts on Encodings for Internationalized Domain Names" [RFC6055]
documents issues related to converting human-readable forms of Domain
Names in forms useful to automated applications when there is no
clear architecture or precise definition of how to handle Domain
Names. "Issues in Identifier Comparison for Security Purposes"
[RFC6943] documents issues related to the same conversion as related
to evaluating security policies. The presence of these studies
suggests a need to examine the architecture of naming and
identifiers.
The most glaring omission discovered by the document survey is a
definitive foundation for Domain Names. There are abstract
descriptions of the concept that come close to qualifying as a
definition. The descriptions though are too loose to be something
that can be tested objectively, frustrating discussions when it comes
to innovations in the use of Domain Names.
Lewis Expires February 7, 2020 [Page 3]
Internet-Draft RFC Origins of Domain Names August 2019
In reviews of this document, an important thought has been expressed.
During the era when the early RFC documents were prepared, many
considerations now deemed important were not considered, discussed,
examined. This lack of attention should be taken simply as the the
limits of the problem space perceived at the time and not as an
intentional non-statement about questions now under consideration.
The fact that the history is presented here does not imply that
history will contain the answers and guide the way forward, the
history as presented is only a starting point.
This document is a literature search covering the RFC series and
makes a case for clarifications to be made. There are obvious
continuations to this work, such as the earlier Internet Engineering
Notes series (IEN), other published works, and interviews with
participants from the early days. This document is intended to help
answer this question of whether the concept of Domain Names is owned
by the DNS protocol or does the DNS protocol exist to support the
concept of Domain Names. It does this by presenting a look into the
recorded history of relevant Requests for Comments. This document
comprises the research and views of the author and has benefited from
review and input from many IETF experts, but it does not represent
the consensus opinion of the IETF.
1.1. Goal
To establish a solid foundation accommodating an installed base and
permission-less innovation, having a clear definition of Domain Names
would be great. This document, however, does not attempt to achieve
a definition. This document's goal has settled into compiling a
narrative on the history, within perhaps artificial bounds (the RFC
series), and declaring that there is a need to clarify Domain Names.
In this document are criteria for performing a clarification,
recognizing from experience in preparing "The Role of Wildcards in
the Domain Name System" [RFC4592] and "DNS Zone Transfer Protocol
(AXFR)" [RFC5936] that clarifications may have adverse impacts on
deployed software, thus entering into a clarifications activity is
not to be taken without considerations.
There are a few deviations from the strict rule of relying on the RFC
series. First is the research into the term "resolve" and then
further additions during late reviews of this document. The
experience of these deviations illustrates the need to expand the
literature search beyond the RFC series and to include other
publications and recollections.
Lewis Expires February 7, 2020 [Page 4]
Internet-Draft RFC Origins of Domain Names August 2019
1.2. Terminology
Throughout this document (except in document quotations) the term
"Domain Names" is capitalized to emphasize the concept of the names
and "the DNS" is used to describe the protocol and algorithms
described in STD 13, including any applicable updates, related
standards track documents and experimental track documents. The
words "DNS domain names" refers to the definition of Domain Names
within the DNS (as well as, for example, "Tor domain names" referring
to the definition of Domain Names within the Tor system).
The term "domain" is a generic term, having many dictionary
definitions. There are many naming systems in existence, many
unrelated to the Internet. The use of the term Domain Names in this
document refers to a roughly-defined set of protocols defined in IETF
RFC documents and their applications' use of a somewhat common,
interoperating, naming structure. Lacking a formal, documented
definition for Domain Names, which is why this document exists, it is
hard to avoid a hand-waving reference.
2. Early RFCs
Two or three decades into the history of Domain Names, a popular
notion has taken hold that Domains Names were defined and specified
in the definition of the Domain Name System (DNS). There are two
documents that form the basic definition of the DNS, "Domain names -
concepts and facilities" [RFC1034] and "Domain names - implementation
and specification" [RFC1035] referred to as RFC 1034 and RFC 1035,
respectively. (Note that there is another pair of Request for
Comments documents with the same titles [RFC0882] [RFC0883] that
precede RFC 1034 and RFC 1035, declared obsolete in favor of the
newer documents.) Together RFC 1034 and RFC 1035 form STD 13, a full
standard cataloged by the RFC Editor. The definitions of the DNS'
version of Domain Names within RFC 1034 and RFC 1035 have become the
apparently-authoritative source for discussions on what is a Domain
Name.
The truth is, the documents comprising STD 13 do not define Domain
Names, the documents define only how Domain Names are used and
processed in the DNS. However, the way in which those RFC documents
read seem to lend to the confusion.
RFC 1034, section 2 begins with this text:
"This RFC introduces domain style names, their use for Internet mail
and host address support, and the protocols and servers used to
implement domain name facilities."
Lewis Expires February 7, 2020 [Page 5]
Internet-Draft RFC Origins of Domain Names August 2019
That text seems to indicate that RFC 1034 is the origin of Domain
Names. Immediately following is section 2.1, entitled "The history
of domain names" which includes the following text. (The text
differs from the original presentation only in wrapping of text to
fit current formatting rules.)
Continuing the quote from RFC 1034:
"The result was several ideas about name spaces and their management
[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a
common thread was the idea of a hierarchical name space, with the
hierarchy roughly corresponding to organizational structure, and
names using "." as the character to mark the boundary between
hierarchy levels. A design using a distributed database and
generalized resources was described in [RFC-882, RFC-883]. Based on
experience with several implementations, the system evolved into the
scheme described in this memo."
The only reference included in that text not otherwise mentioned in
this document is to "INTERNET NAME SERVER", identified as IEN-
116.[IEN116]
The DNS as it is known today did not invent Domain Names. Work on
the Simple Mail Transfer Protocol (SMTP) preceding work on the DNS
mentions Domain Names, and even SMTP too was not the origin of the
concept. The DNS is not even the first attempt at an Internet naming
system, see "The Domain Naming Convention for Internet User
Applications" [RFC0819] and "A Distributed System for Internet Name
Service" [RFC0830].
One important phrase to keep in mind is:
"To simplify implementations,"
which appears in both of the RFC 1034 and RFC 1035 documents, as well
as their predecessor pair RFC 882 and RFC 883. This gives credence
to the notion that Domain Names exist beyond the DNS, in that the
text following the phrase is meant to limit an existing definition or
concept as opposed to introducing a new idea.
3. Emergence of Domain Names
The first effort taken, in preparation for writing this document, was
to scan for the earliest use of the term "domain name" or "name
domain". This work is detailed in the following section, but, as
noted in private email by reviews of early versions of the document,
gave the impression that Domain Names were somehow a by-product of
the effort to develop electronic mail. To challenge the notion that
Lewis Expires February 7, 2020 [Page 6]
Internet-Draft RFC Origins of Domain Names August 2019
email begat Domain Names, a search through RFC documents for the use
of the term resolve as it applies to Domain Names was also done.
3.1. The Term "Domain Name" Itself
Domain Names emerged from the need to build a hierarchy around the
growing number of identified hosts exchanging email. "SIMPLE MAIL
TRANSFER PROTOCOL" [RFC0788], explains, in its section 3.7:
"At some not too distant future time it might be necessary to
expand the mailbox format to include a region or name domain
identifier. There is quite a bit of discussion on this at
present, and is likely that SMTP will be revised in the future to
take into account naming domains."
Knowing the origins of a concept helps setting the correct boundaries
for discussion. The past isn't meant to restrict the future but
meant to help provide a context, include forgotten ideas, and help
identify rational for scope creep.
"Internet Name Domains" [RFC0799] has (arguably) the first formation
of what is a Domain Name:
"In its most general form, a standard internet mailbox name has
the syntax
<user>.<host>@<domain> ,
where <user> is the name of a user known at the host <host> in the
name domain <domain>."
Prior to this, the term "domain" referred to principally an
administrative domain, such as the initial organizations involved in
networks at the time.
"NCP/TCP TRANSITION PLAN" [RFC0801] contains this, indicating the
passage from the host tables:
"It might be advantageous to do away with the host name table and
use a Name Server instead, or to keep a relatively small table as
a cache of recently used host names."
"Computer Mail Meeting Notes" [RFC0805] contains this:
"The conclusion in this area was that the current "user@host" mailbox
identifier should be extended to 'user@host.domain' where 'domain'
could be a hierarchy of domains."
Lewis Expires February 7, 2020 [Page 7]
Internet-Draft RFC Origins of Domain Names August 2019
"The Domain Naming Convention for Internet User Applications"
[RFC0819] contains this:
"A decision has recently been reached to
replace the simple name field, "<host>", by a composite name field,
'<domain>' "
A Domain Name began to take on its current form:
"Internet Convention: Fred@F.ISI.ARPA"
In addition, "simple name" is defined as what we now call a label,
and a "complete (fully qualified) name" is defined as "concatenation
of the simple names of the domain structure tree nodes starting with
its own name and ending with the top level node name". Noticeably
absent is a terminating dot or any mention or representation of a
root.
"The Domain Naming Convention for Internet User Applications" (RFC
819) also defines ARPA as a top-level name (as opposed to top-level
domain name). This is an early mention of the role of top-level
names. Additionally, the use of "." [RFC0020][ANSIX34] as a
separating character is mentioned.
This walk thru history relies solely on the record left behind inside
RFC documents. The precise chain of events is likely slightly
different and nuanced. The point of the exercise is to show that
Domain Names are a concept the emerged over time, spawned the DNS
with its Domain Names, a definition of host names derived from the
host tables, and was heavily influenced by SMTP as the driving
application. The definition of the FTP protocol, originally defined
in "FILE TRANSFER PROTOCOL" [RFC0959], never mentions hosts, domains
or host names. No formal definition of Domain Names has been written
and recorded.
Note: Concurrent with the writing of this document, the Domain Name
Systems Operations working group is documenting a definition for
"Domain Names". The first edition of "DNS Terminology" [RFC7719] has
a recitation of the original definition from STD 13, the successor
edition (still in preparation) has a new, further reaching
definition.
3.2. The Term "Resolve"
In looking for other early mentions of Domain Names, a look for the
use of the term "resolve" or "resolution" was conducted, reading
through early (arbitrarily defined as pre-1000) RFC documents. The
term "resolve" appears numerous times, but in many different
Lewis Expires February 7, 2020 [Page 8]
Internet-Draft RFC Origins of Domain Names August 2019
contexts. "Resolve" has many meanings, consulting a dictionary, such
as Merriam Webster's dictionary [MWDICT], none which seem to match
the use associated with domain names. For example, a committee can
resolve to solve a certain question. This use of "resolve" occurred
numerous times in early RFC documents unrelated to Domain Names.
In "Proposed Official Standard for the Format of ARPA Network
Messages" [RFC0724] the term resolve was used in the sense of mapping
an identifier into an address or something actionable. A section on
Semantics (C), Address fields (1.), General (a.), bullet 1 states:
"<path>s are used to refer to a location, on the ARPANET,
containing a stored address list. The <phrase> should
contain text which the referenced host can resolve to a
file. This standard is not a protocol and so does not
prescribe HOW data is to be retrieved from the file."
Private email to the (reachable) authors of the document pointed to
the use of "resolve" stemming from work on programming languages and
compiler theory. In that field of work, variables are associated
with machine addresses when linking code. There are formal papers
including "A Theory of Name Resolution" [TONR15] using the term and
the term resolution is used in the field of "Automated Reasoning"
[WIKIAR].
The exercise of determining how the term "resolve" came to be part of
Domain Names and DNS shows that there are influences, topics, terms
and concepts from technologies preceding Domain Name and DNS that can
be researched to help establish a foundation from which to build.
There is more work to do here.
3.3. Where Does It Start?
Without a definitive introduction to Domain Names it is hard to know
how far back in documented history to search for references to the
concept. Chasing "domain" and variations has not necessarily found
the beginning, chasing "resolution" and variations also has not
necessarily found the beginning. During later reviews of this
document, a significant early document has been identified for
inclusion, an IEN entitled "A Note On Inter-Network Naming,
Addressing, and Routing" by John F. Shoch. That document is tagged
as IEN-19 [IEN019].
The note introduces the difference between names, addresses, and
routes. The term "domain" is used to scope a name space, giving
examples from telephony and networking. But there still is no formal
definition of Domain Names nor any solution path towards Domain Names
as they are commonly known today.
Lewis Expires February 7, 2020 [Page 9]
Internet-Draft RFC Origins of Domain Names August 2019
A relatively more modern document (15 years later), entitled "On the
Naming and Binding of Network Destinations" [RFC1498], refers to IEN-
19, extending the discussion on naming to divide into four categories
of objects. This document illustrates the continuing conceptual work
covering naming as opposed to further developing the solution known
as Domain Names.
4. Dialects, So To Speak, of Domain Names
Subtypes of Domain Names have come to be defined for different
protocols, evolving and sometimes building on previous definitions.
4.1. Domain Names in the DNS
The DNS protocol defines a subset of Domain Names that referred to as
DNS domain names. The DNS places size restrictions on Domain Names
and defines rules for matching DNS domain names, treating sets of DNS
domain names as equivalent to each other. (This matching refers to
treating upper case and lowercase ASCII letters as equivalent.) The
DNS defines the format used to transmit the names across the network
as well as rules for displaying them inside text zone files. The DNS
creates the notion that names are assigned by an authority per zone.
Placing size restrictions on a DNS domain name is significant in
reducing the overall population of names that can be represented in
the DNS. The matching rules have the effect of creating (to use a
term from graph theory) cliques, distorting the tree-nature of the
Domain Name graph. A clique is a completely connected sub-graph
implying cyclic paths, a tree is a graph that is acyclic. In sum,
the treatment of ASCII (and only ASCII) cases as equivalent is a
distortion of the DNS domain name hierarchy.
The DNS defines two representational formats for DNS domain names.
One format is the "on-the-wire" format used inside messages, a flags-
and-length octet followed by some count of octets for each label with
the final length of 0 representing the root. The other format is a
version that can be rendered in printable ASCII characters, complete
with a means to represent other characters via an escape sequence.
This does not alter the Domain Name concept but has implications when
it comes to interoperating with other protocol definitions of their
domain name use.
The DNS assumes that there is, in concept, a central authority
creating names within the DNS management structure (called a zone).
Although the DNS does not define how a central authority is
implemented nor how it manages names, the names have to come from a
single point to appear in a zone. There are other means for claiming
names, an example will be mentioned later.
Lewis Expires February 7, 2020 [Page 10]
Internet-Draft RFC Origins of Domain Names August 2019
DNS domain names allows for names to appear as address literals, such
as "192.0.2.1" or "0:0:0:0:0:FFFF::192.0.2.1". But such Domain Names
are not used in the DNS for two reasons. Applications expecting a
Domain Name (as a comment line parameter as an example) could opt to
treat the string as an address literal and therefore not look for the
string in the DNS domain name space. And, if addresses were stored
using this representation, there would be no means to aggregate
managed address ranges into zones.
By reversing the order of the address components, DNS domain names
can be aggregated (as in routing) into the same zone. E.g., the
network address 192.0.2.1 would be represented by a DNS domain name
as "1.2.0.192.in-addr.arpa." as described in RFC 1035. For IPv6, the
convention used is documented in "DNS Extensions to Support IP
Version 6" [RFC3596], section 2.5.
See also "Issues in Identifier Comparison for Security Purposes"
[RFC6943] section 3.1, "Host Names", in particular, section 3.1.1 and
3.1.2 on address literals, and section 4.1, "Conflation."
DNS domain names have become the dominant definition of Domain Names
due to the success (scale) of the DNS on the public Internet. Many
protocols interact with the DNS but instead of supporting the
complete definition of DNS domain names the protocols rely on a
subset more commonly called host names.
4.2. Host Names
Work on the definition of a host name began well before the issuance
of the STD 13 documents defining the DNS. The rules for the
Preferred Syntax in RFC 1034 conform to the host name rules outlined
in "DoD Internet host table specification" [RFC0952]. The host name
definition was presented again in "Requirements for Internet Hosts --
Application and Support" [RFC1123] (which is part of STD 3). In
section 2.1 of RFC 1123, one (of two mentions) definition of host
name is presented, noting that the definition is a relaxation of what
is in RFC 952.
Host names are subsets of DNS domain names in the sense that the
character set is limited. In particular, only "let" (i.e.,
presumably letters a-z), "digits" and "hyphen" can be used, with
hyphen only internal to a label. (This description is meant to be
illustrative, not normative. See the grammar presented on page 5 of
"DoD Internet host table specification" for specifics.) "Hypertext
Transfer Protocol -- HTTP/1.0" [RFC1945], Section 3.2.2 "http URL"
specifically references section 2.1 of RFC 1123. The reference is
explicit.
Lewis Expires February 7, 2020 [Page 11]
Internet-Draft RFC Origins of Domain Names August 2019
"Simple Mail Transfer Protocol" [RFC5321] refers to RFC 1035 for a
definition of Domain Names but includes text close to what is in the
previous paragraph, noting that Domain Names as used in SMTP refer to
both hosts and to other entities. RFC 5321 updates RFC 1123, but
does not cite the latter for a definition of host names. RFC 5321
additionally requires brackets to surround address literals,
referring to the use case as an "alternative to a domain name."
See also "IAB Thoughts on Encodings for Internationalized Domain
Names" [RFC6055], particularly section 3 entitled "Use of Non-ASCII
in DNS" for more thoughts on host names.
4.3. URI Authority and Domain Names
In "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986],
also known as STD 66, mentions in its section 3.2.2 (page 20) that
the host subcomponent of the URI Authority (section 3.2) "should
conform to the DNS syntax". This comes after discussion that the
host subcomponent is not strongly tied to the DNS, i.e., names can be
managed via a concept other than the DNS. There's no discussion on
the rationale but this enables the reuse of code parsing and
marshaling the host subcomponent between different Domain Name
environments.
This reinforces the notion that there's a need to understand how
Domain Names interoperate amongst protocols and applications. And
reinforces the need to derive or make explicit a way for client
software to know how to resolve a name, that is, convert a name into
a network address.
4.4. Internet Protocol Address Literals
The above definition includes address literals such as 192.0.2.1 for
IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these
qualify as Domain Names. The addresses might be encased in square
brackets "[" and "]" (SMTP mentioned already). In the DNS, as
previously described in section 3.1, they are represented per
appropriate conventions.
4.5. Internationalized Domain Names in Applications
The original uses of Domain Names (such as DNS domain names and host
names) assumed the ASCII character set. Specifically, making the
labels case insensitive prohibited a straightforward use of any
method of representation of non-ASCII characters.
"Internationalized Domain Names for Applications (IDNA): Definitions
and Document Framework" [RFC5890], with associated other documents,
Lewis Expires February 7, 2020 [Page 12]
Internet-Draft RFC Origins of Domain Names August 2019
defines IDNA2008 as a convention for handling non-ASCII characters in
DNS domain names. In figure 1 of that document, the sets of legal
DNS domain name formats are defined. Noted in the footnotes of the
figure, applications unaware of IDNA2008 cannot distinguish the
subsets defined by the document meaning this definition is not an
alteration of Domain Names, but, like host names, yet another subset
of DNS domain names.
4.6. Restricted for DNS Registration
"Suggested Practices for Registration of Internationalized Domain
Names (IDN)" [RFC4290] presents reasons why DNS domain name
registration is restricted in the context of IDN. (That RFC refers
to a obsoleted version of IDNA but the concepts still apply.) This
is yet another convention related to DNS domain names, which excludes
names that fit the syntax but would lead to undesirable outcomes in
applications.
4.7. Tor Network Names
The Tor network is an activity organized by the Tor Project, Inc.,
described on its main web page "https://www.torproject.org/
index.html.en".
One component of the Tor network name space are Domain Names ending
in ".onion". (There are other suffixes in use, but it isn't very
clear how they are used, defined or whether they are active.)
The way in which Domain Names are used in Tor is described in two web
documents "Tor Rendezvous Specification" [RENDEV] and "Special
Hostnames in Tor" [OHOST] available from the project's website.
Syntactically, a Tor domain name fits within the DNS domain name
definition but the manner of assignment is different in a manner
incompatible with the DNS. (Not better or worse, still significantly
different.) Tor domain names are derived from cryptographic keys and
organized by distributed hash tables, instead of assigned by a
central authority per zone.
4.8. X.509
"Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile" [RFC5280], section 4.2.1.6 "Subject
Alternative Name" a dNSName is defined to be a host name, with the
further restriction that the name " " cannot be used.
Lewis Expires February 7, 2020 [Page 13]
Internet-Draft RFC Origins of Domain Names August 2019
4.9. Multicast DNS
Multicast DNS uses a name space ending with ".local." as described in
"Multicast DNS" [RFC6762]. The rules for Multicast DNS domain names
differ from DNS domain names. Multicast DNS domain names are encoded
as Net-Unicode as defined in " Unicode Format for Network
Interchange" [RFC5198] with the DNS domain name tradition of case
folding the ASCII letters when matching names. Appendix F of RFC
6762 gives an explanation of why the punycode algorithm, defined in
"Punycode: A Bootstring encoding of Unicode for Internationalized
Domain Names in Applications (IDNA)" [RFC3492], is not used.
4.10. /etc/hosts
The precursor to the DNS, host tables, still exists in remnants in
many operating systems. There are library functions, used by
applications to resolve Domain Names, that can return names of
arbitrary length (meaning, for example, longer than what DNS domain
names are defined to be).
"Basic Socket Interface Extensions for IPv6" [RFC3493], addresses
this in Section 6, further documentation can be found as part of "The
Open Group Base Specifications Issue 7" [IEEE1003] and "Microsoft
Winsock Functions" [WINSOCK].
4.11. Other Protocols
This section is used to list (some) other protocols that use Domain
Names but in general do not impose any other restrictions that what
has been mentioned above.
SSH, documented in "The Secure Shell (SSH) Protocol Architecture"
[RFC4251] uses host names, using the name when storing public keys of
hosts. SSH clients, not necessarily the protocol, illustrate how
applications juggle the different forms of Domain Names. SSH can be
invoked to open a secure shell with a host via its DNS domain name/
host name or it can be used to open a secure shell with a host via
its Multicast DNS domain name. Or, many others, including name of a
purely local, per-user scope. (Note that SSH does not distinguish
between DNS domain names and Multicast DNS domain names in the
protocol definition, the difference is handled in resolution
libraries belonging to the computing platform.)
FTP, defined in "FILE TRANSFER PROTOCOL (FTP)" [RFC0959], is silent
on Domain Names but client implementations of the protocol behave as
SSH clients, being un aware the differences between definitions of
Domain Names.
Lewis Expires February 7, 2020 [Page 14]
Internet-Draft RFC Origins of Domain Names August 2019
DHCP, defined in "Dynamic Host Configuration Protocol" [RFC2131],
includes Domain Names in many DHCP options. The use is described in
many documents, starting with "DHCP Options and BOOTP Vendor
Extensions" [RFC2132]. In "Dynamic Host Configuration Protocol
(DHCP) Domain Search Option" [RFC3397] the encoding of Domain Names
uses the on-the-wire format of DNS domain names. In "The DHCP Client
FQDN Option" [RFC4702] the same format is used. "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)" [RFC8415] contains
definitions related to DHCP designed for IPv6. The significance of
the DHCP protocols implementation of Domain Names is that, while most
other protocols represent DNS domain names or host names in a human
readable form, DHCP is using the machine-friendly format.
4.12. Other Others
If there is a use of Domain Names not listed here it is merely an
omission. The goal in this document is to provide a survey that is
sufficient to avoid hand-waving arguments, recognizing the
diminishing return building a complete roster of uses of Domain
Names.
5. Interoperability Considerations
Any single protocol can define a format for a conceptual Domain Name.
Examples given above show that many protocols have done so. From the
examples, it is clear that the way in which protocols have
interpreted Domain Names has varied, leading to, at least, user
interfaces having to have built-in intelligence when handling names
and, at worst, a growing confusion over how the Domain Name space is
to be managed.
When protocols having different formats and rules for Domain Names
interact, software implementing the protocols translate one
protocol's domain name format to another's format. Even when the
translation is straightforward, it is predictable that software will
fail to handle this situation well.
Often the clash of definitions impacts the design of a new protocol
and/or an extension of a protocol. For example, adding non-ASCII
domain names has to be done with backwards compatibility with an
installed base of ASCII-assuming code. This clash can inhibit new
uses of Domain Names.
Search lists are a Domain Name mechanism studied in "SSAC Advisory on
DNS 'Search List' Processing" [SSAC064]. (Note that the advisory's
title labels search lists as a DNS mechanism although the idea of a
search list spans many different naming schemes.) One of the
particular use cases related to this topic is the issuance of search
Lewis Expires February 7, 2020 [Page 15]
Internet-Draft RFC Origins of Domain Names August 2019
lists via DHCP and then used by any user-client protocol
implementation. This emphasizes an interoperability consideration
for how Domain Names are treated in different protocols, not just
among implementations of one protocol.
The detection and handling of Fully Qualified Domain Names is an
interoperability issue as well. At issue is the significance of the
terminating separation character in a printed version of a Domain
Name. Many clients, when passed a Domain Name as an identifier will
add a dot at the end of the argument if the argument does not already
end in a dot. [TRAILDOT1] Some do this only after applying the
aforementioned search list. As mentioned in the SSAC document in the
previous paragraph, inconsistency leads to unpredictable results.
The Special Use Domain Names registry lists Domain Names that are to
be treated in a manner inconsistent with the DNS normal processing
rules. This registry contains Domain Names regardless of whether the
name is a DNS domain name and regardless whether the name is a top-
level (domain) name or is positioned elsewhere in the tree structure.
These are reasons this document is needed. The reason for the
confusion over what's a legal domain name stems from application-
defined restrictions. For example, using a one-label domain name
("dotless") for sending email is not a problem with the DNS nor the
name in concept, but is a problem for mail implementations that
expect more than one label. (One-label names may be assumed to be in
ARPA host table format.) The "IAB Statement: Dotless Domains
Considered Harmful" [IABSTMT] elaborates.
6. IANA Considerations
None.
7. Security Considerations
Nothing direct. This document proposes a definition of the term
"Domain Name" and surveys how it has been variously applied. In some
sense, loosely defined terms give rise to security hazards. Beyond
that, there is no impact of "security."
8. Acknowledgements
Comments or contributions from Andrew Sullivan, Paul Hoffman, George
Michaelson, Kevin Darcy, Joe Abley, Jim Reid, Tony Finch, Robert
Edmonds, hellekin, Stephane Bortzmeyer, Ray Bellis, Bob Harold, Alec
Muffett, Stuart Cheshire, Dave Thaler, Niall O'Reilly, John Klensin,
Dave Crocker, Ken Pogran, John Vittal, Lixia Zhang, Ralph Droms and a
Lewis Expires February 7, 2020 [Page 16]
Internet-Draft RFC Origins of Domain Names August 2019
growing list of others I am losing track of. Not to imply
endorsement.
9. Informational References
[ANSIX34] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange, ANSI X3.4-1968", 1968.
[DNSOP] Woolf, S., "Interim DNSOP WG meeting on Special Use Names:
some reading material", 2015,
<https://mailarchive.ietf.org/arch/msg/dnsop/
VnSjuXYiwd89K_mt05-CJLa0lbs>.
[IABSTMT] Board, I. A., "IAB Statement: Dotless Domains Considered
Harmful", 2013, <https://www.iab.org/documents/
correspondence-reports-documents/2013-2/
iab-statement-dotless-domains-considered-harmful/>.
[IEEE1003]
Group, T. I. A. T. O., "The Open Group Base Specifications
Issue 7, IEEE Std 1003.1, 2013 Edition, Copyright
2001-2013 The IEEE and The Open Group", 2013,
<http://pubs.opengroup.org/onlinepubs/9699919799/
functions/freeaddrinfo.html>.
[IEN019] Shoch, J., "A note on Inter-Network Naming, Addressing,
and Routing", IEN 19, January 1973,
<https://www.rfc-editor.org/ien/ien19.txt>.
[IEN116] Postel, J., "INTERNET NAME SERVER", IEN 116, August 1979,
<https://www.rfc-editor.org/ien/ien116.txt>.
[MWDICT] Merriam-Webster, Incorporated, "Merriam-Webster's Online
Dictionary, 11th Edition (Merriam-Webster's Collegiate
Dictionary)", 2003, <https://www.merriam-webster.com/>.
[OHOST] Mathewson, N., "Special Hostnames in Tor", undated,
<https://gitweb.torproject.org/torspec.git/tree/
address-spec.txt>.
[RENDEV] Anonymous, "Tor Rendezvous Specification", undated,
<https://gitweb.torproject.org/torspec.git/tree/>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>.
Lewis Expires February 7, 2020 [Page 17]
Internet-Draft RFC Origins of Domain Names August 2019
[RFC0724] Crocker, D., Pogran, K., Vittal, J., and D. Henderson,
"Proposed official standard for the format of ARPA Network
messages", RFC 724, DOI 10.17487/RFC0724, May 1977,
<http://www.rfc-editor.org/info/rfc724>.
[RFC0788] Postel, J., "Simple Mail Transfer Protocol", RFC 788,
DOI 10.17487/RFC0788, November 1981,
<http://www.rfc-editor.org/info/rfc788>.
[RFC0799] Mills, D., "Internet name domains", RFC 799,
DOI 10.17487/RFC0799, September 1981,
<http://www.rfc-editor.org/info/rfc799>.
[RFC0801] Postel, J., "NCP/TCP transition plan", RFC 801,
DOI 10.17487/RFC0801, November 1981,
<http://www.rfc-editor.org/info/rfc801>.
[RFC0805] Postel, J., "Computer mail meeting notes", RFC 805,
DOI 10.17487/RFC0805, February 1982,
<http://www.rfc-editor.org/info/rfc805>.
[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC 819,
DOI 10.17487/RFC0819, August 1982,
<http://www.rfc-editor.org/info/rfc819>.
[RFC0830] Su, Z., "Distributed system for Internet name service",
RFC 830, DOI 10.17487/RFC0830, October 1982,
<http://www.rfc-editor.org/info/rfc830>.
[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>.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, DOI 10.17487/RFC0952,
October 1985, <http://www.rfc-editor.org/info/rfc952>.
[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>.
Lewis Expires February 7, 2020 [Page 18]
Internet-Draft RFC Origins of Domain Names August 2019
[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>.
[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>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>.
[RFC1498] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, DOI 10.17487/RFC1498, August
1993, <https://www.rfc-editor.org/info/rfc1498>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996,
<http://www.rfc-editor.org/info/rfc1945>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>.
[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>.
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration
Protocol (DHCP) Domain Search Option", RFC 3397,
DOI 10.17487/RFC3397, November 2002,
<http://www.rfc-editor.org/info/rfc3397>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<http://www.rfc-editor.org/info/rfc3492>.
Lewis Expires February 7, 2020 [Page 19]
Internet-Draft RFC Origins of Domain Names August 2019
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003,
<http://www.rfc-editor.org/info/rfc3493>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
DOI 10.17487/RFC3596, October 2003,
<http://www.rfc-editor.org/info/rfc3596>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC4290] Klensin, J., "Suggested Practices for Registration of
Internationalized Domain Names (IDN)", RFC 4290,
DOI 10.17487/RFC4290, December 2005,
<http://www.rfc-editor.org/info/rfc4290>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
Configuration Protocol (DHCP) Client Fully Qualified
Domain Name (FQDN) Option", RFC 4702,
DOI 10.17487/RFC4702, October 2006,
<http://www.rfc-editor.org/info/rfc4702>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<http://www.rfc-editor.org/info/rfc5198>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
Lewis Expires February 7, 2020 [Page 20]
Internet-Draft RFC Origins of Domain Names August 2019
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055,
DOI 10.17487/RFC6055, February 2011,
<http://www.rfc-editor.org/info/rfc6055>.
[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>.
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for
Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
2013, <http://www.rfc-editor.org/info/rfc6943>.
[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>.
[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>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[SSAC064] Anonymous, "SSAC Advisory on DNS "Search List"
Processing", 2014,
<https://www.icann.org/en/system/files/files/
sac-064-en.pdf>.
[TONR15] Wachsmuth, P. N. A. P. T. E. V. G., "A Theory of Name
Resolution", last seen 2015, <https://msdn.microsoft.com/
en-us/library/windows/desktop/ms738520(v=vs.85).aspx>.
Lewis Expires February 7, 2020 [Page 21]
Internet-Draft RFC Origins of Domain Names August 2019
[TRAILDOT1]
by), S. C. (. M., "Trailing Dots in Domain Names",
Undated,
<http://www.dns-sd.org/trailingdotsindomainnames.html>.
[WIKIAR] Anonymous, "Automated Reasoning", last edit 2016,
<https://en.wikipedia.org/wiki/Automated_reasoning>.
[WINSOCK] Microsoft, "getaddrinfo function", last seen 2017,
<https://msdn.microsoft.com/en-us/library/windows/desktop/
ms738520(v=vs.85).aspx>.
Author's Address
Edward Lewis
ICANN
Email: edward.lewis@icann.org
Lewis Expires February 7, 2020 [Page 22]
