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