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