idnits 2.17.1 draft-lewis-domain-names-09.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 327 has weird spacing: '...on, on the ...' == Line 328 has weird spacing: '...taining a st...' == Line 329 has weird spacing: '...ed host can ...' == Line 330 has weird spacing: '... This stand...' == Line 331 has weird spacing: '...OW data is t...' -- The document date (August 1, 2017) is 2458 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEN-116' is mentioned on line 175, but not defined == Missing Reference: 'RFC-799' is mentioned on line 175, but not defined == Missing Reference: 'RFC-819' is mentioned on line 175, but not defined == Missing Reference: 'RFC-830' is mentioned on line 175, but not defined == Missing Reference: 'RFC-882' is mentioned on line 180, but not defined ** Obsolete undefined reference: RFC 882 (Obsoleted by RFC 1034, RFC 1035) == Missing Reference: 'RFC-883' is mentioned on line 180, but not defined ** Obsolete undefined reference: RFC 883 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 724 (Obsoleted by RFC 733) -- Obsolete informational reference (is this intentional?): RFC 788 (Obsoleted by RFC 821, RFC 974, RFC 1869, RFC 1870) -- Obsolete informational reference (is this intentional?): RFC 882 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 883 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lewis 3 Internet-Draft ICANN 4 Intended status: Informational August 1, 2017 5 Expires: February 2, 2018 7 Domain Names, A Case for Clarifying 8 draft-lewis-domain-names-09.txt 10 Abstract 12 This document researches the origin of the term Domain Name in the 13 Request for Comments document series, documenting that the term did 14 not originate in the documents defining the Domain Name System. The 15 document describes how the term came to be used, how the DNS 16 followed, and surveys the diverse ways Domain Names have been 17 interpreted within various protocols over time. The purpose of this 18 is to give a solid foundation for work on Domain Names across all 19 protocols making use of Domain Names. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 2, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Emergence of Domain Names . . . . . . . . . . . . . . . . . . 5 59 2.1. The Term "Domain Name" Itself . . . . . . . . . . . . . . 5 60 2.2. The Term "Resolve" . . . . . . . . . . . . . . . . . . . 7 61 3. Dialects, So To Speak, of Domain Names . . . . . . . . . . . 8 62 3.1. Domain Names as Restricted for DNS . . . . . . . . . . . 8 63 3.2. Host Names . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.3. URI Authority and Domain Names . . . . . . . . . . . . . 10 65 3.4. Internet Protocol Address Literals . . . . . . . . . . . 10 66 3.5. Internationalized Domain Names in Applications . . . . . 10 67 3.6. Restricted for DNS Registration . . . . . . . . . . . . . 11 68 3.7. Tor Network Names . . . . . . . . . . . . . . . . . . . . 11 69 3.8. X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.9. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 12 71 3.10. /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . 12 72 3.11. Other Protocols . . . . . . . . . . . . . . . . . . . . . 12 73 3.12. Other Others . . . . . . . . . . . . . . . . . . . . . . 13 74 4. Interoperability Considerations . . . . . . . . . . . . . . . 13 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 8. Informational References . . . . . . . . . . . . . . . . . . 15 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 Why bother to define Domain Names now, three decades after the 84 earliest mentions in RFC documents? There are many examples of names 85 as identifiers in existence, a lot of running code. There is a large 86 industry built on management of names as well, a lot of financial 87 investment made. Would not a definition appearing now be merely an 88 academic exercise or worse, a disruption to what seems to be a 89 reliable system? 91 A desire to examine this topic is a reaction to the discussion 92 related to the Special Use Domain Name Registry as described in 93 "Special Use Domain Names" [RFC6761] and the process of adding 94 "ONION" to that registry, as described in "The '.onion' Special-Use 95 Domain Name" [RFC7686]. Concerns raised on a mailing list used to 96 discuss the latter RFC included specific criterial to declare a name 97 as special as well as the conflict with other processes, such as the 98 process launched from "Memorandum of Understanding Concerning the 99 Technical Work of the Internet Assigned Numbers Authority" [RFC2860], 100 for registering a name in the DNS. 102 During reviews of this document, documented studies of other 103 difficulties have surfaced. "IAB Thoughts on Encodings for 104 Internationalized Domain Names" [RFC6055] documents issues related to 105 converting human-readable forms of Domain Names in forms useful to 106 automated applications when there is no clear architecture or precise 107 definition of how to handle Domain Names. "Issues in Identifier 108 Comparison for Security Purposes" [RFC6943] documents issues related 109 to the same conversion as related to evaluating security policies. 110 The presence of these studies suggests a need to examine the 111 architecture of naming and identifiers. 113 The beneficiaries of such work include both the developers of 114 software that makes use of names and identifiers. A single piece of 115 code could be used in different naming environments if the code can 116 determine how to process a name. With code reusable across different 117 environments, another benefit are innovators exploring new means of 118 identifying objects. 120 1.1. Goal 122 The work ahead has the ingredients of a "clarification" - a loose or 123 poorly-worded initial definition, multiple diverse valid 124 interpretations in use, and a need to converge on a more precise 125 definition which may cause some issues with backwards compatibility. 126 This document sets out to establish that a clarification is 127 warranted. 129 1.2. Background 131 Two or three decades into the history of Domain Names, a popular 132 notion has taken hold that Domains Names were defined and specified 133 in the definition of the Domain Name System (DNS). There are two 134 documents that form the basic definition of the DNS, "Domain names - 135 concepts and facilities" [RFC1034] and "Domain names - implementation 136 and specification" [RFC1035] referred to as RFC 1034 and RFC 1035, 137 respectively. (Note that there is another pair of Request for 138 Comments documents with the same titles [RFC0882] [RFC0883] that 139 precede RFC 1034 and RFC 1035, those were declared obsolete in favor 140 of the newer documents.) Together RFC 1034 and RFC 1035 form STD 13, 141 a full standard cataloged by the RFC Editor. The definitions of DNS 142 domain names within RFC 1034 and RFC 1035 have become the apparently- 143 authoritative source for discussions on what is a Domain Name. 145 Throughout this document the term "Domain Names" is capitalized to 146 emphasize the concept of the names and DNS is used to describe the 147 protocol and algorithms described in STD 13, including any applicable 148 updates, related standards track documents and experimental track 149 documents. 151 The term "domain" is a generic term, there are many naming systems in 152 existence. The use of the term Domain Names in this document refers 153 to the roughly-defined set of protocols and their applications' use 154 of a naming structure that is prevalent amongst many protocols 155 defined in IETF RFC documents. 157 The truth is, STD 13 does not define Domain Names, the documents 158 define only how Domain Names are used and processed in the DNS. 159 However, the way in which the RFC documents read seem to lend to the 160 confusion. 162 RFC 1034, section 2 begins with this text: 164 "This RFC introduces domain style names, their use for Internet mail 165 and host address support, and the protocols and servers used to 166 implement domain name facilities." 168 Which seems to indicate that RFC 1034 is the origin of Domain Names. 169 Immediately following is section 2.1, entitled "The history of domain 170 names" which includes the following text. (The text differs from the 171 original presentation only in wrapping of text to fit current 172 formatting rules.) 174 "The result was several ideas about name spaces and their management 175 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a 176 common thread was the idea of a hierarchical name space, with the 177 hierarchy roughly corresponding to organizational structure, and 178 names using "." as the character to mark the boundary between 179 hierarchy levels. A design using a distributed database and 180 generalized resources was described in [RFC-882, RFC-883]. Based on 181 experience with several implementations, the system evolved into the 182 scheme described in this memo." 184 The only reference included in that text not otherwise mentioened in 185 this document is IEN-116. The reference for that is defined as:" 187 "[IEN-116] J. Postel, "Internet Name Server", IEN-116, 188 USC/Information Sciences Institute, August 1979. 190 A name service obsoleted by the Domain Name System, but 191 still in use." 193 The DNS as it is known today did not invent Domain Names. Work on 194 the Simple Mail Transfer Protocol preceding the DNS mentions domain 195 names, and even it was not the origin of the concept. The DNS is not 196 even the first attempt at an Internet naming system, see "The Domain 197 Naming Convention for Internet User Applications" [RFC0819] and "A 198 Distributed System for Internet Name Service" [RFC0830]. 200 One important phrase to keep in mind is: 202 "To simplify implementations," 204 which appears in both RFC 1034 and RFC 1035 as well as their 205 predecessors RFC 882 and RFC 883. This gives credence to the notion 206 that Domain Names exist beyond the DNS. 208 2. Emergence of Domain Names 210 The first effort taken, in preparation for writing this document, was 211 to scan for the earliest use of the term "domain name" or "name 212 domain". This work is detailed in the following section, but, as 213 noted in private email by reviews of early versions of the document, 214 gave the impression that Domain Names were somehow a by-product of 215 the effort to develop electronic mail. To challenge the notion that 216 email begat domain names, a search through RFC documents for the use 217 of the term resolve as it applies to Domain Names was also done. 219 2.1. The Term "Domain Name" Itself 221 Domain Names emerged from the need to build a hierarchy around the 222 growing number of identified hosts exchanging email. "SIMPLE MAIL 223 TRANSFER PROTOCOL" [RFC0788], explains, in its section 3.7: 225 "At some not too distant future time it might be necessary to 226 expand the mailbox format to include a region or name domain 227 identifier. There is quite a bit of discussion on this at 228 present, and is likely that SMTP will be revised in the future to 229 take into account naming domains." 231 Knowing the origins of a concept helps setting the correct boundaries 232 for discussion. The past isn't meant to restrict the future but 233 meant to help provide a context, include forgotten ideas, and help 234 identify rational for scope creep. 236 "Internet Name Domains" [RFC0799] has (arguably) the first formation 237 of what is a Domain Name: 239 "In its most general form, a standard internet mailbox name has 240 the syntax 242 .@ , 244 where is the name of a user known at the host in the 245 name domain ." 247 Prior to this, domain referred to principally an administrative 248 domain, such as the initial organizations involved in networks at the 249 time. 251 "NCP/TCP TRANSITION PLAN" [RFC0801] contains this, indicating the 252 passage from the host tables: 254 "It might be advantageous to do away with the host name table and 255 use a Name Server instead, or to keep a relatively small table as 256 a cache of recently used host names." 258 "Computer Mail Meeting Notes" [RFC0805] contains this: 260 "The conclusion in this area was that the current "user@host" mailbox 261 identifier should be extended to 'user@host.domain' where 'domain' 262 could be a hierarchy of domains." 264 "The Domain Naming Convention for Internet User Applications" 265 [RFC0819] contains this: 267 "A decision has recently been reached to 268 replace the simple name field, "", by a composite name field, 269 '' " 271 A domain name began to take on its current form: 273 "Internet Convention: Fred@F.ISI.ARPA" 275 In addition, "simple name" is defined as what we now call a label, 276 and a "complete (fully qualified) name" is defined as "concatenation 277 of the simple names of the domain structure tree nodes starting with 278 its own name and ending with the top level node name". Noticeably 279 absent is a terminating dot or any mention or representation of a 280 root. 282 "The Domain Naming Convention for Internet User Applications" (RFC 283 819) also defines ARPA as a top-level name (as opposed to top-level 284 domain name). This is an early mention of the role of top-level 285 names. Additionally, the use of "." [RFC0020][ANSIX34] as a 286 separating character is mentioned. 288 This walk thru history relies solely on the record left behind inside 289 RFC documents. The precise chain of events is likely slightly 290 different and nuanced. The point of the exercise is to show that 291 Domain Names are a concept the emerged over time, spawned the DNS 292 with its domain names, a definition of host names derived from the 293 host tables, and was heavily influenced by SMTP as the driving 294 application. The definition of the FTP protocol, originally defined 295 in "FILE TRANSFER PROTOCOL" [RFC0959], never mentions hosts, domains 296 or host names. But no formal definition of Domain Names has been 297 written and recorded. 299 Note: Concurrent with the writing of this document, the Domain Name 300 Systems Operations working group is documenting a definition for 301 "Domain Names". The first edition of "DNS Terminology" [RFC7719] has 302 a recitation of the original definition from STD 13, the successor 303 edition (still in preparation) has a new, further reaching 304 definition. 306 2.2. The Term "Resolve" 308 As much as Domain Names were influenced by SMTP, electronic mail was 309 not the origin of the Domain Names concepts, this was a hypothesis 310 came from a personal view of the early days of Internet work. To 311 test this, a look for the use of the term "resolve" or "resolution" 312 was conducted in early (arbitrarily defined as pre-1000) RFC 313 documents. 315 The term "resolve" appears numerous times, but in many different 316 contexts. "Resolve" has many meanings, consulting a dictionary, such 317 as Merriam Webster's dictionary [MWDICT], none which seem to match 318 the use associated with domain names. For example, a committee can 319 resolve to solve a certain question. This use of "resolve" occurred 320 numerous times in early RFC documents unrelated to Domain Names. 322 In "Proposed Official Standard for the Format of ARPA Network 323 Messages" [RFC0724] the term resolve was used in the sense of mapping 324 an identifier into an address or something actionable. A section on 325 Semantics (C), Address fields (1.), General (a.), bullet 1 states: 327 "s are used to refer to a location, on the ARPANET, 328 containing a stored address list. The should 329 contain text which the referenced host can resolve to a 330 file. This standard is not a protocol and so does not 331 prescribe HOW data is to be retrieved from the file." 333 Private email to the (reachable) authors of the document pointed to 334 the use of "resolve" stemming from work on programming languages and 335 compiler theory. In that field of work, variables are associated 336 with machine addresses when linking code. There are formal papers 337 including "A Theory of Name Resolution" [TONR15] using the term and 338 the term resolution is used in the field of "Automated Reasoning" 339 [WIKIAR]. 341 While determining the first use of the term resolve or resolution may 342 be hitting against the law of diminishing returns, it is clear that 343 there is a wealth of work that has gone into the concept of Domain 344 Names well before the DNS came into being. 346 3. Dialects, So To Speak, of Domain Names 348 Subtypes of Domain Names have come to be defined for different 349 protocols, evolving and sometimes building on previous definitions. 351 3.1. Domain Names as Restricted for DNS 353 The DNS protocol places size restrictions on Domain Names and defines 354 rules for matching domain names, treating sets of Domain Names as 355 equivalent to each other. (This matching refers to treating upper 356 case and lower case ASCII letters as equivalent.) The DNS defines 357 the format used to transmit the names across the network as well as 358 rules for displaying them inside text zone files. The DNS creates 359 the notion that names are assigned by an authority per zone. 361 Placing size restrictions on Domain Names is significant in reducing 362 the overall population of names that can be represented in the DNS. 363 The matching rules have the effect of creating (to use a term from 364 graph theory) cliques, distorting the tree-nature of the Domain Name 365 graph. A clique is a completely connected sub-graph implying cyclic 366 paths, a tree is a graph that is acyclic. In sum, the treatment of 367 ASCII (and only ASCII) cases as equivalent is a distortion of the 368 Domain Name hierarchy. 370 DNS defines two formats for domain names. One is the "on-the-wire" 371 format used inside messages, a flags-and-length octet followed by 372 some count of octets for each label with the final length of 0 373 representing the root. The other is a version that can be rendered 374 in printable ASCII characters, complete with a means to represent 375 other characters via an escape sequence. This does not alter the 376 Domain Name concept but has implications when it comes to 377 interoperating with other protocol definitions of their domain name 378 use. 380 DNS assumes that there is, in concept, a central authority creating 381 names within the DNS management structure (called a zone). Although 382 the DNS does not define how a central authority is implemented nor 383 how it coins names, the names have to come from a single point to 384 appear in a zone. There are other means for claiming names, an 385 example will be mentioned later. 387 DNS domain names could appear to be the same as address literals, 388 such as "192.0.2.1" or "0:0:0:0:0:FFFF::192.0.2.1". Such DNS domain 389 names are not used for two reasons. Applications expecting a Domain 390 Name (as a comment line parameter as an example) would opt to treat 391 the string as an address literal and would therefore not look for the 392 string in the DNS domain name space. The management model of the DNS 393 would prefer to aggregate (as in routing) addresses belonging 394 together in the same zone, resulting in labels appearing in reverse 395 order. E.g., the network address 192.0.2.1 would be represented by a 396 DNS domain name as "1.2.0.192.in-addr.arpa." as described in RFC 397 1035. For IPv6, the convention used is documented in "DNS Extensions 398 to Support IP Version 6" [RFC3596], section 2.5. 400 See also "Issues in Identifier Comparison for Security Purposes" 401 [RFC6943] section 3.1, "Host Names", in particular, section 3.1.1 and 402 3.1.2 on address literals, and section 4.1, "Conflation." 404 DNS domain names have become the dominant definition of domain names 405 due to the success (scale) of the DNS on the public Internet. Many 406 protocols interact with the DNS but instead of supporting the 407 complete definition of DNS domain names, the protocols rely on a 408 subset more commonly called host names. 410 3.2. Host Names 412 Work on the definition of a host name began well before the issuance 413 of the STD 13 documents defining DNS. The rules for the Preferred 414 Syntax in RFC 1034 conform to the host name rules outlined in "DoD 415 Internet host table specification" [RFC0952]. The host name 416 definition was presented again in "Requirements for Internet Hosts -- 417 Application and Support" [RFC1123] (which is part of STD 3). In 418 section 2.1 of RFC 1123, one (of two mentions) definition of host 419 name is presented, noting that the definition is a relaxation of what 420 is in RFC 952. 422 Host names are subsets of DNS domain names in the sense that the 423 character set is limited. In particular, only "let" (i.e., 424 presumably letters a-z), "digits" and "hyphen" can be used, with 425 hyphen only internal to a label. (This description is meant to be 426 illustrative, not normative. See the grammar presented on page 5 of 427 RFC 952 for specifics.) "Hypertext Transfer Protocol -- HTTP/1.0" 428 [RFC1945], Section 3.2.2 "http URL" specifically references section 429 2.1 of RFC 1123. The reference is explicit. 431 "Simple Mail Transfer Protocol" [RFC5321] refers to RFC 1035 for a 432 definition of domain names but includes text close to what is in the 433 previous paragraph, noting that domain names as used in SMTP refer to 434 both hosts and to other entities. RFC 5321 updates RFC 1123, but 435 does not cite the latter for a definition of host names. RFC 5321 436 additionally requires brackets to surround address literals, 437 referring to the use case as an "alternative to a domain name." 439 See also "IAB Thoughts on Encodings for Internationalized Domain 440 Names" [RFC6055], particularly section 3 entitled "Use of Non-ASCII 441 in DNS" for more thoughts on host names. 443 3.3. URI Authority and Domain Names 445 In "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986], 446 also known as STD 66, mentions in its section 3.2.2 (page 20) that 447 the host subcomponent of the URI Authority (section 3.2) "should 448 conform to the DNS syntax". This comes after discussion that the 449 host subcomponent is not strongly tied to the DNS, i.e., names can be 450 managed via a concept other than the DNS. There's no discussion on 451 the rationale but this enables the reuse of code parsing and 452 marshalling the host subcomponent between different Domain Name 453 environments. 455 This reinforces the notion that there's a need to understand how 456 Domain Names interoperate amongst protocols and applications. And 457 reinforces the need to derive or make explicit a way for client 458 software to know how to resolve a name, that is, convert a name into 459 a network address. 461 3.4. Internet Protocol Address Literals 463 The above definition includes address literals such as 192.0.2.1 for 464 IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these 465 might qualify as Domain Names. The addresses might be encased in 466 square brackets "[" and "]" (SMTP mentioned already). In the DNS, as 467 previously described in section 3.1, they are represented per 468 appropriate conventions. 470 3.5. Internationalized Domain Names in Applications 472 The original uses of Domain Names (such as DNS domain names and host 473 names) assumed the ASCII character set. Specifically, making the 474 labels case insensitive prohibited a straightforward use of any 475 method of representation of non-ASCII characters. 477 "Internationalized Domain Names for Applications (IDNA): Definitions 478 and Document Framework" [RFC5890], with associated other documents, 479 defines IDNA2008 as a convention for handling non-ASCII characters in 480 DNS domain names. In figure 1 of that document, the sets of legal 481 DNS domain name formats are defined. Noted in the footnotes of the 482 figure, applications unaware of IDNA2008 cannot distinguish the 483 subsets defined by the document meaning this definition is not an 484 alteration of Domain Names, but, like host names, yet another subset 485 of DNS domain names. 487 3.6. Restricted for DNS Registration 489 "Suggested Practices for Registration of Internationalized Domain 490 Names (IDN)" [RFC4290] presents reasons why DNS domain name 491 registration is restricted in the context of IDN. (That RFC refers 492 to an older form than IDNA2008, but the concepts still apply.) This 493 is yet another convention related to DNS domain names, excluding 494 names that would lead to undesirable outcomes. 496 3.7. Tor Network Names 498 The Tor network is an activity organized by the Tor Project, Inc., 499 described on its main web page "https://www.torproject.org/ 500 index.html.en". 502 One component of the Tor network name space are Domain Names ending 503 in ".onion". (There are other suffixes in use, but it isn't very 504 clear how they are used, defined or whether they are active.) 506 The way in which Domain Names are used in Tor is described in two web 507 documents "Tor Rendezvous Specification" [RENDEV] and "Special 508 Hostnames in Tor" [OHOST] available from the project's website. 510 Syntactically, a Tor domain name fits within the DNS domain name 511 definition but the manner of assignment is different in a manner 512 incompatible with the DNS. (Not better or worse, still significantly 513 different.) Tor domain names are derived from cryptographic keys and 514 organized by distributed hash tables, instead of assigned by a 515 central authority per zone. 517 3.8. X.509 519 "Internet X.509 Public Key Infrastructure Certificate and Certificate 520 Revocation List (CRL) Profile" [RFC5280], section 4.2.1.6 "Subject 521 Alternative Name" a dNSName is defined to be a host name, with the 522 further restriction that the name " " cannot be used. (The subtle 523 irony is that a name consisting of just a blank would hardly qualify 524 as a Domain Name.) 526 3.9. Multicast DNS 528 Multicast DNS uses a name space ending with ".local." as described in 529 "Multicast DNS" [RFC6762]. The rules for Multicast DNS domain names 530 differ from DNS domain names. Multicast DNS domain names are encoded 531 as Net-Unicode as defined in " Unicode Format for Network 532 Interchange" [RFC5198] with the DNS domain name tradition of case 533 folding the ASCII letters when matching names. Appendix F of RFC 534 6762 gives an explanation of why the punycode algorithm, defined in 535 "Punycode: A Bootstring encoding of Unicode for Internationalized 536 Domain Names in Applications (IDNA)" [RFC3492], is not used. 538 3.10. /etc/hosts 540 The precursor to DNS, host tables, still exists in remnants in many 541 operating systems. There are library functions, used by applications 542 to resolve DNS domain names, that can return names of arbitrary 543 length (meaning, for example longer than what DNS domain names are 544 defined to be). 546 "Basic Socket Interface Extensions for IPv6" [RFC3493], addresses 547 this in Section 6, further documentation can be found as part of "The 548 Open Group Base Specifications Issue 7" [IEEE1003] and "Microsoft 549 Winsock Functions" [WINSOCK]. 551 3.11. Other Protocols 553 This section is used to list (some) other protocols that use Domain 554 Names but in general do not impose any other restrictions that what 555 has been mentioned above. 557 SSH, documented in "The Secure Shell (SSH) Protocol Architecture" 558 [RFC4251] uses host names, using the name when storing public keys of 559 hosts. SSH clients, not necessarily the protocol, illustrate how 560 applications juggle the different forms of Domain Names. SSH can be 561 invoked to open a secure shell with a host via its DNS domain name/ 562 host name or it can be used to open a secure shell with a host via 563 its Multicast DNS domain name. Or, many others, including name of a 564 purely local, per-user scope. (Note that SSH does not distinguish 565 between DNS names and Multicast DNS domain names in the protocol 566 definition, the difference is handled in resolution libraries 567 belonging to the computing platform.) 569 FTP, defined in "FILE TRANSFER PROTOCOL (FTP)" [RFC0959], is silent 570 on domain names but client implementations of the protocol behave as 571 SSH clients, being un aware the differences between definitions of 572 Domain Names. 574 DHCP, defined in "Dynamic Host Configuration Protocol" [RFC2131], 575 includes domain names in its Domain Search Option as described in 576 "Dynamic Host Configuration Protocol (DHCP) Domain Search Option" 577 [RFC3397]. The encoding of Domain Names used is the on-the-wire 578 format of the DNS, using DNS-defined message compression. DHCP 579 handles Domain Names in other options, such as defined in "The DHCP 580 Client FQDN Option" [RFC4702], in the same format. The significance 581 of this is that most other protocols represent DNS domain names or 582 host names in a human readable form, DHCP is using the machine- 583 friendly format. 585 3.12. Other Others 587 If there is a use of Domain Names not listed here it is merely an 588 omission. The goal in this document is to provide a survey that is 589 sufficient to avoid hand-waving arguments, recognizing the 590 diminishing return in trying to build a complete roster of uses of 591 Domain Names. If there are omissions that ought to be included, 592 please send references for the use case to the author (while this is 593 an Internet Draft, that is). 595 4. Interoperability Considerations 597 Any single protocol can define a format for a conceptual Domain Name. 598 Examples given above show that many protocols have done so. From the 599 examples, it is clear that the way in which protocols have 600 interpreted Domain Names has varied, leading to, at least, user 601 interfaces having to have built-in intelligence when handling names 602 and, at worst, a growing confusion over how the Domain Name space is 603 to be managed. 605 When protocols having different formats and rules for Domain Names 606 interact, software implementing the protocols translate one 607 protocol's domain name format to another's format. Even when the 608 translation is straightforward, it is predictable that software will 609 fail to handle this situation well. 611 Often the clash of definitions impacts the design of a new protocol 612 and/or an extension of a protocol. For example, adding non-ASCII 613 domain names has to be done with backwards compatibility with an 614 installed base of ASCII-assuming code. This clash can inhibit new 615 uses of Domain Names. 617 Search lists are a Domain Name mechanism studied in "SSAC Advisory on 618 DNS 'Search List' Processing" [SSAC064]. One of the particular use 619 cases related to this topic is the issuance of search lists via DHCP 620 and then used by any user-client protocol implementation. This 621 emphasizes an interoperability consideration for how Domain Names are 622 treated in different protocols, not just among implementations of one 623 protocol. 625 The detection and handling of Fully Qualified Domain Names is an 626 interoperability issue as well. At issue is the significance of the 627 terminating separation character in a printed version of a Domain 628 Name. Many clients, when passed a Domain Name as an identifier will 629 add a dot at the end of the argument if the argument does not already 630 end in a dot. [TRAILDOT1] Some do this only after applying the 631 aforementioned search list. As mentioned in the SSAC document in the 632 previous paragraph, inconsistency leads to surprising results. 634 The Special Use Domain Names registry lists Domain Names that are to 635 be treated in a manner inconsistent with the DNS normal processing 636 rules. This registry contains Domain Names regardless of whether the 637 name is a DNS domain name and regardless whether the name is a top- 638 level (domain) name or is positioned elsewhere in the tree structure. 640 These are reasons this document is needed. The reason for the 641 confusion over what's a legal domain name stems from application- 642 defined restrictions. For example, using a one-label domain name 643 ("dotless") for sending email is not a problem with the DNS nor the 644 name in concept, but is a problem for mail implementations that 645 expect more than one label. (One-label names may be assumed to be in 646 ARPA host table format.) The "IAB Statement: Dotless Domains 647 Considered Harmful" [IABSTMT] elaborates. 649 5. Acknowledgements 651 Comments or contributions from Andrew Sullivan, Paul Hoffman, George 652 Michaelson, Kevin Darcy, Joe Abley, Jim Reid, Tony Finch, Robert 653 Edmonds, hellekin, Stephane Bortzmeyer, Ray Bellis, Bob Harold, Alec 654 Muffett, Stuart Cheshire, Dave Thaler, Niall O'Reilly, John Klensin, 655 Dave Crocker, Ken Pogran, John Vittal and a growing list of others I 656 am losing track of. Not to imply endorsement. 658 6. IANA Considerations 660 None. 662 7. Security Considerations 664 Nothing direct. This document proposes a definition of the term 665 "Domain Name" and surveys how it has been variously applied. In some 666 sense, loosely defined terms give rise to security hazards. Beyond 667 that, there is no impact of "security." 669 8. Informational References 671 [ANSIX34] American National Standards Institute (formerly United 672 States of America Standards Institute), "USA Code for 673 Information Interchange, ANSI X3.4-1968", 1968. 675 [IABSTMT] "IAB Statement: Dotless Domains Considered Harmful", 2013, 676 . 680 [IEEE1003] 681 "The Open Group Base Specifications Issue 7, IEEE Std 682 1003.1, 2013 Edition, Copyright 2001-2013 The IEEE and The 683 Open Group", 2013, 684 . 687 [MWDICT] Merriam-Webster, Incorporated, "Merriam-Webster's Online 688 Dictionary, 11th Edition (Merriam-Webster's Collegiate 689 Dictionary)", 2003, . 691 [OHOST] "Special Hostnames in Tor", undated, 692 . 695 [RENDEV] "Tor Rendezvous Specification", undated, 696 . 698 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 699 RFC 20, DOI 10.17487/RFC0020, October 1969, 700 . 702 [RFC0724] Crocker, D., Pogran, K., Vittal, J., and D. Henderson, 703 "Proposed official standard for the format of ARPA Network 704 messages", RFC 724, DOI 10.17487/RFC0724, May 1977, 705 . 707 [RFC0788] Postel, J., "Simple Mail Transfer Protocol", RFC 788, 708 DOI 10.17487/RFC0788, November 1981, 709 . 711 [RFC0799] Mills, D., "Internet name domains", RFC 799, 712 DOI 10.17487/RFC0799, September 1981, 713 . 715 [RFC0801] Postel, J., "NCP/TCP transition plan", RFC 801, 716 DOI 10.17487/RFC0801, November 1981, 717 . 719 [RFC0805] Postel, J., "Computer mail meeting notes", RFC 805, 720 DOI 10.17487/RFC0805, February 1982, 721 . 723 [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for 724 Internet User Applications", RFC 819, 725 DOI 10.17487/RFC0819, August 1982, 726 . 728 [RFC0830] Su, Z., "Distributed system for Internet name service", 729 RFC 830, DOI 10.17487/RFC0830, October 1982, 730 . 732 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 733 RFC 882, DOI 10.17487/RFC0882, November 1983, 734 . 736 [RFC0883] Mockapetris, P., "Domain names: Implementation 737 specification", RFC 883, DOI 10.17487/RFC0883, November 738 1983, . 740 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 741 host table specification", RFC 952, DOI 10.17487/RFC0952, 742 October 1985, . 744 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 745 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 746 . 748 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 749 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 750 . 752 [RFC1035] Mockapetris, P., "Domain names - implementation and 753 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 754 November 1987, . 756 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 757 Application and Support", STD 3, RFC 1123, 758 DOI 10.17487/RFC1123, October 1989, 759 . 761 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 762 Transfer Protocol -- HTTP/1.0", RFC 1945, 763 DOI 10.17487/RFC1945, May 1996, 764 . 766 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 767 RFC 2131, DOI 10.17487/RFC2131, March 1997, 768 . 770 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 771 Understanding Concerning the Technical Work of the 772 Internet Assigned Numbers Authority", RFC 2860, 773 DOI 10.17487/RFC2860, June 2000, 774 . 776 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 777 Protocol (DHCP) Domain Search Option", RFC 3397, 778 DOI 10.17487/RFC3397, November 2002, 779 . 781 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 782 for Internationalized Domain Names in Applications 783 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 784 . 786 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 787 Stevens, "Basic Socket Interface Extensions for IPv6", 788 RFC 3493, DOI 10.17487/RFC3493, February 2003, 789 . 791 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 792 "DNS Extensions to Support IP Version 6", RFC 3596, 793 DOI 10.17487/RFC3596, October 2003, 794 . 796 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 797 Resource Identifier (URI): Generic Syntax", STD 66, 798 RFC 3986, DOI 10.17487/RFC3986, January 2005, 799 . 801 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 802 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 803 January 2006, . 805 [RFC4290] Klensin, J., "Suggested Practices for Registration of 806 Internationalized Domain Names (IDN)", RFC 4290, 807 DOI 10.17487/RFC4290, December 2005, 808 . 810 [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 811 Configuration Protocol (DHCP) Client Fully Qualified 812 Domain Name (FQDN) Option", RFC 4702, 813 DOI 10.17487/RFC4702, October 2006, 814 . 816 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 817 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 818 . 820 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 821 Housley, R., and W. Polk, "Internet X.509 Public Key 822 Infrastructure Certificate and Certificate Revocation List 823 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 824 . 826 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 827 DOI 10.17487/RFC5321, October 2008, 828 . 830 [RFC5890] Klensin, J., "Internationalized Domain Names for 831 Applications (IDNA): Definitions and Document Framework", 832 RFC 5890, DOI 10.17487/RFC5890, August 2010, 833 . 835 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 836 Encodings for Internationalized Domain Names", RFC 6055, 837 DOI 10.17487/RFC6055, February 2011, 838 . 840 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 841 RFC 6761, DOI 10.17487/RFC6761, February 2013, 842 . 844 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 845 DOI 10.17487/RFC6762, February 2013, 846 . 848 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 849 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 850 2013, . 852 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 853 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 854 2015, . 856 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 857 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 858 2015, . 860 [SSAC064] ICANN Security and Stability Advisory Committee, "SSAC 861 Advisory on DNS "Search List" Processing", 2014, 862 . 865 [TONR15] Programming Languages and Systems - 24th European 866 Symposium on Programming, ESOP 2015, Held as Part of the 867 European Joint Conferences on Theory and Practice of 868 Software, ETAPS 2015, London, UK, April 11-18, 2015, 869 Proceedings. Lecture Notes in Computer Science, Springer, 870 April 2015., "A Theory of Name Resolution", last seen 871 2015, . 874 [TRAILDOT1] 875 "Trailing Dots in Domain Names", Undated, 876 . 878 [WIKIAR] Wikipedia, "Automated Reasoning", last edit 2016, 879 . 881 [WINSOCK] "getaddrinfo function", last seen 2017, 882 . 885 Author's Address 887 Edward Lewis 888 ICANN 890 Email: edward.lewis@icann.org