idnits 2.17.1 draft-lewis-domain-names-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 392 has weird spacing: '...on, on the ...' == Line 393 has weird spacing: '...taining a st...' == Line 394 has weird spacing: '...ed host can ...' == Line 395 has weird spacing: '... This stand...' == Line 396 has weird spacing: '...OW data is t...' -- The document date (August 6, 2019) is 1725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEN-116' is mentioned on line 247, but not defined == Missing Reference: 'RFC-799' is mentioned on line 247, but not defined == Missing Reference: 'RFC-819' is mentioned on line 247, but not defined == Missing Reference: 'RFC-830' is mentioned on line 247, but not defined == Missing Reference: 'RFC-882' is mentioned on line 252, but not defined ** Obsolete undefined reference: RFC 882 (Obsoleted by RFC 1034, RFC 1035) == Missing Reference: 'RFC-883' is mentioned on line 252, but not defined ** Obsolete undefined reference: RFC 883 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 724 (Obsoleted by RFC 733) -- Obsolete informational reference (is this intentional?): RFC 788 (Obsoleted by RFC 821, RFC 974, RFC 1869, RFC 1870) -- Obsolete informational reference (is this intentional?): RFC 882 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 883 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lewis 3 Internet-Draft ICANN 4 Intended status: Informational August 6, 2019 5 Expires: February 7, 2020 7 RFC Origins of Domain Names 8 draft-lewis-domain-names-13 10 Abstract 12 Is the concept of Domain Names owned by the DNS protocol or does the 13 DNS protocol exist to support the concept of Domain Names? This 14 question has become pertinent in light of proposals to use Domain 15 Names in protocols in ways incompatible with the DNS protocol and the 16 operational environment built to run the protocol. 18 This document is intended to help answer this question by presenting 19 a look into the recorded history of relevant Requests for Comments. 20 This document comprises the research and views of the author and has 21 benefited from review and input from many IETF experts, but it does 22 not represent the consensus opinion of the IETF. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 7, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Early RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Emergence of Domain Names . . . . . . . . . . . . . . . . . . 6 63 3.1. The Term "Domain Name" Itself . . . . . . . . . . . . . . 7 64 3.2. The Term "Resolve" . . . . . . . . . . . . . . . . . . . 8 65 3.3. Where Does It Start? . . . . . . . . . . . . . . . . . . 9 66 4. Dialects, So To Speak, of Domain Names . . . . . . . . . . . 10 67 4.1. Domain Names in the DNS . . . . . . . . . . . . . . . . . 10 68 4.2. Host Names . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.3. URI Authority and Domain Names . . . . . . . . . . . . . 12 70 4.4. Internet Protocol Address Literals . . . . . . . . . . . 12 71 4.5. Internationalized Domain Names in Applications . . . . . 12 72 4.6. Restricted for DNS Registration . . . . . . . . . . . . . 13 73 4.7. Tor Network Names . . . . . . . . . . . . . . . . . . . . 13 74 4.8. X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.9. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 14 76 4.10. /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.11. Other Protocols . . . . . . . . . . . . . . . . . . . . . 14 78 4.12. Other Others . . . . . . . . . . . . . . . . . . . . . . 15 79 5. Interoperability Considerations . . . . . . . . . . . . . . . 15 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 83 9. Informational References . . . . . . . . . . . . . . . . . . 17 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 Which came first, the concept of Domain Names or the DNS? This 89 question is at the heart of whether or how Domain Names are put to 90 use in ways avoiding the DNS protocol. 92 The discussion leading to "The '.onion' Special-Use Domain Name" 93 [RFC7686], a document designating "onion" as a top-level domain in 94 the Special Use Domain Names registry (see "Special Use Domain Names" 95 [RFC6761]), opened the question of how to treat Domain Names that 96 were designed to be used external to the DNS. The history of Domain 97 Names and the DNS had become intertwined over time to the point that 98 what is essentially a case of permission-less innovation led to 99 contentious discussions on the IETF's DNS Operations (DNSOP) working 100 group mail list and an interim meeting of the DNSOP working 101 group[DNSOP]. 103 A portion of the discussion centered around a seeming conflict among 104 processes to register Domain Names, such as the process launched from 105 "Memorandum of Understanding Concerning the Technical Work of the 106 Internet Assigned Numbers Authority" [RFC2860], for registering a 107 name in the global, public DNS and the process for registering a name 108 in the Special Use Domain Names registry. The latter process is 109 documented in "Special Use Domain Names" cited in the previous 110 paragraph. 112 To help establish a way forward, a look backward is thought to be a 113 good start. A document search, sticking to RFC documents, reveals 114 evidence of discussions on Domain Names prior to the DNS, with the 115 DNS protocol's base documents indicating that the DNS is based on 116 some simplifying assumptions, implying there is a larger concept in 117 play. 119 To help bolster the idea that Domain Names came first, a look at how 120 other protocols have treated identifying names, how Domain Names are 121 put to use, how what a name is further restricted for the protocol's 122 needs. From this it has become apparent that the concept of Domain 123 Names has drifted over time, which leads to some uncertainty when it 124 comes to looking forward. 126 During reviews of this document, documented studies of other 127 difficulties resulting from the uncertainty have surfaced. "IAB 128 Thoughts on Encodings for Internationalized Domain Names" [RFC6055] 129 documents issues related to converting human-readable forms of Domain 130 Names in forms useful to automated applications when there is no 131 clear architecture or precise definition of how to handle Domain 132 Names. "Issues in Identifier Comparison for Security Purposes" 133 [RFC6943] documents issues related to the same conversion as related 134 to evaluating security policies. The presence of these studies 135 suggests a need to examine the architecture of naming and 136 identifiers. 138 The most glaring omission discovered by the document survey is a 139 definitive foundation for Domain Names. There are abstract 140 descriptions of the concept that come close to qualifying as a 141 definition. The descriptions though are too loose to be something 142 that can be tested objectively, frustrating discussions when it comes 143 to innovations in the use of Domain Names. 145 In reviews of this document, an important thought has been expressed. 146 During the era when the early RFC documents were prepared, many 147 considerations now deemed important were not considered, discussed, 148 examined. This lack of attention should be taken simply as the the 149 limits of the problem space perceived at the time and not as an 150 intentional non-statement about questions now under consideration. 151 The fact that the history is presented here does not imply that 152 history will contain the answers and guide the way forward, the 153 history as presented is only a starting point. 155 This document is a literature search covering the RFC series and 156 makes a case for clarifications to be made. There are obvious 157 continuations to this work, such as the earlier Internet Engineering 158 Notes series (IEN), other published works, and interviews with 159 participants from the early days. This document is intended to help 160 answer this question of whether the concept of Domain Names is owned 161 by the DNS protocol or does the DNS protocol exist to support the 162 concept of Domain Names. It does this by presenting a look into the 163 recorded history of relevant Requests for Comments. This document 164 comprises the research and views of the author and has benefited from 165 review and input from many IETF experts, but it does not represent 166 the consensus opinion of the IETF. 168 1.1. Goal 170 To establish a solid foundation accommodating an installed base and 171 permission-less innovation, having a clear definition of Domain Names 172 would be great. This document, however, does not attempt to achieve 173 a definition. This document's goal has settled into compiling a 174 narrative on the history, within perhaps artificial bounds (the RFC 175 series), and declaring that there is a need to clarify Domain Names. 177 In this document are criteria for performing a clarification, 178 recognizing from experience in preparing "The Role of Wildcards in 179 the Domain Name System" [RFC4592] and "DNS Zone Transfer Protocol 180 (AXFR)" [RFC5936] that clarifications may have adverse impacts on 181 deployed software, thus entering into a clarifications activity is 182 not to be taken without considerations. 184 There are a few deviations from the strict rule of relying on the RFC 185 series. First is the research into the term "resolve" and then 186 further additions during late reviews of this document. The 187 experience of these deviations illustrates the need to expand the 188 literature search beyond the RFC series and to include other 189 publications and recollections. 191 1.2. Terminology 193 Throughout this document (except in document quotations) the term 194 "Domain Names" is capitalized to emphasize the concept of the names 195 and "the DNS" is used to describe the protocol and algorithms 196 described in STD 13, including any applicable updates, related 197 standards track documents and experimental track documents. The 198 words "DNS domain names" refers to the definition of Domain Names 199 within the DNS (as well as, for example, "Tor domain names" referring 200 to the definition of Domain Names within the Tor system). 202 The term "domain" is a generic term, having many dictionary 203 definitions. There are many naming systems in existence, many 204 unrelated to the Internet. The use of the term Domain Names in this 205 document refers to a roughly-defined set of protocols defined in IETF 206 RFC documents and their applications' use of a somewhat common, 207 interoperating, naming structure. Lacking a formal, documented 208 definition for Domain Names, which is why this document exists, it is 209 hard to avoid a hand-waving reference. 211 2. Early RFCs 213 Two or three decades into the history of Domain Names, a popular 214 notion has taken hold that Domains Names were defined and specified 215 in the definition of the Domain Name System (DNS). There are two 216 documents that form the basic definition of the DNS, "Domain names - 217 concepts and facilities" [RFC1034] and "Domain names - implementation 218 and specification" [RFC1035] referred to as RFC 1034 and RFC 1035, 219 respectively. (Note that there is another pair of Request for 220 Comments documents with the same titles [RFC0882] [RFC0883] that 221 precede RFC 1034 and RFC 1035, declared obsolete in favor of the 222 newer documents.) Together RFC 1034 and RFC 1035 form STD 13, a full 223 standard cataloged by the RFC Editor. The definitions of the DNS' 224 version of Domain Names within RFC 1034 and RFC 1035 have become the 225 apparently-authoritative source for discussions on what is a Domain 226 Name. 228 The truth is, the documents comprising STD 13 do not define Domain 229 Names, the documents define only how Domain Names are used and 230 processed in the DNS. However, the way in which those RFC documents 231 read seem to lend to the confusion. 233 RFC 1034, section 2 begins with this text: 235 "This RFC introduces domain style names, their use for Internet mail 236 and host address support, and the protocols and servers used to 237 implement domain name facilities." 238 That text seems to indicate that RFC 1034 is the origin of Domain 239 Names. Immediately following is section 2.1, entitled "The history 240 of domain names" which includes the following text. (The text 241 differs from the original presentation only in wrapping of text to 242 fit current formatting rules.) 244 Continuing the quote from RFC 1034: 246 "The result was several ideas about name spaces and their management 247 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a 248 common thread was the idea of a hierarchical name space, with the 249 hierarchy roughly corresponding to organizational structure, and 250 names using "." as the character to mark the boundary between 251 hierarchy levels. A design using a distributed database and 252 generalized resources was described in [RFC-882, RFC-883]. Based on 253 experience with several implementations, the system evolved into the 254 scheme described in this memo." 256 The only reference included in that text not otherwise mentioned in 257 this document is to "INTERNET NAME SERVER", identified as IEN- 258 116.[IEN116] 260 The DNS as it is known today did not invent Domain Names. Work on 261 the Simple Mail Transfer Protocol (SMTP) preceding work on the DNS 262 mentions Domain Names, and even SMTP too was not the origin of the 263 concept. The DNS is not even the first attempt at an Internet naming 264 system, see "The Domain Naming Convention for Internet User 265 Applications" [RFC0819] and "A Distributed System for Internet Name 266 Service" [RFC0830]. 268 One important phrase to keep in mind is: 270 "To simplify implementations," 272 which appears in both of the RFC 1034 and RFC 1035 documents, as well 273 as their predecessor pair RFC 882 and RFC 883. This gives credence 274 to the notion that Domain Names exist beyond the DNS, in that the 275 text following the phrase is meant to limit an existing definition or 276 concept as opposed to introducing a new idea. 278 3. Emergence of Domain Names 280 The first effort taken, in preparation for writing this document, was 281 to scan for the earliest use of the term "domain name" or "name 282 domain". This work is detailed in the following section, but, as 283 noted in private email by reviews of early versions of the document, 284 gave the impression that Domain Names were somehow a by-product of 285 the effort to develop electronic mail. To challenge the notion that 286 email begat Domain Names, a search through RFC documents for the use 287 of the term resolve as it applies to Domain Names was also done. 289 3.1. The Term "Domain Name" Itself 291 Domain Names emerged from the need to build a hierarchy around the 292 growing number of identified hosts exchanging email. "SIMPLE MAIL 293 TRANSFER PROTOCOL" [RFC0788], explains, in its section 3.7: 295 "At some not too distant future time it might be necessary to 296 expand the mailbox format to include a region or name domain 297 identifier. There is quite a bit of discussion on this at 298 present, and is likely that SMTP will be revised in the future to 299 take into account naming domains." 301 Knowing the origins of a concept helps setting the correct boundaries 302 for discussion. The past isn't meant to restrict the future but 303 meant to help provide a context, include forgotten ideas, and help 304 identify rational for scope creep. 306 "Internet Name Domains" [RFC0799] has (arguably) the first formation 307 of what is a Domain Name: 309 "In its most general form, a standard internet mailbox name has 310 the syntax 312 .@ , 314 where is the name of a user known at the host in the 315 name domain ." 317 Prior to this, the term "domain" referred to principally an 318 administrative domain, such as the initial organizations involved in 319 networks at the time. 321 "NCP/TCP TRANSITION PLAN" [RFC0801] contains this, indicating the 322 passage from the host tables: 324 "It might be advantageous to do away with the host name table and 325 use a Name Server instead, or to keep a relatively small table as 326 a cache of recently used host names." 328 "Computer Mail Meeting Notes" [RFC0805] contains this: 330 "The conclusion in this area was that the current "user@host" mailbox 331 identifier should be extended to 'user@host.domain' where 'domain' 332 could be a hierarchy of domains." 333 "The Domain Naming Convention for Internet User Applications" 334 [RFC0819] contains this: 336 "A decision has recently been reached to 337 replace the simple name field, "", by a composite name field, 338 '' " 340 A Domain Name began to take on its current form: 342 "Internet Convention: Fred@F.ISI.ARPA" 344 In addition, "simple name" is defined as what we now call a label, 345 and a "complete (fully qualified) name" is defined as "concatenation 346 of the simple names of the domain structure tree nodes starting with 347 its own name and ending with the top level node name". Noticeably 348 absent is a terminating dot or any mention or representation of a 349 root. 351 "The Domain Naming Convention for Internet User Applications" (RFC 352 819) also defines ARPA as a top-level name (as opposed to top-level 353 domain name). This is an early mention of the role of top-level 354 names. Additionally, the use of "." [RFC0020][ANSIX34] as a 355 separating character is mentioned. 357 This walk thru history relies solely on the record left behind inside 358 RFC documents. The precise chain of events is likely slightly 359 different and nuanced. The point of the exercise is to show that 360 Domain Names are a concept the emerged over time, spawned the DNS 361 with its Domain Names, a definition of host names derived from the 362 host tables, and was heavily influenced by SMTP as the driving 363 application. The definition of the FTP protocol, originally defined 364 in "FILE TRANSFER PROTOCOL" [RFC0959], never mentions hosts, domains 365 or host names. No formal definition of Domain Names has been written 366 and recorded. 368 Note: Concurrent with the writing of this document, the Domain Name 369 Systems Operations working group is documenting a definition for 370 "Domain Names". The first edition of "DNS Terminology" [RFC7719] has 371 a recitation of the original definition from STD 13, the successor 372 edition (still in preparation) has a new, further reaching 373 definition. 375 3.2. The Term "Resolve" 377 In looking for other early mentions of Domain Names, a look for the 378 use of the term "resolve" or "resolution" was conducted, reading 379 through early (arbitrarily defined as pre-1000) RFC documents. The 380 term "resolve" appears numerous times, but in many different 381 contexts. "Resolve" has many meanings, consulting a dictionary, such 382 as Merriam Webster's dictionary [MWDICT], none which seem to match 383 the use associated with domain names. For example, a committee can 384 resolve to solve a certain question. This use of "resolve" occurred 385 numerous times in early RFC documents unrelated to Domain Names. 387 In "Proposed Official Standard for the Format of ARPA Network 388 Messages" [RFC0724] the term resolve was used in the sense of mapping 389 an identifier into an address or something actionable. A section on 390 Semantics (C), Address fields (1.), General (a.), bullet 1 states: 392 "s are used to refer to a location, on the ARPANET, 393 containing a stored address list. The should 394 contain text which the referenced host can resolve to a 395 file. This standard is not a protocol and so does not 396 prescribe HOW data is to be retrieved from the file." 398 Private email to the (reachable) authors of the document pointed to 399 the use of "resolve" stemming from work on programming languages and 400 compiler theory. In that field of work, variables are associated 401 with machine addresses when linking code. There are formal papers 402 including "A Theory of Name Resolution" [TONR15] using the term and 403 the term resolution is used in the field of "Automated Reasoning" 404 [WIKIAR]. 406 The exercise of determining how the term "resolve" came to be part of 407 Domain Names and DNS shows that there are influences, topics, terms 408 and concepts from technologies preceding Domain Name and DNS that can 409 be researched to help establish a foundation from which to build. 410 There is more work to do here. 412 3.3. Where Does It Start? 414 Without a definitive introduction to Domain Names it is hard to know 415 how far back in documented history to search for references to the 416 concept. Chasing "domain" and variations has not necessarily found 417 the beginning, chasing "resolution" and variations also has not 418 necessarily found the beginning. During later reviews of this 419 document, a significant early document has been identified for 420 inclusion, an IEN entitled "A Note On Inter-Network Naming, 421 Addressing, and Routing" by John F. Shoch. That document is tagged 422 as IEN-19 [IEN019]. 424 The note introduces the difference between names, addresses, and 425 routes. The term "domain" is used to scope a name space, giving 426 examples from telephony and networking. But there still is no formal 427 definition of Domain Names nor any solution path towards Domain Names 428 as they are commonly known today. 430 A relatively more modern document (15 years later), entitled "On the 431 Naming and Binding of Network Destinations" [RFC1498], refers to IEN- 432 19, extending the discussion on naming to divide into four categories 433 of objects. This document illustrates the continuing conceptual work 434 covering naming as opposed to further developing the solution known 435 as Domain Names. 437 4. Dialects, So To Speak, of Domain Names 439 Subtypes of Domain Names have come to be defined for different 440 protocols, evolving and sometimes building on previous definitions. 442 4.1. Domain Names in the DNS 444 The DNS protocol defines a subset of Domain Names that referred to as 445 DNS domain names. The DNS places size restrictions on Domain Names 446 and defines rules for matching DNS domain names, treating sets of DNS 447 domain names as equivalent to each other. (This matching refers to 448 treating upper case and lowercase ASCII letters as equivalent.) The 449 DNS defines the format used to transmit the names across the network 450 as well as rules for displaying them inside text zone files. The DNS 451 creates the notion that names are assigned by an authority per zone. 453 Placing size restrictions on a DNS domain name is significant in 454 reducing the overall population of names that can be represented in 455 the DNS. The matching rules have the effect of creating (to use a 456 term from graph theory) cliques, distorting the tree-nature of the 457 Domain Name graph. A clique is a completely connected sub-graph 458 implying cyclic paths, a tree is a graph that is acyclic. In sum, 459 the treatment of ASCII (and only ASCII) cases as equivalent is a 460 distortion of the DNS domain name hierarchy. 462 The DNS defines two representational formats for DNS domain names. 463 One format is the "on-the-wire" format used inside messages, a flags- 464 and-length octet followed by some count of octets for each label with 465 the final length of 0 representing the root. The other format is a 466 version that can be rendered in printable ASCII characters, complete 467 with a means to represent other characters via an escape sequence. 468 This does not alter the Domain Name concept but has implications when 469 it comes to interoperating with other protocol definitions of their 470 domain name use. 472 The DNS assumes that there is, in concept, a central authority 473 creating names within the DNS management structure (called a zone). 474 Although the DNS does not define how a central authority is 475 implemented nor how it manages names, the names have to come from a 476 single point to appear in a zone. There are other means for claiming 477 names, an example will be mentioned later. 479 DNS domain names allows for names to appear as address literals, such 480 as "192.0.2.1" or "0:0:0:0:0:FFFF::192.0.2.1". But such Domain Names 481 are not used in the DNS for two reasons. Applications expecting a 482 Domain Name (as a comment line parameter as an example) could opt to 483 treat the string as an address literal and therefore not look for the 484 string in the DNS domain name space. And, if addresses were stored 485 using this representation, there would be no means to aggregate 486 managed address ranges into zones. 488 By reversing the order of the address components, DNS domain names 489 can be aggregated (as in routing) into the same zone. E.g., the 490 network address 192.0.2.1 would be represented by a DNS domain name 491 as "1.2.0.192.in-addr.arpa." as described in RFC 1035. For IPv6, the 492 convention used is documented in "DNS Extensions to Support IP 493 Version 6" [RFC3596], section 2.5. 495 See also "Issues in Identifier Comparison for Security Purposes" 496 [RFC6943] section 3.1, "Host Names", in particular, section 3.1.1 and 497 3.1.2 on address literals, and section 4.1, "Conflation." 499 DNS domain names have become the dominant definition of Domain Names 500 due to the success (scale) of the DNS on the public Internet. Many 501 protocols interact with the DNS but instead of supporting the 502 complete definition of DNS domain names the protocols rely on a 503 subset more commonly called host names. 505 4.2. Host Names 507 Work on the definition of a host name began well before the issuance 508 of the STD 13 documents defining the DNS. The rules for the 509 Preferred Syntax in RFC 1034 conform to the host name rules outlined 510 in "DoD Internet host table specification" [RFC0952]. The host name 511 definition was presented again in "Requirements for Internet Hosts -- 512 Application and Support" [RFC1123] (which is part of STD 3). In 513 section 2.1 of RFC 1123, one (of two mentions) definition of host 514 name is presented, noting that the definition is a relaxation of what 515 is in RFC 952. 517 Host names are subsets of DNS domain names in the sense that the 518 character set is limited. In particular, only "let" (i.e., 519 presumably letters a-z), "digits" and "hyphen" can be used, with 520 hyphen only internal to a label. (This description is meant to be 521 illustrative, not normative. See the grammar presented on page 5 of 522 "DoD Internet host table specification" for specifics.) "Hypertext 523 Transfer Protocol -- HTTP/1.0" [RFC1945], Section 3.2.2 "http URL" 524 specifically references section 2.1 of RFC 1123. The reference is 525 explicit. 527 "Simple Mail Transfer Protocol" [RFC5321] refers to RFC 1035 for a 528 definition of Domain Names but includes text close to what is in the 529 previous paragraph, noting that Domain Names as used in SMTP refer to 530 both hosts and to other entities. RFC 5321 updates RFC 1123, but 531 does not cite the latter for a definition of host names. RFC 5321 532 additionally requires brackets to surround address literals, 533 referring to the use case as an "alternative to a domain name." 535 See also "IAB Thoughts on Encodings for Internationalized Domain 536 Names" [RFC6055], particularly section 3 entitled "Use of Non-ASCII 537 in DNS" for more thoughts on host names. 539 4.3. URI Authority and Domain Names 541 In "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986], 542 also known as STD 66, mentions in its section 3.2.2 (page 20) that 543 the host subcomponent of the URI Authority (section 3.2) "should 544 conform to the DNS syntax". This comes after discussion that the 545 host subcomponent is not strongly tied to the DNS, i.e., names can be 546 managed via a concept other than the DNS. There's no discussion on 547 the rationale but this enables the reuse of code parsing and 548 marshaling the host subcomponent between different Domain Name 549 environments. 551 This reinforces the notion that there's a need to understand how 552 Domain Names interoperate amongst protocols and applications. And 553 reinforces the need to derive or make explicit a way for client 554 software to know how to resolve a name, that is, convert a name into 555 a network address. 557 4.4. Internet Protocol Address Literals 559 The above definition includes address literals such as 192.0.2.1 for 560 IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these 561 qualify as Domain Names. The addresses might be encased in square 562 brackets "[" and "]" (SMTP mentioned already). In the DNS, as 563 previously described in section 3.1, they are represented per 564 appropriate conventions. 566 4.5. Internationalized Domain Names in Applications 568 The original uses of Domain Names (such as DNS domain names and host 569 names) assumed the ASCII character set. Specifically, making the 570 labels case insensitive prohibited a straightforward use of any 571 method of representation of non-ASCII characters. 573 "Internationalized Domain Names for Applications (IDNA): Definitions 574 and Document Framework" [RFC5890], with associated other documents, 575 defines IDNA2008 as a convention for handling non-ASCII characters in 576 DNS domain names. In figure 1 of that document, the sets of legal 577 DNS domain name formats are defined. Noted in the footnotes of the 578 figure, applications unaware of IDNA2008 cannot distinguish the 579 subsets defined by the document meaning this definition is not an 580 alteration of Domain Names, but, like host names, yet another subset 581 of DNS domain names. 583 4.6. Restricted for DNS Registration 585 "Suggested Practices for Registration of Internationalized Domain 586 Names (IDN)" [RFC4290] presents reasons why DNS domain name 587 registration is restricted in the context of IDN. (That RFC refers 588 to a obsoleted version of IDNA but the concepts still apply.) This 589 is yet another convention related to DNS domain names, which excludes 590 names that fit the syntax but would lead to undesirable outcomes in 591 applications. 593 4.7. Tor Network Names 595 The Tor network is an activity organized by the Tor Project, Inc., 596 described on its main web page "https://www.torproject.org/ 597 index.html.en". 599 One component of the Tor network name space are Domain Names ending 600 in ".onion". (There are other suffixes in use, but it isn't very 601 clear how they are used, defined or whether they are active.) 603 The way in which Domain Names are used in Tor is described in two web 604 documents "Tor Rendezvous Specification" [RENDEV] and "Special 605 Hostnames in Tor" [OHOST] available from the project's website. 607 Syntactically, a Tor domain name fits within the DNS domain name 608 definition but the manner of assignment is different in a manner 609 incompatible with the DNS. (Not better or worse, still significantly 610 different.) Tor domain names are derived from cryptographic keys and 611 organized by distributed hash tables, instead of assigned by a 612 central authority per zone. 614 4.8. X.509 616 "Internet X.509 Public Key Infrastructure Certificate and Certificate 617 Revocation List (CRL) Profile" [RFC5280], section 4.2.1.6 "Subject 618 Alternative Name" a dNSName is defined to be a host name, with the 619 further restriction that the name " " cannot be used. 621 4.9. Multicast DNS 623 Multicast DNS uses a name space ending with ".local." as described in 624 "Multicast DNS" [RFC6762]. The rules for Multicast DNS domain names 625 differ from DNS domain names. Multicast DNS domain names are encoded 626 as Net-Unicode as defined in " Unicode Format for Network 627 Interchange" [RFC5198] with the DNS domain name tradition of case 628 folding the ASCII letters when matching names. Appendix F of RFC 629 6762 gives an explanation of why the punycode algorithm, defined in 630 "Punycode: A Bootstring encoding of Unicode for Internationalized 631 Domain Names in Applications (IDNA)" [RFC3492], is not used. 633 4.10. /etc/hosts 635 The precursor to the DNS, host tables, still exists in remnants in 636 many operating systems. There are library functions, used by 637 applications to resolve Domain Names, that can return names of 638 arbitrary length (meaning, for example, longer than what DNS domain 639 names are defined to be). 641 "Basic Socket Interface Extensions for IPv6" [RFC3493], addresses 642 this in Section 6, further documentation can be found as part of "The 643 Open Group Base Specifications Issue 7" [IEEE1003] and "Microsoft 644 Winsock Functions" [WINSOCK]. 646 4.11. Other Protocols 648 This section is used to list (some) other protocols that use Domain 649 Names but in general do not impose any other restrictions that what 650 has been mentioned above. 652 SSH, documented in "The Secure Shell (SSH) Protocol Architecture" 653 [RFC4251] uses host names, using the name when storing public keys of 654 hosts. SSH clients, not necessarily the protocol, illustrate how 655 applications juggle the different forms of Domain Names. SSH can be 656 invoked to open a secure shell with a host via its DNS domain name/ 657 host name or it can be used to open a secure shell with a host via 658 its Multicast DNS domain name. Or, many others, including name of a 659 purely local, per-user scope. (Note that SSH does not distinguish 660 between DNS domain names and Multicast DNS domain names in the 661 protocol definition, the difference is handled in resolution 662 libraries belonging to the computing platform.) 664 FTP, defined in "FILE TRANSFER PROTOCOL (FTP)" [RFC0959], is silent 665 on Domain Names but client implementations of the protocol behave as 666 SSH clients, being un aware the differences between definitions of 667 Domain Names. 669 DHCP, defined in "Dynamic Host Configuration Protocol" [RFC2131], 670 includes Domain Names in many DHCP options. The use is described in 671 many documents, starting with "DHCP Options and BOOTP Vendor 672 Extensions" [RFC2132]. In "Dynamic Host Configuration Protocol 673 (DHCP) Domain Search Option" [RFC3397] the encoding of Domain Names 674 uses the on-the-wire format of DNS domain names. In "The DHCP Client 675 FQDN Option" [RFC4702] the same format is used. "Dynamic Host 676 Configuration Protocol for IPv6 (DHCPv6)" [RFC8415] contains 677 definitions related to DHCP designed for IPv6. The significance of 678 the DHCP protocols implementation of Domain Names is that, while most 679 other protocols represent DNS domain names or host names in a human 680 readable form, DHCP is using the machine-friendly format. 682 4.12. Other Others 684 If there is a use of Domain Names not listed here it is merely an 685 omission. The goal in this document is to provide a survey that is 686 sufficient to avoid hand-waving arguments, recognizing the 687 diminishing return building a complete roster of uses of Domain 688 Names. 690 5. Interoperability Considerations 692 Any single protocol can define a format for a conceptual Domain Name. 693 Examples given above show that many protocols have done so. From the 694 examples, it is clear that the way in which protocols have 695 interpreted Domain Names has varied, leading to, at least, user 696 interfaces having to have built-in intelligence when handling names 697 and, at worst, a growing confusion over how the Domain Name space is 698 to be managed. 700 When protocols having different formats and rules for Domain Names 701 interact, software implementing the protocols translate one 702 protocol's domain name format to another's format. Even when the 703 translation is straightforward, it is predictable that software will 704 fail to handle this situation well. 706 Often the clash of definitions impacts the design of a new protocol 707 and/or an extension of a protocol. For example, adding non-ASCII 708 domain names has to be done with backwards compatibility with an 709 installed base of ASCII-assuming code. This clash can inhibit new 710 uses of Domain Names. 712 Search lists are a Domain Name mechanism studied in "SSAC Advisory on 713 DNS 'Search List' Processing" [SSAC064]. (Note that the advisory's 714 title labels search lists as a DNS mechanism although the idea of a 715 search list spans many different naming schemes.) One of the 716 particular use cases related to this topic is the issuance of search 717 lists via DHCP and then used by any user-client protocol 718 implementation. This emphasizes an interoperability consideration 719 for how Domain Names are treated in different protocols, not just 720 among implementations of one protocol. 722 The detection and handling of Fully Qualified Domain Names is an 723 interoperability issue as well. At issue is the significance of the 724 terminating separation character in a printed version of a Domain 725 Name. Many clients, when passed a Domain Name as an identifier will 726 add a dot at the end of the argument if the argument does not already 727 end in a dot. [TRAILDOT1] Some do this only after applying the 728 aforementioned search list. As mentioned in the SSAC document in the 729 previous paragraph, inconsistency leads to unpredictable results. 731 The Special Use Domain Names registry lists Domain Names that are to 732 be treated in a manner inconsistent with the DNS normal processing 733 rules. This registry contains Domain Names regardless of whether the 734 name is a DNS domain name and regardless whether the name is a top- 735 level (domain) name or is positioned elsewhere in the tree structure. 737 These are reasons this document is needed. The reason for the 738 confusion over what's a legal domain name stems from application- 739 defined restrictions. For example, using a one-label domain name 740 ("dotless") for sending email is not a problem with the DNS nor the 741 name in concept, but is a problem for mail implementations that 742 expect more than one label. (One-label names may be assumed to be in 743 ARPA host table format.) The "IAB Statement: Dotless Domains 744 Considered Harmful" [IABSTMT] elaborates. 746 6. IANA Considerations 748 None. 750 7. Security Considerations 752 Nothing direct. This document proposes a definition of the term 753 "Domain Name" and surveys how it has been variously applied. In some 754 sense, loosely defined terms give rise to security hazards. Beyond 755 that, there is no impact of "security." 757 8. Acknowledgements 759 Comments or contributions from Andrew Sullivan, Paul Hoffman, George 760 Michaelson, Kevin Darcy, Joe Abley, Jim Reid, Tony Finch, Robert 761 Edmonds, hellekin, Stephane Bortzmeyer, Ray Bellis, Bob Harold, Alec 762 Muffett, Stuart Cheshire, Dave Thaler, Niall O'Reilly, John Klensin, 763 Dave Crocker, Ken Pogran, John Vittal, Lixia Zhang, Ralph Droms and a 764 growing list of others I am losing track of. Not to imply 765 endorsement. 767 9. Informational References 769 [ANSIX34] American National Standards Institute (formerly United 770 States of America Standards Institute), "USA Code for 771 Information Interchange, ANSI X3.4-1968", 1968. 773 [DNSOP] Woolf, S., "Interim DNSOP WG meeting on Special Use Names: 774 some reading material", 2015, 775 . 778 [IABSTMT] Board, I. A., "IAB Statement: Dotless Domains Considered 779 Harmful", 2013, . 783 [IEEE1003] 784 Group, T. I. A. T. O., "The Open Group Base Specifications 785 Issue 7, IEEE Std 1003.1, 2013 Edition, Copyright 786 2001-2013 The IEEE and The Open Group", 2013, 787 . 790 [IEN019] Shoch, J., "A note on Inter-Network Naming, Addressing, 791 and Routing", IEN 19, January 1973, 792 . 794 [IEN116] Postel, J., "INTERNET NAME SERVER", IEN 116, August 1979, 795 . 797 [MWDICT] Merriam-Webster, Incorporated, "Merriam-Webster's Online 798 Dictionary, 11th Edition (Merriam-Webster's Collegiate 799 Dictionary)", 2003, . 801 [OHOST] Mathewson, N., "Special Hostnames in Tor", undated, 802 . 805 [RENDEV] Anonymous, "Tor Rendezvous Specification", undated, 806 . 808 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 809 RFC 20, DOI 10.17487/RFC0020, October 1969, 810 . 812 [RFC0724] Crocker, D., Pogran, K., Vittal, J., and D. Henderson, 813 "Proposed official standard for the format of ARPA Network 814 messages", RFC 724, DOI 10.17487/RFC0724, May 1977, 815 . 817 [RFC0788] Postel, J., "Simple Mail Transfer Protocol", RFC 788, 818 DOI 10.17487/RFC0788, November 1981, 819 . 821 [RFC0799] Mills, D., "Internet name domains", RFC 799, 822 DOI 10.17487/RFC0799, September 1981, 823 . 825 [RFC0801] Postel, J., "NCP/TCP transition plan", RFC 801, 826 DOI 10.17487/RFC0801, November 1981, 827 . 829 [RFC0805] Postel, J., "Computer mail meeting notes", RFC 805, 830 DOI 10.17487/RFC0805, February 1982, 831 . 833 [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for 834 Internet User Applications", RFC 819, 835 DOI 10.17487/RFC0819, August 1982, 836 . 838 [RFC0830] Su, Z., "Distributed system for Internet name service", 839 RFC 830, DOI 10.17487/RFC0830, October 1982, 840 . 842 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 843 RFC 882, DOI 10.17487/RFC0882, November 1983, 844 . 846 [RFC0883] Mockapetris, P., "Domain names: Implementation 847 specification", RFC 883, DOI 10.17487/RFC0883, November 848 1983, . 850 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 851 host table specification", RFC 952, DOI 10.17487/RFC0952, 852 October 1985, . 854 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 855 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 856 . 858 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 859 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 860 . 862 [RFC1035] Mockapetris, P., "Domain names - implementation and 863 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 864 November 1987, . 866 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 867 Application and Support", STD 3, RFC 1123, 868 DOI 10.17487/RFC1123, October 1989, 869 . 871 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 872 Destinations", RFC 1498, DOI 10.17487/RFC1498, August 873 1993, . 875 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 876 Transfer Protocol -- HTTP/1.0", RFC 1945, 877 DOI 10.17487/RFC1945, May 1996, 878 . 880 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 881 RFC 2131, DOI 10.17487/RFC2131, March 1997, 882 . 884 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 885 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 886 . 888 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 889 Understanding Concerning the Technical Work of the 890 Internet Assigned Numbers Authority", RFC 2860, 891 DOI 10.17487/RFC2860, June 2000, 892 . 894 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 895 Protocol (DHCP) Domain Search Option", RFC 3397, 896 DOI 10.17487/RFC3397, November 2002, 897 . 899 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 900 for Internationalized Domain Names in Applications 901 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 902 . 904 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 905 Stevens, "Basic Socket Interface Extensions for IPv6", 906 RFC 3493, DOI 10.17487/RFC3493, February 2003, 907 . 909 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 910 "DNS Extensions to Support IP Version 6", RFC 3596, 911 DOI 10.17487/RFC3596, October 2003, 912 . 914 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 915 Resource Identifier (URI): Generic Syntax", STD 66, 916 RFC 3986, DOI 10.17487/RFC3986, January 2005, 917 . 919 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 920 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 921 January 2006, . 923 [RFC4290] Klensin, J., "Suggested Practices for Registration of 924 Internationalized Domain Names (IDN)", RFC 4290, 925 DOI 10.17487/RFC4290, December 2005, 926 . 928 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 929 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 930 . 932 [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 933 Configuration Protocol (DHCP) Client Fully Qualified 934 Domain Name (FQDN) Option", RFC 4702, 935 DOI 10.17487/RFC4702, October 2006, 936 . 938 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 939 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 940 . 942 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 943 Housley, R., and W. Polk, "Internet X.509 Public Key 944 Infrastructure Certificate and Certificate Revocation List 945 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 946 . 948 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 949 DOI 10.17487/RFC5321, October 2008, 950 . 952 [RFC5890] Klensin, J., "Internationalized Domain Names for 953 Applications (IDNA): Definitions and Document Framework", 954 RFC 5890, DOI 10.17487/RFC5890, August 2010, 955 . 957 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 958 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 959 . 961 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 962 Encodings for Internationalized Domain Names", RFC 6055, 963 DOI 10.17487/RFC6055, February 2011, 964 . 966 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 967 RFC 6761, DOI 10.17487/RFC6761, February 2013, 968 . 970 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 971 DOI 10.17487/RFC6762, February 2013, 972 . 974 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 975 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 976 2013, . 978 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 979 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 980 2015, . 982 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 983 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 984 2015, . 986 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 987 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 988 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 989 RFC 8415, DOI 10.17487/RFC8415, November 2018, 990 . 992 [SSAC064] Anonymous, "SSAC Advisory on DNS "Search List" 993 Processing", 2014, 994 . 997 [TONR15] Wachsmuth, P. N. A. P. T. E. V. G., "A Theory of Name 998 Resolution", last seen 2015, . 1001 [TRAILDOT1] 1002 by), S. C. (. M., "Trailing Dots in Domain Names", 1003 Undated, 1004 . 1006 [WIKIAR] Anonymous, "Automated Reasoning", last edit 2016, 1007 . 1009 [WINSOCK] Microsoft, "getaddrinfo function", last seen 2017, 1010 . 1013 Author's Address 1015 Edward Lewis 1016 ICANN 1018 Email: edward.lewis@icann.org