Network Working Group E. Lewis
Internet-Draft ICANN
Intended status: Informational February 1, 2018
Expires: August 5, 2018

Domain Names, A Case for Clarifying


Is the concept of Domain Names owned by the DNS protocol or does the DNS protocol exist to support the Domain Names concept? 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 runthe protocol. This document looks first at the early record in the RFC series and then expands to survey how Domain Names are used in protocols and reaches the conclusion that Domain Names are independent of the DNS, and further, that there might be a need to clarify the definition of Domain Names to reinforce that notion.

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

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 August 5, 2018.

Copyright Notice

Copyright (c) 2018 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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Which came first, the concept of Domain Names or the protocol called 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 Names and DNS had become intertwined to the point over time to the point that what is essentially a case of permission-less innovation led to a contentious discussion on the IETF's DNS Operations working group mail list.

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.

To help establish a way forward, a look backward is needed. A document search, sticking to RFC documents, reveals evidence of discussions on domains 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 cconcept 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 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 in the document survey is a definitive foundation for Domain Names. There are abstract descriptions of the concept that come close to being 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.

This document settles being a literature search covering the RFC series and comes to making a case for clarications to be made. There are obvious continuations to this work, such as the earlier Internet Engineering Notes, other published works, and interviews with participants in the early days. That will be conducted as follow on work to this document.

1.1. Goal

To establish a solid foundation accommodating an installed based 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 is one deviation from the strict rules of relying on the RFC series which has been included, that is the section on determining the origin of the term "resolve" in the context of Domain Names and the DNS. This work is interesting and adds to the larger picture of what needs to be done. The experience of that side route illustrates the need to expand the literature search beyond the RFC series and to include other publications and recollections.

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, those were 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 DNS domain names within RFC 1034 and RFC 1035 have become the apparently-authoritative source for discussions on what is a Domain Name.

Throughout this document the term "Domain Names" is capitalized to emphasize the concept of the names and 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 term "domain" is a generic term, there are many naming systems in existence. The use of the term Domain Names in this document refers to the roughly-defined set of protocols and their applications' use of a naming structure that is prevalent amongst many protocols defined in IETF RFC documents.

The truth is, STD 13 does not define Domain Names, the documents define only how Domain Names are used and processed in the DNS. However, the way in which the 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."

Which 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.)

"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 mentioened in this document is IEN-116. The reference for that is defined as:"

"[IEN-116]  J. Postel, "Internet Name Server", IEN-116,
            USC/Information Sciences Institute, August 1979.

            A name service obsoleted by the Domain Name System, but
            still in use."

The DNS as it is known today did not invent Domain Names. Work on the Simple Mail Transfer Protocol preceding the DNS mentions domain names, and even it 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 RFC 1034 and RFC 1035 as well as their predecessors RFC 882 and RFC 883. This gives credence to the notion that Domain Names exist beyond the DNS.

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 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, 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."

"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. But 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"

As much as Domain Names were influenced by SMTP, electronic mail was not the origin of the Domain Names concepts, this was a hypothesis came from a personal view of the early days of Internet work. To test this, a look for the use of the term "resolve" or "resolution" was conducted in early (arbitrarily defined as pre-1000) RFC documents.

The term "resolve" appears numerous times, but in many different 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 tthat there are influences, topics, terms and concepts from technologies preceeding Domain Name and DNS that can be researched to help establish a foundation from which to build. There is more work to do here.

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 as Restricted for DNS

