RFC Origins of Domain NamesICANNedward.lewis@icann.orgIs 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. 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" , a document designating "onion" as a top-level domain in the Special Use Domain Names registry (see "Special Use Domain Names" ), 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 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. 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" , 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" 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" 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. 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.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" and "DNS Zone Transfer Protocol (AXFR)" 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. 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.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" and "Domain names - implementation and specification" referred to as RFC 1034 and RFC 1035, respectively. (Note that there is another pair of Request for Comments documents with the same titles 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: 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.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" and "A Distributed System for Internet Name Service" . 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. 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. Domain Names emerged from the need to build a hierarchy around the growing number of identified hosts exchanging email. "SIMPLE MAIL TRANSFER PROTOCOL" , explains, in its section 3.7: 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" has (arguably) the first formation of what is a Domain Name: 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" contains this, indicating the passage from the host tables: "Computer Mail Meeting Notes" contains this: "The Domain Naming Convention for Internet User Applications" contains this: A Domain Name began to take on its current form: 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 "." 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" , 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" has a recitation of the original definition from STD 13, the successor edition (still in preparation) has a new, further reaching definition.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 contexts. "Resolve" has many meanings, consulting a dictionary, such as Merriam Webster's dictionary , 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" 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: 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" using the term and the term resolution is used in the field of "Automated Reasoning" . 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.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 .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.A relatively more modern document (15 years later), entitled "On the Naming and Binding of Network Destinations" , 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.Subtypes of Domain Names have come to be defined for different protocols, evolving and sometimes building on previous definitions. 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. 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" , section 2.5. See also "Issues in Identifier Comparison for Security Purposes" 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. 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" . The host name definition was presented again in "Requirements for Internet Hosts -- Application and Support" (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" , Section 3.2.2 "http URL" specifically references section 2.1 of RFC 1123. The reference is explicit. "Simple Mail Transfer Protocol" 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" , particularly section 3 entitled "Use of Non-ASCII in DNS" for more thoughts on host names. In "Uniform Resource Identifier (URI): Generic Syntax" , 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. 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. 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" , 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. "Suggested Practices for Registration of Internationalized Domain Names (IDN)" 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.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" and "Special Hostnames in Tor" 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. "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" , 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.Multicast DNS uses a name space ending with ".local." as described in "Multicast DNS" . 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" 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)" , is not used. 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" , addresses this in Section 6, further documentation can be found as part of "The Open Group Base Specifications Issue 7" and "Microsoft Winsock Functions" . 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" 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)" , 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" , includes Domain Names in many DHCP options. The use is described in many documents, starting with "DHCP Options and BOOTP Vendor Extensions" . In "Dynamic Host Configuration Protocol (DHCP) Domain Search Option" the encoding of Domain Names uses the on-the-wire format of DNS domain names. In "The DHCP Client FQDN Option" the same format is used. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 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. 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. 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" . (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 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. 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" elaborates. None. 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." 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 growing list of others I am losing track of. Not to imply endorsement. A note on Inter-Network Naming, Addressing, and RoutingINTERNET NAME SERVERASCII format for network interchangeProposed official standard for the format of ARPA Network messagesSimple Mail Transfer ProtocolInternet name domainsNCP/TCP transition planThis RFC discusses the conversion of hosts from NCP to TCP. And making available the principle services: Telnet, File Transfer, and Mail. These protocols allow all hosts in the ARPA community to share a common interprocess communication environment.Computer mail meeting notesThis RFC consists of notes from a meeting that was held at USC Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail. The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further strutured.The Domain Naming Convention for Internet User ApplicationsThis RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.Distributed system for Internet name serviceThis RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.Domain names: Concepts and facilitiesThis RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities.Domain names: Implementation specificationThis RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.DoD Internet host table specificationThis RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date.File Transfer ProtocolThis memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition.Domain names - concepts and facilitiesThis RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.Domain names - implementation and specificationThis RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.Requirements for Internet Hosts - Application and SupportThis RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]On the Naming and Binding of Network DestinationsThis brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas: First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. This memo provides information for the Internet community. It does not specify an Internet standard.Hypertext Transfer Protocol -- HTTP/1.0The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.Dynamic Host Configuration ProtocolThe Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]DHCP Options and BOOTP Vendor ExtensionsThis document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers AuthorityThis document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community.Dynamic Host Configuration Protocol (DHCP) Domain Search OptionPunycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]Basic Socket Interface Extensions for IPv6The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community.DNS Extensions to Support IP Version 6This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]Uniform Resource Identifier (URI): Generic SyntaxA Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]The Secure Shell (SSH) Protocol ArchitectureThe Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK]Suggested Practices for Registration of Internationalized Domain Names (IDN)This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names. This memo provides information for the Internet community.The Role of Wildcards in the Domain Name SystemThis is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK] The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) OptionThis document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. [STANDARDS-TRACK]Unicode Format for Network InterchangeThe Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]Simple Mail Transfer ProtocolThis document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]Internationalized Domain Names for Applications (IDNA): Definitions and Document FrameworkThis document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]DNS Zone Transfer Protocol (AXFR)The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK] IAB Thoughts on Encodings for Internationalized Domain NamesThis document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.Special-Use Domain NamesThis document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.Multicast DNSAs networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.Issues in Identifier Comparison for Security PurposesIdentifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.The ".onion" Special-Use Domain NameThis document registers the ".onion" Special-Use Domain Name.DNS TerminologyThe DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.Dynamic Host Configuration Protocol for IPv6 (DHCPv6)This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.Merriam-Webster's Online Dictionary, 11th Edition (Merriam-Webster's Collegiate Dictionary) Merriam-Webster, Incorporated USA Code for Information Interchange, ANSI X3.4-1968 American National Standards Institute (formerly United States of America Standards Institute) Interim DNSOP WG meeting on Special Use Names: some reading material
Tor Rendezvous Specification Special Hostnames in Tor IAB Statement: Dotless Domains Considered Harmful The Open Group Base Specifications Issue 7, IEEE Std 1003.1, 2013 Edition, Copyright 2001-2013 The IEEE and The Open Group getaddrinfo function A Theory of Name Resolution 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. Automated Reasoning Wikipedia SSAC Advisory on DNS "Search List" Processing ICANN Security and Stability Advisory Committee Trailing Dots in Domain Names