idnits 2.17.00 (12 Aug 2021) /tmp/idnits38064/draft-lewis-domain-names-03.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 799 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- 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 == Unrecognized Status in 'Intended Status: unknown', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (July 1, 2016) is 2150 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC 6761' on line 98 looks like a reference -- Missing reference section? 'RFC 7686' on line 100 looks like a reference -- Missing reference section? 'RFC 2860' on line 104 looks like a reference -- Missing reference section? 'RFC 6055' on line 369 looks like a reference -- Missing reference section? 'RFC 6943' on line 113 looks like a reference -- Missing reference section? 'IEN-116' on line 176 looks like a reference -- Missing reference section? 'RFC-799' on line 176 looks like a reference -- Missing reference section? 'RFC-819' on line 176 looks like a reference -- Missing reference section? 'RFC-830' on line 176 looks like a reference -- Missing reference section? 'RFC-882' on line 181 looks like a reference -- Missing reference section? 'RFC-883' on line 181 looks like a reference -- Missing reference section? 'RFC 3596' on line 328 looks like a reference -- Missing reference section? 'RFC 5321' on line 360 looks like a reference -- Missing reference section? 'RFC 3986' on line 374 looks like a reference -- Missing reference section? 'RFC 5890' on line 406 looks like a reference -- Missing reference section? 'RFC 4290' on line 418 looks like a reference -- Missing reference section? 'RENDEV' on line 434 looks like a reference -- Missing reference section? 'OHOST' on line 435 looks like a reference -- Missing reference section? 'RFC 5280' on line 447 looks like a reference -- Missing reference section? 'RFC 6762' on line 456 looks like a reference -- Missing reference section? 'IEEE1003.1' on line 473 looks like a reference -- Missing reference section? 'WINSOCK' on line 474 looks like a reference -- Missing reference section? 'RFC 4251' on line 483 looks like a reference -- Missing reference section? 'RFC 959' on line 493 looks like a reference -- Missing reference section? 'RFC 2131' on line 498 looks like a reference -- Missing reference section? 'SAC 064' on line 541 looks like a reference -- Missing reference section? 'RFC 819' on line 562 looks like a reference Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Independent Submission E. Lewis 2 Internet-Draft ICANN 3 Expires: January 1, 2017 Date: July 1, 2016 4 Intended Status: unknown 6 Domain Names 7 draft-lewis-domain-names-03.txt 9 Abstract 11 This document researches the origin of the term Domain Name in the 12 Request for Comments document series, documenting that the term did 13 not originate in the documents defining the Domain Name System. The 14 document describes how the term came to be used, how the DNS followed, 15 and surveys the diverse ways Domain Names have been interpreted within 16 various protocols over time. The purpose of this is to give a solid 17 foundation for work on Domain Names across all protocols making use of 18 Domain Names. 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 http://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 1, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 (http://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 0. NOTE TO RFC EDITOR AND REVIEWERS 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 56 2. Emergence of Domain Names . . . . . . . . . . . . . . . . . . 1 57 3. Dialects, so to speak, of Domain Names . . . . . . . . . . . . 1 58 4. Interoperability Considerations . . . . . . . . . . . . . . . 1 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 1 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 1 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 1 63 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 1 65 0. NOTE TO RFC EDITOR AND REVIEWERS 67 The closest mailing list to this topic is arcing@ietf.org. Or maybe 68 dnsop@ietf.org. Private comments may also be directed at the editor. 70 This section (and sub-sections) **probably** should be removed 71 prior to publication. 73 Note on changes from earlier edition: 75 The document's scope has been reduced, at least for now. The document 76 sticks to history and current observations without proposing a 77 definition nor an architecture. There's too many degrees of freedom 78 in the definition/architecture space at the moment to make a useful 79 specific recommendation. 81 1. Introduction 83 What is the motivation behind the document and what is the anticipated 84 result? 86 1.1 Motivation for this Document 88 Why bother to define Domain Names now, three decades after the 89 earliest mentions in RFC documents? There are many examples of 90 names as identifiers in existence, a lot of running code. There is 91 a large industry built on management of names as well, a lot of 92 financial investment made. Would not a definition appearing now be 93 merely an academic exercise or worse, a disruption to what seems to 94 be a reliable system? 96 A desire to examine this topic is a reaction to the discussion 97 related to the Special Use Domain Name Registry as described in 98 "Special Use Domain Names" [RFC 6761] and the process of adding 99 "ONION" to that registry, as described in "The '.onion' Special-Use 100 Domain Name" [RFC 7686]. Concerns raised on a mailing list used to 101 discuss the latter RFC included specific criterial to declare a name 102 as special as well as the conflict with other processes, such as the 103 process launched from "Memorandum of Understanding Concerning the 104 Technical Work of the Internet Assigned Numbers Authority" [RFC 2860], 105 for registering a name in the DNS. 107 During reviews of this document, documented studies of other 108 difficulties have surfaced. "IAB Thoughts on Encodings for 109 Internationalized Domain Names" [RFC 6055] documents issues related to 110 converting human-readable forms of Domain Names in forms useful to 111 automated applications when there is no clear architecture or precise 112 definition of how to handle Domain Names. "Issues in Identifier 113 Comparison for Security Purposes" [RFC 6943] documents issues related 114 to the same conversion as related to evaluating security policies. The 115 presence of these studies suggest a need to examine the architecture 116 of naming and identifiers. 118 The beneficiaries of such work include both the developers of software 119 that makes use of names and identifiers. A single piece of code could 120 be used in different naming environments if the code can determine how 121 to process a name. With code reusable across different environments, 122 another benefit are innovators exploring new means of identifying 123 objects. 125 1.2 Goal 127 The work ahead has the ingredients of a "clarification" - a loose 128 or poorly worded initial definition, multiple diverse valid 129 interpretations in use, and a need to converge on a more precise 130 definition which may cause some issues with backwards compatibility. 131 This document sets out to establish that a clarification is warranted. 133 1.3 Background 135 Two or three decades into the history of Domain Names, a popular 136 notion has taken hold that Domains Names were defined and specified 137 in the definition of the Domain Name System (DNS). There are two 138 documents that form the basic definition of the DNS, "Domain names - 139 concepts and facilities" and "Domain names - implementation and 140 specification" referred to as RFC 1034 and RFC 1035, respectively. 141 (Note that there is another pair of Request for Comments documents 142 with the same titles that precede RFC 1034 and RFC 1035, those were 143 declared obsolete in favor of the newer documents.) Together RFC 1034 144 and RFC 1035 form STD 13, a full standard cataloged by the RFC Editor. 145 The definitions of DNS domain names within RFC 1034 and RFC 1035 have 146 become the apparently-authoritative source for discussions on what is 147 a Domain Name. 149 Throughout this document the term "Domain Names" is capitalized to 150 emphasize the concept of the names and DNS is used to describe the 151 protocol and algorithms described in STD 13, including any applicable 152 updates, related standards track documents and experimental track 153 documents. 155 The term domain is a generic term. And there are many naming 156 systems in existence. The use of the term Domain Names in this 157 document refers to the roughly-defined set of protocols and their 158 applications' use of a naming structure that is prevalent amongst 159 many protocols defined in IETF RFC documents. 161 The truth is, STD 13 does not define Domain Names, the documents define 162 only how Domain Names are used and processed in the DNS. However the 163 way in which the RFC documents read seem to lend to the confusion. 165 RFC 1034, section 2 begins with this text: 167 "This RFC introduces domain style names, their use for Internet mail 168 and host address support, and the protocols and servers used to 169 implement domain name facilities." 171 Which seems to indicate that RFC 1034 is the origin of Domain Names. 172 Immediately following is section 2.1, entitled "The history of domain 173 names" which includes the following text. 175 "The result was several ideas about name spaces and their management 176 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a 177 common thread was the idea of a hierarchical name space, with the 178 hierarchy roughly corresponding to organizational structure, and names 179 using "." as the character to mark the boundary between hierarchy 180 levels. A design using a distributed database and generalized 181 resources was described in [RFC-882, RFC-883]. Based on experience 182 with several implementations, the system evolved into the scheme 183 described in this memo." 185 The DNS as it is known today did not invent Domain Names (work on the 186 Simple Mail Transfer Protocol did) and, for what it's worth, wasn't 187 the first attempt at an Internet naming system (described in RFC 819 188 "The Domain Naming Convention for Internet User Applications"). 190 One important phrase to keep in mind is: 192 "To simplify implementations," 194 which appears in both RFC 1034 and RFC 1035 as well as their 195 predecessors RFC 882 and RFC 883. This gives credence to the notion 196 that Domain Names exist beyond the DNS. 198 2. Emergence of Domain Names 200 Domain Names emerged from the need to build a hierarchy around the 201 growing number of identified hosts exchanging email. RFC 788, "SIMPLE 202 MAIL TRANSFER PROTOCOL", explains, in its section 3.7: 204 "At some not too distant future time it might be necessary to 205 expand the mailbox format to include a region or name domain 206 identifier. There is quite a bit of discussion on this at 207 present, and is likely that SMTP will be revised in the future to 208 take into account naming domains." 210 Knowing the origins of a concept helps setting the correct boundaries 211 for discussion. The past isn't meant to restrict the future but 212 meant to help provide a context, include forgotten ideas, and help 213 identify rational for scope creep. 215 RFC 799 "Internet Name Domains" has (arguably) the first formation of 216 what is a Domain Name: 218 "In its most general form, a standard internet mailbox name has 219 the syntax 221 .@ , 223 where is the name of a user known at the host in the 224 name domain ." 226 Prior to this, domain referred to principally an administrative 227 domain, such as the initial organizations involved in networks at the 228 time. 230 RFC 801 "NCP/TCP TRANSITION PLAN" contains this, indicating the 231 passage from the host tables: 233 "It might be advantageous to do away with the host name table and 234 use a Name Server instead, or to keep a relatively small table as 235 a cache of recently used host names." 237 RFC 805 "Computer Mail Meeting Notes" contains this: 239 "The conclusion in this area was that the current "user@host" mailbox 240 identifier should be extended to 'user@host.domain' where 'domain' 241 could be a hierarchy of domains." 243 RFC 819 "The Domain Naming Convention for Internet User Applications" 244 contains this: 246 "A decision has recently been reached to 247 replace the simple name field, "", by a composite name field, 248 '' " 250 A domain name began to take on its current form: 252 "Internet Convention: Fred@F.ISI.ARPA" 254 In addition, "simple name" is defined as what we now call a label, and 255 a "complete (fully qualified) name" is defined as "concatenation of 256 the simple names of the domain structure tree nodes starting with its 257 own name and ending with the top level node name". Noticeably 258 absent is a terminating dot or any mention or representation of a 259 root. 261 RFC 819 defines ARPA as a top-level name (as opposed to top-level 262 domain name). This is an early mention of the role of top-level 263 names. 265 This walk through history relies solely on the record left behind 266 inside RFCs. The precise chain of events is likely slightly 267 different and nuanced. The point of the exercise is to show that 268 Domain Names are a concept the emerged over time, spawned the DNS 269 with its domain names, a definition of host names derived from the 270 host tables, and was heavily influenced by SMTP as the driving 271 application. The definition of the FTP protocol, originally defined 272 in RFC 959 "FILE TRANSFER PROTOCOL", never mentions hosts, domains or 273 host names. But no formal definition of Domain Names has been 274 written and recorded. 276 3. Dialects, so to speak, of Domain Names 278 Subtypes of Domain Names have come to be defined for different 279 protocols, evolving and sometimes building on previous definitions. 281 3.1 Domain Names as Restricted for DNS 283 The DNS protocol place size restrictions on Domain Names and defines 284 rules for matching domain names, treating sets of Domain Names as 285 equivalent to each other. (This matching refers to treating upper 286 case and lower case ASCII letters as equivalent.) The DNS defines 287 the format used to transmit the names across the network as well as 288 rules for displaying them inside text zone files. The DNS creates 289 the notion that names are assigned by an authority per zone. 291 Placing size restrictions on Domain Names is significant in reducing 292 the overall population of names that can be represented in the DNS. 293 The matching rules have the effect of creating (to use a term from 294 graph theory) cliques, distorting the tree-nature of the Domain Name 295 graph. A clique is a completely connected sub-graph implying cyclic 296 paths, a tree is a graph that is acyclic. In sum, the treatment of 297 ASCII (and only ASCII) cases as equivalent is a distortion of the 298 Domain Name hierarchy. 300 DNS defines two formats for domain names. One is the "on-the-wire" 301 format used inside messages, a flags-and-length octet followed by 302 some count of octets for each label with the final length of 0 303 representing the root. The other is a version that can be rendered 304 in printable ASCII characters, complete with a means to represent 305 other characters via an escape sequence. This does not alter the 306 Domain Name concept but has implications when it comes to 307 interoperating with other protocol definitions of their domain name 308 use. 310 DNS assumes that there is, in concept, a central authority creating 311 names within the DNS management structure (called a zone). Although 312 the DNS does not define how a central authority is implemented nor 313 how it coins names, the names have to come from a single point to 314 appear in a zone. There are other means for claiming names, an 315 example will be mentioned later. 317 DNS domain names could appear to be the same as address literals, such 318 as "192.0.2.1" or "0:0:0:0:0:FFFF::192.0.2.1". Such DNS domain 319 names are not used for two reasons. Applications expecting a 320 Domain Name (as a comment line parameter as an example) would 321 opt to treat the string as an address literal and would therefore 322 not look for the string in the DNS domain name space. The management 323 model of the DNS would prefer to aggregate (as in routing) addresses 324 belonging together in the same zone, resulting in labels appearing in 325 reverse order. E.g., the network address 192.0.2.1 would be 326 represented by a DNS domain name as "1.2.0.192.in-addr.arpa." 327 as described in RFC 1035. For IPv6, the convention used is documented 328 in "DNS Extensions to Support IP Version 6" [RFC 3596], section 2.5. 330 See also "Issues in Identifier Comparison for Security Purposes" [RFC 331 6943] section 3.1, "Host Names", in particular section 3.1.1 and 3.1.2 332 on address literals, and section 4.1, "Conflation." 334 DNS domain names have become the dominant definition of domain names 335 due to the success (scale) of the DNS on the public Internet. Many 336 protocols interact with the DNS but instead of supporting the 337 complete definition of DNS domain names, the protocols rely on a 338 subset more commonly called host names. 340 3.2 Host Names 342 Work on the definition of a host name began well before the issuance 343 of the STD 13 documents defining DNS. The rules for the Preferred 344 Syntax in RFC 1034 conform to the host name rules outlined in RFC 345 952. The host name definition was presented again in RFC 1123 346 "Requirements for Internet Hosts -- Application and Support" (which 347 is part of STD 3). In section 2.1 of RFC 1123, one (of two mentions) 348 definition of host name is presented, noting that the definition is a 349 relaxation of what is in RFC 952. 351 Host names are subsets of DNS domain names in the sense that the 352 character set is limited. In particular, only "let" (i.e., 353 presumably letters a-z), "digits" and "hyphen" can be used, with 354 hyphen only internal to a label. (This description is meant to be 355 illustrative, not normative. See the grammar presented on page 5 of 356 RFC 952 for specifics.) RFC 1945 "Hypertext Transfer Protocol -- 357 HTTP/1.0", Section 3.2.2 "http URL" specifically references section 358 2.1 of RFC 1123. The reference is explicit. 360 "Simple Mail Transfer Protocol" [RFC 5321] refers to RFC 1035 for a 361 definition of domain names but includes text close to what is in the 362 previous paragraph, noting that domain names as used in SMTP refer to 363 both hosts and to other entities. RFC 5321 updates RFC 1123, but 364 does not cite the latter for a definition of host names. RFC 5321 365 additionally requires brackets to surround address literals, 366 referring to the use case as an "alternative to a domain name." 368 See also "IAB Thoughts on Encodings for Internationalized Domain Names" 369 [RFC 6055], particularly section 3 entitled "Use of Non-ASCII in DNS" 370 for more thoughts on host names. 372 3.3 URI Authority and Domain Names 374 In "Uniform Resource Identifier (URI): Generic Syntax" [RFC 3986], also 375 known as STD 66, mentions in its section 3.2.2 (page 20) that the host 376 subcomponent of the URI Authority (section 3.2) "should conform to the 377 DNS syntax". This comes after discussion that the host subcomponent 378 is not strongly tied to the DNS, i.e., names can be managed via a 379 concept other than the DNS. There's no discussion on the rationale 380 but this enables the reuse of code parsing and marshalling the host 381 subcomponent between different Domain Name environments. 383 This reinforces the notion that there's a need to understand how Domain 384 Names interoperate amongst protocols and applications. And reinforces 385 the need to derive or make explicit a way for client software to know 386 how to resolve a name, that is, convert a name into a network address. 388 3.4 Internet Protocol Address Literals 390 The above definition includes address literals such as 192.0.2.1 for 391 IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these 392 qualify as Domain Names. In some protocols, these domain names are 393 specified as being preceded by a "#" (find this and cite) or encased 394 in square brackets "[" and "]" (SMTP mentioned already). In the DNS, 395 as previously described in section 3.1, they are represented 396 according to appropriate conventions. 398 3.5 Internationalized Domain Names in Applications 400 The original uses of Domain Names (such as DNS domain names 401 and host names) assumed the ASCII character set. Specifically, 402 making the labels case insensitive prohibited a straightforward use 403 of any method of representation of non-ASCII characters. 405 "Internationalized Domain Names for Applications (IDNA): Definitions 406 and Document Framework" [RFC 5890], with associated other documents, 407 defines IDNA2008 as a convention for handling non-ASCII characters in 408 DNS domain names. In figure 1 of that document, the sets of legal DNS 409 domain name formats are defined. Noted in the footnotes of the 410 figure, applications unaware of IDNA2008 cannot distinguish the subsets 411 defined by the document meaning this definition is not an alteration 412 of Domain Names, but, like host names, yet another subset of DNS 413 domain names. 415 3.6 Restricted for DNS Registration 417 "Suggested Practices for Registration of Internationalized Domain Names 418 (IDN)" [RFC 4290] presents reasons why registration of DNS domain 419 names is restricted, in the context of IDN. (That RFC refers to an 420 older form than IDNA2008, but the concepts still apply.) This is yet 421 another convention related to DNS domain names, excluding names that 422 would lead to undesirable outcomes. 424 3.7 Tor Network Names 426 The Tor network is an activity organized by the Tor Project, Inc., 427 described on its main web page 428 "https://www.torproject.org/index.html.en". One component of the 429 network are Domain Names ending in ".onion". (There are other 430 suffixes in use, but it isn't very clear how they are used, defined 431 or whether they are active.) 433 The way in which Domain Names are used in Tor is described in two web 434 documents "Tor Rendezvous Specification" [RENDEV] and "Special 435 Hostnames in Tor" [OHOST] available from the project's website. 437 Syntactically, a Tor domain name fits within the DNS domain name 438 definition but the manner of assignment is different in a manner 439 incompatible with the DNS. (Not better or worse, still significantly 440 different.) Tor domain names are derived from cryptographic keys and 441 organized by distributed hash tables, instead of assigned by a central 442 authority per zone. 444 3.8 X.509 446 "Internet X.509 Public Key Infrastructure Certificate and Certificate 447 Revocation List (CRL) Profile" [RFC 5280], section 4.2.1.6 "Subject 448 Alternative Name" a dNSName is defined to be a host name, with the 449 further restriction that the name " " cannot be used. (The sublte 450 irony is that a name consisting of just a blank would hardly qualify 451 as a Domain Name.) 453 3.9 Multicast DNS 455 Multicast DNS uses a name space ending with ".local." as described in 456 "Multicast DNS" [RFC 6762]. The rules for Multicast DNS domain names 457 differ from DNS domain names. Multicast DNS domain names are encoded 458 as Net-Unicode as defined in RFC5198 " Unicode Format for Network 459 Interchange" with the DNS domain name tradition of case folding the 460 ASCII letters when matching names. Appendix F of RFC 6762 gives an 461 explanation of why the punycode algorithm is not used. 463 3.10 /etc/hosts 465 The precursor to DNS, host tables, still exists in remnants in many 466 operating systems. There are library functions, used by applications 467 to resolve DNS domain names, that can return names of arbitrary 468 length (meaning, for example longer than what DNS domain names are 469 defined to be). 471 RFC 3493, "Basic Socket Interface Extensions for IPv6", addresses 472 this in Section 6, further documentation can be found as part of 473 The Open Group Base Specifications Issue 7 [IEEE1003.1] and Microsoft 474 Winsock Functions [WINSOCK]. 476 3.11 Other Protocols 478 This section is used to list (some) other protocols that use Domain 479 Names but in general do not impose any other restrictions that what 480 has been mentioned above. 482 SSH, documented in "The Secure Shell (SSH) Protocol Architecture" 483 [RFC 4251] uses host names, using the name when storing public keys 484 of hosts. SSH clients, not necessarily the protocol, illustrate how 485 applications juggle the different forms of Domain Names. SSH can be 486 invoked to open a secure shell with a host via its DNS domain 487 name/host name or it can be used to open a secure shell with a host 488 via its Multicast DNS domain name. (Note that SSH does not distinguish 489 between DNS names and Multicast DNS domain names in the protocol 490 definition, the difference is handled in resolution libraries belonging 491 to the computing platform.) 493 FTP, defined in "FILE TRANSFER PROTOCOL (FTP)" [RFC 959], is silent on 494 domain names but client implementations of the protocol behave as SSH 495 clients, being un aware the differences between definitions of Domain 496 Names. 498 DHCP, defined in "Dynamic Host Configuration Protocol" [RFC 2131], 499 includes domain names in its Domain Search Option [RFC 3397 "Dynamic 500 Host Configuration Protocol (DHCP) Domain Search Option"]. The 501 encoding of Domain Names used is the on-the-wire format of the DNS, 502 using DNS-defined message compression. DHCP handles Domain Names in 503 other options such as in RFC 4702 defined "The DHCP Client FQDN 504 Option", in the same format. The significance of this is that most 505 other protocols represent DNS domain names or host names in a human 506 readable form, DHCP is using the machine-friendly format. 508 3.12 Other others 510 If there is a use of Domain Names not listed here it is merely an 511 omission. The goal in this document is to provide a survey that 512 is sufficient to avoid hand-waving arguments, recognizing the 513 diminishing return in trying to build a complete roster of uses 514 of Domain Names. If there are omissions that ought to be included, 515 please send references for the use case to the author (while this is 516 an Internet Draft, that is). 518 4. Interoperability Considerations 520 Any single protocol is able to define a format for a conceptual Domain 521 Name. Examples given above show that many protocols have done so. 522 From the examples it is clear that the way in which protocols have 523 interpreted Domain Names has varied, leading to, at least, user 524 interfaces having to have built-in intelligence when handling names 525 and, at worst, a growing confusion over how the Domain Name space is 526 to be managed. 528 When protocols having different formats and rules for Domain Names 529 interact, software implementing the protocols translate one protocol's 530 domain name format to another's format. Even when the translation is 531 straightforward, software often fails to handle error conditions well. 532 (Is there a citation for that?) 534 Often times the clash of definitions impacts the design of a new 535 protocol and/or an extension of a protocol. For example, adding 536 non-ASCII domain names has to be done with backwards compatibility 537 with an installed base of ASCII-assuming code. This clash can 538 inhibit new uses of Domain Names. 540 Search lists are a Domain Name mechanism studied in "SSAC Advisory 541 on DNS 'Search List' Processing" [SAC 064]. One of the particular 542 use cases related to this topic is the issuance of search lists via 543 DHCP and then used by any user-client protocol implementation. This 544 emphasizes an interoperability consideration for how Domain Names 545 are treated in different protocols, not just among implementations of 546 one protocol. 548 The definition of a Fully Qualified Domain Name has two forms. The 549 discussion over FQDN involved human-readable names. The principle 550 question is whether to require the terminating dot or to assume it 551 when the end of an input string is hit. Some protocol clients will 552 silently add a dot when a user types in a name to a command line, 553 others will do so if there is a dot inside the name. [No reference] 554 But some definitions, such as the one in the previously referenced 555 SSAC advisory, require the terminating dot to be included before a name 556 is considered to be fully qualified. 558 The Special Use Domain Names registry lists Domain Names that are to 559 be treated in a manner inconsistent with the DNS normal processing 560 rules. This registry contains Domain Names regardless of whether the 561 name is a DNS domain name and regardless whether the name is a 562 top-level (domain) name [RFC 819] or is positioned elsewhere in the 563 tree structure. 565 These are reasons this document is needed. The reason for the 566 confusion over what's a legal domain name stems from 567 application-defined restrictions. For example, using a one-label 568 domain name ("dotless") for sending email is not a problem with the 569 DNS nor the name in concept, but is a problem for mail implementations 570 that expect more than one label. (One-label names may be assumed to 571 be in ARPA host table format.) The "IAB Statement: Dotless Domains 572 Considered Harmful" [IAB Stmt] elaborates. 574 5. Acknowledgements 576 The definition of domain names was lifted from an email from Lyman 577 Chapin. The URL for that message is (combine the two lines): 579 https://mailarchive.ietf.org/arch/msg/inip-discuss/ 580 cqvFTt3_ve9EBOQfA9TlcqgTIFc 582 The definition has since been removed from this draft. 584 Comments from Andrew Sullivan, Paul Hoffman, George Michaelson, 585 Kevin Darcy, Joe Abley, Jim Reid, Tony Finch, Robert Edmonds, 586 hellekin, Stephane Bortzmeyer, Ray Bellis, Bob Harold, Alec Muffett, 587 Stuart Cheshire, Dave Thaler and a growing list of others I am losing 588 track of. Not to imply endorsement. 590 6. IANA Considerations 592 None. 594 7. Security Considerations 596 Nothing direct. This document proposes a definition of the term 597 "Domain Name" and surveys how it has been variously applied. In 598 some sense, loosely defined terms give rise to security hazards. 599 Beyond that, there is no impact of "security." 601 8. References 603 Many references are in-line throughout the text with titles to ease 604 comprehension of the prose. All documents cited are listed here. 605 Whether there is a normative/informative split will depend what, if 606 any, track this document is processed. For now, consider this a 607 reading list on the topic. 609 ANSIX34 American National Standards Institute (formerly United 610 States of America Standards Institute), "USA Code for 611 Information Interchange", ANSI X3.4-1968, 1968 613 RFC 20 Cerf, V., "ASCII format for network interchange", STD 80, 614 RFC 20, DOI 10.17487/RFC0020, October 1969, 615 . 617 RFC 788 Postel, J., "Simple Mail Transfer Protocol", RFC 788, DOI 618 10.17487/RFC0788, November 1981, 619 . 621 RFC 799 Mills, D., "Internet name domains", RFC 799, DOI 622 10.17487/RFC0799, September 1981, 623 . 625 RFC 801 Postel, J., "NCP/TCP transition plan", RFC 801, DOI 626 10.17487/RFC0801, November 1981, 627 . 629 RFC 805 Postel, J., "Computer mail meeting notes", RFC 805, DOI 630 10.17487/RFC0805, February 1982, 631 . 633 RFC 819 Postel, J., "Computer mail meeting notes", RFC 805, DOI 634 10.17487/RFC0805, February 1982, 635 . 637 RFC 882 Mockapetris, P., "Domain names: Concepts and facilities", 638 RFC 882, DOI 10.17487/RFC0882, November 1983, 639 . 641 RFC 883 Mockapetris, P., "Domain names: Implementation 642 specification", RFC 883, DOI 10.17487/RFC0883, November 643 1983, . 645 RFC 952 Mockapetris, P., "Domain names: Implementation 646 specification", RFC 883, DOI 10.17487/RFC0883, November 647 1983, . 649 RFC 959 Postel, J. and J. Reynolds, "File Transfer Protocol", STD 650 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 651 . 653 RFC 1034 Mockapetris, P., "Domain names - concepts and facilities", 654 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 655 . 657 RFC 1035 Mockapetris, P., "Domain names - implementation and 658 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 659 November 1987, . 661 RFC 1123 Braden, R., Ed., "Requirements for Internet Hosts - 662 Application and Support", STD 3, RFC 1123, DOI 663 10.17487/RFC1123, October 1989, 664 . 666 RFC 1945 Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 667 Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 668 10.17487/RFC1945, May 1996, 669 . 671 RFC 2131 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 672 DOI 10.17487/RFC2131, March 1997, 673 . 675 RFC 2860 Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 676 Understanding Concerning the Technical Work of the Internet 677 Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, 678 June 2000, . 680 RFC 3397 Aboba, B. and S. Cheshire, "Dynamic Host Configuration 681 Protocol (DHCP) Domain Search Option", RFC 3397, 682 DOI 10.17487/RFC3397, November 2002, 683 . 685 RFC 3492 Costello, A., "Punycode: A Bootstring encoding of Unicode 686 for Internationalized Domain Names in Applications (IDNA)", 687 RFC 3492, DOI 10.17487/RFC3492, March 2003, 688 . 690 RFC 3493 Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 691 Stevens, "Basic Socket Interface Extensions for IPv6", 692 RFC 3493, DOI 10.17487/RFC3493, February 2003, 693 . 695 RFC 3596 Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 696 "DNS Extensions to Support IP Version 6", RFC 3596, 697 DOI 10.17487/RFC3596, October 2003, 698 . 700 RFC 3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 701 Resource Identifier (URI): Generic Syntax", STD 66, RFC 702 3986, DOI 10.17487/RFC3986, January 2005, 703 . 705 RFC 4251 Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 706 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 707 January 2006, . 709 RFC 4290 Klensin, J., "Suggested Practices for Registration of 710 Internationalized Domain Names (IDN)", RFC 4290, DOI 711 10.17487/RFC4290, December 2005, 712 . 714 RFC 4702 Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 715 Configuration Protocol (DHCP) Client Fully Qualified Domain 716 Name (FQDN) Option", RFC 4702, DOI 10.17487/RFC4702, 717 October 2006, . 719 RFC 5198 Klensin, J. and M. Padlipsky, "Unicode Format for Network 720 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 721 . 723 RFC 5280 Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 724 Housley, R., and W. Polk, "Internet X.509 Public Key 725 Infrastructure Certificate and Certificate Revocation 726 List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 727 May 2008, . 729 RFC 5321 Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 730 10.17487/RFC5321, October 2008, 731 . 733 RFC 5890 Klensin, J., "Internationalized Domain Names for 734 Applications (IDNA): Definitions and Document Framework", 735 RFC 5890, DOI 10.17487/RFC5890, August 2010, 736 . 738 RFC 6055 Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts 739 on Encodings for Internationalized Domain Names", RFC 6055, 740 DOI 10.17487/RFC6055, February 2011, 741 . 743 RFC 6761 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 744 RFC 6761, DOI 10.17487/RFC6761, February 2013, 745 . 747 RFC 6762 Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 748 DOI 10.17487/RFC6762, February 2013, 749 . 751 RFC 6943 Thaler, D., Ed., "Issues in Identifier Comparison for 752 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, 753 May 2013, . 755 RFC 7686 Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 756 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015, 757 . 759 Diestel Diestel, R., "Graph Theory", Springer-Verlag, Heidelberg 760 Graduate Texts in Mathematics, Volume 173 ISBN 761 978-3-642-14278-9, July 2010 (2005, 2000, 1997), 762 764 SAC064 ICANN Security and Stability Committee, "SSAC Advisory on 765 Search List Processing", SAC064, February 2014, 766 768 RENDEV Anonymous, "Tor Rendezvous Specification", Undated, 769 772 OHOST Nick Mathewson, "Special Hostnames in Tor", Undated, 773 776 IABStmt IAB, 2013, 780 IEEE1003 The Open Group Base Specifications Issue 7, IEEE Std 781 1003.1, 2013 Edition, Copyright 2001-2013 The IEEE 782 and The Open Group, 783 786 WINSOCK URL only, 789 9. Author's Address 791 Edward Lewis 792 ICANN 793 801 17th Street NW 794 Suite 401 795 Washington DC, 20006 US 796 edward.lewis@icann.org 798 Lewis Expires January 1, 2016 [Page 1]