The DNS protocol places size restrictions on Domain Names and defines rules for matching domain names, treating sets of Domain Names as equivalent to each other. (This matching refers to treating upper case and lower case 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 Domain Names 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 Domain Name hierarchy.

DNS defines two formats for domain names. One 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 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.

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

DNS domain names could appear to be the same as address literals, such as "" or "0:0:0:0:0:FFFF::". Such DNS domain names are not used for two reasons. Applications expecting a Domain Name (as a comment line parameter as an example) would opt to treat the string as an address literal and would therefore not look for the string in the DNS domain name space. The management model of the DNS would prefer to aggregate (as in routing) addresses belonging together in the same zone, resulting in labels appearing in reverse order. E.g., the network address would be represented by a DNS domain name as "" 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 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 RFC 952 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.

"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 marshalling 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 for IPv4 and even IPv6 literals such as ::ffff: Yes, these might 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, 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 an older form than IDNA2008, but the concepts still apply.) This is yet another convention related to DNS domain names, excluding names that would lead to undesirable outcomes.

4.7. Tor Network Names

The Tor network is an activity organized by the Tor Project, Inc., described on its main web page "".

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 "Subject Alternative Name" a dNSName is defined to be a host name, with the further restriction that the name " " cannot be used. (The subtle irony is that a name consisting of just a blank would hardly qualify as a Domain Name.)

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 DNS, host tables, still exists in remnants in many operating systems. There are library functions, used by applications to resolve DNS 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 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.

DHCP, defined in "Dynamic Host Configuration Protocol" [RFC2131], includes domain names in its Domain Search Option as described in "Dynamic Host Configuration Protocol (DHCP) Domain Search Option" [RFC3397]. The encoding of Domain Names used is the on-the-wire format of the DNS, using DNS-defined message compression. DHCP handles Domain Names in other options, such as defined in "The DHCP Client FQDN Option" [RFC4702], in the same format. The significance of this is that 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 in trying to build a complete roster of uses of Domain Names. If there are omissions that ought to be included, please send references for the use case to the author (while this is an Internet Draft, that is).

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]. One of the particular use cases related to this topic is the issuance of search 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 surprising 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. 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 and a growing list of others I am losing track of. Not to imply endorsement.

7. IANA Considerations


8. 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."

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.
[IABSTMT] "IAB Statement: Dotless Domains Considered Harmful", 2013.
[IEEE1003] "The Open Group Base Specifications Issue 7, IEEE Std 1003.1, 2013 Edition, Copyright 2001-2013 The IEEE and The Open Group", 2013.
[MWDICT] Merriam-Webster, Incorporated, "Merriam-Webster's Online Dictionary, 11th Edition (Merriam-Webster's Collegiate Dictionary)", 2003.
[OHOST] "Special Hostnames in Tor", undated.
[RENDEV] "Tor Rendezvous Specification", undated.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969.
[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.
[RFC0788] Postel, J., "Simple Mail Transfer Protocol", RFC 788, DOI 10.17487/RFC0788, November 1981.
[RFC0799] Mills, D., "Internet name domains", RFC 799, DOI 10.17487/RFC0799, September 1981.
[RFC0801] Postel, J., "NCP/TCP transition plan", RFC 801, DOI 10.17487/RFC0801, November 1981.
[RFC0805] Postel, J., "Computer mail meeting notes", RFC 805, DOI 10.17487/RFC0805, February 1982.
[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC 819, DOI 10.17487/RFC0819, August 1982.
[RFC0830] Su, Z., "Distributed system for Internet name service", RFC 830, DOI 10.17487/RFC0830, October 1982.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983.
[RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983.
[RFC0952] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host table specification", RFC 952, DOI 10.17487/RFC0952, October 1985.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989.
[RFC1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/RFC1945, May 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997.
[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.
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, DOI 10.17487/RFC3397, November 2002.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003.
[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.
[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.
[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.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006.
[RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, DOI 10.17487/RFC4290, December 2005.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006.
[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.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008.
[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.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010.
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010.
[RFC6055] Thaler, D., Klensin, J. and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, DOI 10.17487/RFC6055, February 2011.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013.
[RFC6943] Thaler, D., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015.
[RFC7719] Hoffman, P., Sullivan, A. and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015.
[SSAC064] ICANN Security and Stability Advisory Committee, "SSAC Advisory on DNS "Search List" Processing", 2014.
[TONR15] Programming Languages and Systems - 24th European Symposium on Programming, ESOP 2015, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2015, London, UK, April 11-18, 2015, Proceedings. Lecture Notes in Computer Science, Springer, April 2015., "A Theory of Name Resolution", last seen 2015.
[TRAILDOT1] "Trailing Dots in Domain Names", Undated.
[WIKIAR] Wikipedia, "Automated Reasoning", last edit 2016.
[WINSOCK] "getaddrinfo function", last seen 2017.

Author's Address

Edward Lewis ICANN EMail: