idnits 2.17.1 draft-lewis-domain-names-06.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 848 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 == Line 303 has weird spacing: '...on, on the ...' == Line 304 has weird spacing: '...taining a st...' == Line 305 has weird spacing: '...ed host can ...' == Line 306 has weird spacing: '... This stand...' == Line 307 has weird spacing: '...OW data is t...' == 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 (March 27, 2017) is 2558 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 93 looks like a reference -- Missing reference section? 'RFC 7686' on line 95 looks like a reference -- Missing reference section? 'RFC 2860' on line 99 looks like a reference -- Missing reference section? 'RFC 6055' on line 415 looks like a reference -- Missing reference section? 'RFC 6943' on line 108 looks like a reference -- Missing reference section? 'IEN-116' on line 171 looks like a reference -- Missing reference section? 'RFC-799' on line 171 looks like a reference -- Missing reference section? 'RFC-819' on line 171 looks like a reference -- Missing reference section? 'RFC-830' on line 171 looks like a reference -- Missing reference section? 'RFC-882' on line 176 looks like a reference -- Missing reference section? 'RFC-883' on line 176 looks like a reference -- Missing reference section? 'MWDICT' on line 293 looks like a reference -- Missing reference section? 'RFC724' on line 299 looks like a reference -- Missing reference section? 'TONR15' on line 314 looks like a reference -- Missing reference section? 'WIKIAR' on line 315 looks like a reference -- Missing reference section? 'RFC 3596' on line 374 looks like a reference -- Missing reference section? 'RFC 5321' on line 406 looks like a reference -- Missing reference section? 'RFC 3986' on line 420 looks like a reference -- Missing reference section? 'RFC 5890' on line 452 looks like a reference -- Missing reference section? 'RFC 4290' on line 464 looks like a reference -- Missing reference section? 'RENDEV' on line 481 looks like a reference -- Missing reference section? 'OHOST' on line 482 looks like a reference -- Missing reference section? 'RFC 5280' on line 494 looks like a reference -- Missing reference section? 'RFC 6762' on line 503 looks like a reference -- Missing reference section? 'IEEE1003.1' on line 520 looks like a reference -- Missing reference section? 'WINSOCK' on line 521 looks like a reference -- Missing reference section? 'RFC 4251' on line 530 looks like a reference -- Missing reference section? 'RFC 959' on line 541 looks like a reference -- Missing reference section? 'RFC 2131' on line 546 looks like a reference -- Missing reference section? 'SAC 064' on line 588 looks like a reference -- Missing reference section? 'RFC 819' on line 609 looks like a reference -- Missing reference section? 'IABSTMT' on line 619 looks like a reference Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 34 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: September 27, 2017 Date: March 27, 2017 4 Intended Status: unknown 6 Domain Names, A Case for Clarifying 7 draft-lewis-domain-names-06.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 September 27, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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 should be removed prior to publication. 72 Note on changes from earlier edition: 74 Removal of a discussion on defining "Domain Name." 76 1. Introduction 78 What is the motivation behind the document and what is the anticipated 79 result? 81 1.1 Motivation for this Document 83 Why bother to define Domain Names now, three decades after the 84 earliest mentions in RFC documents? There are many examples of 85 names as identifiers in existence, a lot of running code. There is 86 a large industry built on management of names as well, a lot of 87 financial investment made. Would not a definition appearing now be 88 merely an academic exercise or worse, a disruption to what seems to 89 be a 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" [RFC 6761] and the process of adding 94 "ONION" to that registry, as described in "The '.onion' Special-Use 95 Domain Name" [RFC 7686]. 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" [RFC 2860], 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" [RFC 6055] 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" [RFC 6943] documents issues related 109 to the same conversion as related to evaluating security policies. The 110 presence of these studies suggests a need to examine the architecture 111 of naming and identifiers. 113 The beneficiaries of such work include both the developers of software 114 that makes use of names and identifiers. A single piece of code could 115 be used in different naming environments if the code can determine how 116 to process a name. With code reusable across different environments, 117 another benefit are innovators exploring new means of identifying 118 objects. 120 1.2 Goal 122 The work ahead has the ingredients of a "clarification" - a loose 123 or 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 warranted. 128 1.3 Background 130 Two or three decades into the history of Domain Names, a popular 131 notion has taken hold that Domains Names were defined and specified 132 in the definition of the Domain Name System (DNS). There are two 133 documents that form the basic definition of the DNS, "Domain names - 134 concepts and facilities" and "Domain names - implementation and 135 specification" referred to as RFC 1034 and RFC 1035, respectively. 136 (Note that there is another pair of Request for Comments documents 137 with the same titles that precede RFC 1034 and RFC 1035, those were 138 declared obsolete in favor of the newer documents.) Together RFC 1034 139 and RFC 1035 form STD 13, a full standard cataloged by the RFC Editor. 140 The definitions of DNS domain names within RFC 1034 and RFC 1035 have 141 become the apparently-authoritative source for discussions on what is 142 a Domain Name. 144 Throughout this document the term "Domain Names" is capitalized to 145 emphasize the concept of the names and DNS is used to describe the 146 protocol and algorithms described in STD 13, including any applicable 147 updates, related standards track documents and experimental track 148 documents. 150 The term domain is a generic term, there are many naming systems in 151 existence. The use of the term Domain Names in this document refers 152 to the roughly-defined set of protocols and their applications' use 153 of a naming structure that is prevalent amongst many protocols defined 154 in IETF RFC documents. 156 The truth is, STD 13 does not define Domain Names, the documents define 157 only how Domain Names are used and processed in the DNS. However, the 158 way in which the RFC documents read seem to lend to the confusion. 160 RFC 1034, section 2 begins with this text: 162 "This RFC introduces domain style names, their use for Internet mail 163 and host address support, and the protocols and servers used to 164 implement domain name facilities." 166 Which seems to indicate that RFC 1034 is the origin of Domain Names. 167 Immediately following is section 2.1, entitled "The history of domain 168 names" which includes the following text. 170 "The result was several ideas about name spaces and their management 171 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a 172 common thread was the idea of a hierarchical name space, with the 173 hierarchy roughly corresponding to organizational structure, and names 174 using "." as the character to mark the boundary between hierarchy 175 levels. A design using a distributed database and generalized 176 resources was described in [RFC-882, RFC-883]. Based on experience 177 with several implementations, the system evolved into the scheme 178 described in this memo." 180 The DNS as it is known today did not invent Domain Names. Work on the 181 Simple Mail Transfer Protocol preceding the DNS mentions domain names, 182 and even it was not the origin of the concept. The DNS is not even 183 the first attempt at an Internet naming system (described in RFC 819 184 "The Domain Naming Convention for Internet User Applications"). 186 One important phrase to keep in mind is: 188 "To simplify implementations," 190 which appears in both RFC 1034 and RFC 1035 as well as their 191 predecessors RFC 882 and RFC 883. This gives credence to the notion 192 that Domain Names exist beyond the DNS. 194 2. Emergence of Domain Names 196 The first effort taken, in preparation for writing this document, was 197 to scan for the earliest use of the term "domain name" or "name domain". 198 This work is detailed in the following section, but, as noted in 199 private email by reviews of early versions of the document, gave the 200 impression that Domain Names were somehow a by-product of the effort to 201 develop electronic mail. To challenge the notion that email begat 202 domain names, a search through RFC documents for the use of the term 203 resolve as it applies to Domain Names was also done. 205 2.1 The term "Domain Name" itself 207 Domain Names emerged from the need to build a hierarchy around the 208 growing number of identified hosts exchanging email. RFC 788, "SIMPLE 209 MAIL TRANSFER PROTOCOL", explains, in its section 3.7: 211 "At some not too distant future time it might be necessary to 212 expand the mailbox format to include a region or name domain 213 identifier. There is quite a bit of discussion on this at 214 present, and is likely that SMTP will be revised in the future to 215 take into account naming domains." 217 Knowing the origins of a concept helps setting the correct boundaries 218 for discussion. The past isn't meant to restrict the future but 219 meant to help provide a context, include forgotten ideas, and help 220 identify rational for scope creep. 222 RFC 799 "Internet Name Domains" has (arguably) the first formation of 223 what is a Domain Name: 225 "In its most general form, a standard internet mailbox name has 226 the syntax 228 .@ , 230 where is the name of a user known at the host in the 231 name domain ." 233 Prior to this, domain referred to principally an administrative 234 domain, such as the initial organizations involved in networks at the 235 time. 237 RFC 801 "NCP/TCP TRANSITION PLAN" contains this, indicating the 238 passage from the host tables: 240 "It might be advantageous to do away with the host name table and 241 use a Name Server instead, or to keep a relatively small table as 242 a cache of recently used host names." 244 RFC 805 "Computer Mail Meeting Notes" contains this: 246 "The conclusion in this area was that the current "user@host" mailbox 247 identifier should be extended to 'user@host.domain' where 'domain' 248 could be a hierarchy of domains." 250 RFC 819 "The Domain Naming Convention for Internet User Applications" 251 contains this: 253 "A decision has recently been reached to 254 replace the simple name field, "", by a composite name field, 255 '' " 257 A domain name began to take on its current form: 259 "Internet Convention: Fred@F.ISI.ARPA" 261 In addition, "simple name" is defined as what we now call a label, and 262 a "complete (fully qualified) name" is defined as "concatenation of 263 the simple names of the domain structure tree nodes starting with its 264 own name and ending with the top level node name". Noticeably 265 absent is a terminating dot or any mention or representation of a 266 root. 268 RFC 819 defines ARPA as a top-level name (as opposed to top-level 269 domain name). This is an early mention of the role of top-level 270 names. 272 This walk thru history relies solely on the record left behind 273 inside RFC documents. The precise chain of events is likely slightly 274 different and nuanced. The point of the exercise is to show that 275 Domain Names are a concept the emerged over time, spawned the DNS 276 with its domain names, a definition of host names derived from the 277 host tables, and was heavily influenced by SMTP as the driving 278 application. The definition of the FTP protocol, originally defined 279 in RFC 959 "FILE TRANSFER PROTOCOL", never mentions hosts, domains or 280 host names. But no formal definition of Domain Names has been 281 written and recorded. 283 2.2 The term "Resolve" 285 As much as Domain Names were influenced by SMTP, electronic mail was 286 not the origin of the Domain Names concepts, this was a hypothesis 287 came from a personal view of the early days of Internet work. To test 288 this, a look for the use of the term "resolve" or "resolution" was 289 conducted in early (arbitrarily defined as pre-1000) RFC documents. 291 The term "resolve" appears numerous times, but in a different context. 292 "Resolve" has many meanings, consulting a dictionary, such as Merriam 293 Webster's dictionary [MWDICT], none which seem to match the use 294 associated with domain names. For example, a committee can resolve 295 to solve a certain question. This use of "resolve" occurred numerous 296 times in early RFC documents unrelated to Domain Names. 298 In "Proposed Official Standard for the Format of ARPA Network Messages" 299 [RFC724] the term resolve was used in the sense of mapping an 300 identifier into an address or something actionable. A section on 301 Semantics (C), Address fields (1.), General (a.), bullet 1 states: 303 "s are used to refer to a location, on the ARPANET, 304 containing a stored address list. The should 305 contain text which the referenced host can resolve to a 306 file. This standard is not a protocol and so does not 307 prescribe HOW data is to be retrieved from the file." 309 Private email to the (reachable) authors of the document pointed to 310 the use of "resolve" stemming from work on Programming Languages and 311 Compiler Theory. In that field of work, variables are associated 312 with machine addresses when linking code. Note: work on fully 313 documenting this is incomplete. One reason is that while there are 314 formal papers on "A Theory of Name Resolution" [TONR15], the term 315 resolution is used in the field of "Automated Reasoning" [WIKIAR]. 317 While determining the first use of the term resolve or resolution may 318 be hitting against the law of diminishing returns, it is clear that 319 there is a wealth of work that has gone into the concept of Domain 320 Names well before the DNS came into being. 322 3. Dialects, so to speak, of Domain Names 324 Subtypes of Domain Names have come to be defined for different 325 protocols, evolving and sometimes building on previous definitions. 327 3.1 Domain Names as Restricted for DNS 329 The DNS protocol places size restrictions on Domain Names and defines 330 rules for matching domain names, treating sets of Domain Names as 331 equivalent to each other. (This matching refers to treating upper 332 case and lower case ASCII letters as equivalent.) The DNS defines 333 the format used to transmit the names across the network as well as 334 rules for displaying them inside text zone files. The DNS creates 335 the notion that names are assigned by an authority per zone. 337 Placing size restrictions on Domain Names is significant in reducing 338 the overall population of names that can be represented in the DNS. 339 The matching rules have the effect of creating (to use a term from 340 graph theory) cliques, distorting the tree-nature of the Domain Name 341 graph. A clique is a completely connected sub-graph implying cyclic 342 paths, a tree is a graph that is acyclic. In sum, the treatment of 343 ASCII (and only ASCII) cases as equivalent is a distortion of the 344 Domain Name hierarchy. 346 DNS defines two formats for domain names. One is the "on-the-wire" 347 format used inside messages, a flags-and-length octet followed by 348 some count of octets for each label with the final length of 0 349 representing the root. The other is a version that can be rendered 350 in printable ASCII characters, complete with a means to represent 351 other characters via an escape sequence. This does not alter the 352 Domain Name concept but has implications when it comes to 353 interoperating with other protocol definitions of their domain name 354 use. 356 DNS assumes that there is, in concept, a central authority creating 357 names within the DNS management structure (called a zone). Although 358 the DNS does not define how a central authority is implemented nor 359 how it coins names, the names have to come from a single point to 360 appear in a zone. There are other means for claiming names, an 361 example will be mentioned later. 363 DNS domain names could appear to be the same as address literals, such 364 as "192.0.2.1" or "0:0:0:0:0:FFFF::192.0.2.1". Such DNS domain 365 names are not used for two reasons. Applications expecting a 366 Domain Name (as a comment line parameter as an example) would 367 opt to treat the string as an address literal and would therefore 368 not look for the string in the DNS domain name space. The management 369 model of the DNS would prefer to aggregate (as in routing) addresses 370 belonging together in the same zone, resulting in labels appearing in 371 reverse order. E.g., the network address 192.0.2.1 would be 372 represented by a DNS domain name as "1.2.0.192.in-addr.arpa." 373 as described in RFC 1035. For IPv6, the convention used is documented 374 in "DNS Extensions to Support IP Version 6" [RFC 3596], section 2.5. 376 See also "Issues in Identifier Comparison for Security Purposes" [RFC 377 6943] section 3.1, "Host Names", in particular, section 3.1.1 and 3.1.2 378 on address literals, and section 4.1, "Conflation." 380 DNS domain names have become the dominant definition of domain names 381 due to the success (scale) of the DNS on the public Internet. Many 382 protocols interact with the DNS but instead of supporting the 383 complete definition of DNS domain names, the protocols rely on a 384 subset more commonly called host names. 386 3.2 Host Names 388 Work on the definition of a host name began well before the issuance 389 of the STD 13 documents defining DNS. The rules for the Preferred 390 Syntax in RFC 1034 conform to the host name rules outlined in RFC 391 952. The host name definition was presented again in RFC 1123 392 "Requirements for Internet Hosts -- Application and Support" (which 393 is part of STD 3). In section 2.1 of RFC 1123, one (of two mentions) 394 definition of host name is presented, noting that the definition is a 395 relaxation of what is in RFC 952. 397 Host names are subsets of DNS domain names in the sense that the 398 character set is limited. In particular, only "let" (i.e., 399 presumably letters a-z), "digits" and "hyphen" can be used, with 400 hyphen only internal to a label. (This description is meant to be 401 illustrative, not normative. See the grammar presented on page 5 of 402 RFC 952 for specifics.) RFC 1945 "Hypertext Transfer Protocol -- 403 HTTP/1.0", Section 3.2.2 "http URL" specifically references section 404 2.1 of RFC 1123. The reference is explicit. 406 "Simple Mail Transfer Protocol" [RFC 5321] refers to RFC 1035 for a 407 definition of domain names but includes text close to what is in the 408 previous paragraph, noting that domain names as used in SMTP refer to 409 both hosts and to other entities. RFC 5321 updates RFC 1123, but 410 does not cite the latter for a definition of host names. RFC 5321 411 additionally requires brackets to surround address literals, 412 referring to the use case as an "alternative to a domain name." 414 See also "IAB Thoughts on Encodings for Internationalized Domain Names" 415 [RFC 6055], particularly section 3 entitled "Use of Non-ASCII in DNS" 416 for more thoughts on host names. 418 3.3 URI Authority and Domain Names 420 In "Uniform Resource Identifier (URI): Generic Syntax" [RFC 3986], also 421 known as STD 66, mentions in its section 3.2.2 (page 20) that the host 422 subcomponent of the URI Authority (section 3.2) "should conform to the 423 DNS syntax". This comes after discussion that the host subcomponent 424 is not strongly tied to the DNS, i.e., names can be managed via a 425 concept other than the DNS. There's no discussion on the rationale 426 but this enables the reuse of code parsing and marshalling the host 427 subcomponent between different Domain Name environments. 429 This reinforces the notion that there's a need to understand how Domain 430 Names interoperate amongst protocols and applications. And reinforces 431 the need to derive or make explicit a way for client software to know 432 how to resolve a name, that is, convert a name into a network address. 434 3.4 Internet Protocol Address Literals 436 The above definition includes address literals such as 192.0.2.1 for 437 IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these 438 qualify as Domain Names. In some protocols, these domain names are 439 specified as being preceded by a "#" (find this and cite) or encased 440 in square brackets "[" and "]" (SMTP mentioned already). In the DNS, 441 as previously described in section 3.1, they are represented per 442 appropriate conventions. 444 3.5 Internationalized Domain Names in Applications 446 The original uses of Domain Names (such as DNS domain names 447 and host names) assumed the ASCII character set. Specifically, 448 making the labels case insensitive prohibited a straightforward use 449 of any method of representation of non-ASCII characters. 451 "Internationalized Domain Names for Applications (IDNA): Definitions 452 and Document Framework" [RFC 5890], with associated other documents, 453 defines IDNA2008 as a convention for handling non-ASCII characters in 454 DNS domain names. In figure 1 of that document, the sets of legal DNS 455 domain name formats are defined. Noted in the footnotes of the 456 figure, applications unaware of IDNA2008 cannot distinguish the subsets 457 defined by the document meaning this definition is not an alteration 458 of Domain Names, but, like host names, yet another subset of DNS 459 domain names. 461 3.6 Restricted for DNS Registration 463 "Suggested Practices for Registration of Internationalized Domain Names 464 (IDN)" [RFC 4290] presents reasons why DNS domain name registration 465 is restricted in the context of IDN. (That RFC refers to an 466 older form than IDNA2008, but the concepts still apply.) This is yet 467 another convention related to DNS domain names, excluding names that 468 would lead to undesirable outcomes. 470 3.7 Tor Network Names 472 The Tor network is an activity organized by the Tor Project, Inc., 473 described on its main web page 474 "https://www.torproject.org/index.html.en". 476 One component of the Tor network name space are Domain Names ending 477 in ".onion". (There are other suffixes in use, but it isn't very 478 clear how they are used, defined or whether they are active.) 480 The way in which Domain Names are used in Tor is described in two web 481 documents "Tor Rendezvous Specification" [RENDEV] and "Special 482 Hostnames in Tor" [OHOST] available from the project's website. 484 Syntactically, a Tor domain name fits within the DNS domain name 485 definition but the manner of assignment is different in a manner 486 incompatible with the DNS. (Not better or worse, still significantly 487 different.) Tor domain names are derived from cryptographic keys and 488 organized by distributed hash tables, instead of assigned by a central 489 authority per zone. 491 3.8 X.509 493 "Internet X.509 Public Key Infrastructure Certificate and Certificate 494 Revocation List (CRL) Profile" [RFC 5280], section 4.2.1.6 "Subject 495 Alternative Name" a dNSName is defined to be a host name, with the 496 further restriction that the name " " cannot be used. (The subtle 497 irony is that a name consisting of just a blank would hardly qualify 498 as a Domain Name.) 500 3.9 Multicast DNS 502 Multicast DNS uses a name space ending with ".local." as described in 503 "Multicast DNS" [RFC 6762]. The rules for Multicast DNS domain names 504 differ from DNS domain names. Multicast DNS domain names are encoded 505 as Net-Unicode as defined in RFC5198 " Unicode Format for Network 506 Interchange" with the DNS domain name tradition of case folding the 507 ASCII letters when matching names. Appendix F of RFC 6762 gives an 508 explanation of why the punycode algorithm is not used. 510 3.10 /etc/hosts 512 The precursor to DNS, host tables, still exists in remnants in many 513 operating systems. There are library functions, used by applications 514 to resolve DNS domain names, that can return names of arbitrary 515 length (meaning, for example longer than what DNS domain names are 516 defined to be). 518 RFC 3493, "Basic Socket Interface Extensions for IPv6", addresses 519 this in Section 6, further documentation can be found as part of 520 The Open Group Base Specifications Issue 7 [IEEE1003.1] and Microsoft 521 Winsock Functions [WINSOCK]. 523 3.11 Other Protocols 525 This section is used to list (some) other protocols that use Domain 526 Names but in general do not impose any other restrictions that what 527 has been mentioned above. 529 SSH, documented in "The Secure Shell (SSH) Protocol Architecture" 530 [RFC 4251] uses host names, using the name when storing public keys 531 of hosts. SSH clients, not necessarily the protocol, illustrate how 532 applications juggle the different forms of Domain Names. SSH can be 533 invoked to open a secure shell with a host via its DNS domain 534 name/host name or it can be used to open a secure shell with a host 535 via its Multicast DNS domain name. Or, many others, including name of a 536 purely local, per-user scope. (Note that SSH does not distinguish 537 between DNS names and Multicast DNS domain names in the protocol 538 definition, the difference is handled in resolution libraries belonging 539 to the computing platform.) 541 FTP, defined in "FILE TRANSFER PROTOCOL (FTP)" [RFC 959], is silent on 542 domain names but client implementations of the protocol behave as SSH 543 clients, being un aware the differences between definitions of Domain 544 Names. 546 DHCP, defined in "Dynamic Host Configuration Protocol" [RFC 2131], 547 includes domain names in its Domain Search Option [RFC 3397 "Dynamic 548 Host Configuration Protocol (DHCP) Domain Search Option"]. The 549 encoding of Domain Names used is the on-the-wire format of the DNS, 550 using DNS-defined message compression. DHCP handles Domain Names in 551 other options such as in RFC 4702 defined "The DHCP Client FQDN 552 Option", in the same format. The significance of this is that most 553 other protocols represent DNS domain names or host names in a human 554 readable form, DHCP is using the machine-friendly format. 556 3.12 Other others 558 If there is a use of Domain Names not listed here it is merely an 559 omission. The goal in this document is to provide a survey that 560 is sufficient to avoid hand-waving arguments, recognizing the 561 diminishing return in trying to build a complete roster of uses 562 of Domain Names. If there are omissions that ought to be included, 563 please send references for the use case to the author (while this is 564 an Internet Draft, that is). 566 4. Interoperability Considerations 568 Any single protocol can define a format for a conceptual Domain Name. 569 Examples given above show that many protocols have done so. From the 570 examples, it is clear that the way in which protocols have interpreted 571 Domain Names has varied, leading to, at least, user interfaces having 572 to have built-in intelligence when handling names and, at worst, a 573 growing confusion over how the Domain Name space is to be managed. 575 When protocols having different formats and rules for Domain Names 576 interact, software implementing the protocols translate one protocol's 577 domain name format to another's format. Even when the translation is 578 straightforward, software often fails to handle error conditions well. 579 (Is there a citation for that?) 581 Often the clash of definitions impacts the design of a new protocol 582 and/or an extension of a protocol. For example, adding non-ASCII 583 domain names has to be done with backwards compatibility with an 584 installed base of ASCII-assuming code. This clash can inhibit new 585 uses of Domain Names. 587 Search lists are a Domain Name mechanism studied in "SSAC Advisory 588 on DNS 'Search List' Processing" [SAC 064]. One of the particular 589 use cases related to this topic is the issuance of search lists via 590 DHCP and then used by any user-client protocol implementation. This 591 emphasizes an interoperability consideration for how Domain Names 592 are treated in different protocols, not just among implementations of 593 one protocol. 595 The definition of a Fully Qualified Domain Name has two forms. The 596 discussion over FQDN involved human-readable names. The principle 597 question is whether to require the terminating dot or to assume it 598 when the end of an input string is hit. Some protocol clients will 599 silently add a dot when a user types in a name to a command line, 600 others will do so if there is a dot inside the name. [No reference] 601 But some definitions, such as the one in the previously referenced 602 SSAC advisory, require the terminating dot to be included before a name 603 is considered to be fully qualified. 605 The Special Use Domain Names registry lists Domain Names that are to 606 be treated in a manner inconsistent with the DNS normal processing 607 rules. This registry contains Domain Names regardless of whether the 608 name is a DNS domain name and regardless whether the name is a 609 top-level (domain) name [RFC 819] or is positioned elsewhere in the 610 tree structure. 612 These are reasons this document is needed. The reason for the 613 confusion over what's a legal domain name stems from 614 application-defined restrictions. For example, using a one-label 615 domain name ("dotless") for sending email is not a problem with the 616 DNS nor the name in concept, but is a problem for mail implementations 617 that expect more than one label. (One-label names may be assumed to 618 be in ARPA host table format.) The "IAB Statement: Dotless Domains 619 Considered Harmful" [IABSTMT] elaborates. 621 5. Acknowledgements 623 Comments from Andrew Sullivan, Paul Hoffman, George Michaelson, 624 Kevin Darcy, Joe Abley, Jim Reid, Tony Finch, Robert Edmonds, 625 hellekin, Stephane Bortzmeyer, Ray Bellis, Bob Harold, Alec Muffett, 626 Stuart Cheshire, Dave Thaler, Niall O'Reilly and a growing list of 627 others I am losing track of. Not to imply endorsement. 629 6. IANA Considerations 631 None. 633 7. Security Considerations 635 Nothing direct. This document proposes a definition of the term 636 "Domain Name" and surveys how it has been variously applied. In 637 some sense, loosely defined terms give rise to security hazards. 638 Beyond that, there is no impact of "security." 640 8. References 642 Many references are in-line throughout the text with titles to ease 643 comprehension of the prose. All documents cited are listed here. 644 Whether there is a normative/informative split will depend what, if 645 any, track this document is processed. For now, consider this a 646 reading list on the topic. 648 ANSIX34 American National Standards Institute (formerly United 649 States of America Standards Institute), "USA Code for 650 Information Interchange", ANSI X3.4-1968, 1968 652 DNSBIND Cricket Liu, Paul Albitz, DNS and BIND (5th Edition), 653 O'Reilly Media, Inc., 2006 655 RFC 20 Cerf, V., "ASCII format for network interchange", STD 80, 656 RFC 20, DOI 10.17487/RFC0020, October 1969, 657 . 659 RFC 788 Postel, J., "Simple Mail Transfer Protocol", RFC 788, DOI 660 10.17487/RFC0788, November 1981, 661 . 663 RFC 799 Mills, D., "Internet name domains", RFC 799, DOI 664 10.17487/RFC0799, September 1981, 665 . 667 RFC 801 Postel, J., "NCP/TCP transition plan", RFC 801, DOI 668 10.17487/RFC0801, November 1981, 669 . 671 RFC 805 Postel, J., "Computer mail meeting notes", RFC 805, DOI 672 10.17487/RFC0805, February 1982, 673 . 675 RFC 819 Postel, J., "Computer mail meeting notes", RFC 805, DOI 676 10.17487/RFC0805, February 1982, 677 . 679 RFC 882 Mockapetris, P., "Domain names: Concepts and facilities", 680 RFC 882, DOI 10.17487/RFC0882, November 1983, 681 . 683 RFC 883 Mockapetris, P., "Domain names: Implementation 684 specification", RFC 883, DOI 10.17487/RFC0883, November 685 1983, . 687 RFC 952 Mockapetris, P., "Domain names: Implementation 688 specification", RFC 883, DOI 10.17487/RFC0883, November 689 1983, . 691 RFC 959 Postel, J. and J. Reynolds, "File Transfer Protocol", STD 692 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 693 . 695 RFC 1034 Mockapetris, P., "Domain names - concepts and facilities", 696 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 697 . 699 RFC 1035 Mockapetris, P., "Domain names - implementation and 700 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 701 November 1987, . 703 RFC 1123 Braden, R., Ed., "Requirements for Internet Hosts - 704 Application and Support", STD 3, RFC 1123, DOI 705 10.17487/RFC1123, October 1989, 706 . 708 RFC 1945 Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 709 Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 710 10.17487/RFC1945, May 1996, 711 . 713 RFC 2131 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 714 DOI 10.17487/RFC2131, March 1997, 715 . 717 RFC 2860 Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 718 Understanding Concerning the Technical Work of the Internet 719 Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, 720 June 2000, . 722 RFC 3397 Aboba, B. and S. Cheshire, "Dynamic Host Configuration 723 Protocol (DHCP) Domain Search Option", RFC 3397, 724 DOI 10.17487/RFC3397, November 2002, 725 . 727 RFC 3492 Costello, A., "Punycode: A Bootstring encoding of Unicode 728 for Internationalized Domain Names in Applications (IDNA)", 729 RFC 3492, DOI 10.17487/RFC3492, March 2003, 730 . 732 RFC 3493 Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 733 Stevens, "Basic Socket Interface Extensions for IPv6", 734 RFC 3493, DOI 10.17487/RFC3493, February 2003, 735 . 737 RFC 3596 Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 738 "DNS Extensions to Support IP Version 6", RFC 3596, 739 DOI 10.17487/RFC3596, October 2003, 740 . 742 RFC 3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 743 Resource Identifier (URI): Generic Syntax", STD 66, RFC 744 3986, DOI 10.17487/RFC3986, January 2005, 745 . 747 RFC 4251 Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 748 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 749 January 2006, . 751 RFC 4290 Klensin, J., "Suggested Practices for Registration of 752 Internationalized Domain Names (IDN)", RFC 4290, DOI 753 10.17487/RFC4290, December 2005, 754 . 756 RFC 4702 Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 757 Configuration Protocol (DHCP) Client Fully Qualified Domain 758 Name (FQDN) Option", RFC 4702, DOI 10.17487/RFC4702, 759 October 2006, . 761 RFC 5198 Klensin, J. and M. Padlipsky, "Unicode Format for Network 762 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 763 . 765 RFC 5280 Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 766 Housley, R., and W. Polk, "Internet X.509 Public Key 767 Infrastructure Certificate and Certificate Revocation 768 List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 769 May 2008, . 771 RFC 5321 Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 772 10.17487/RFC5321, October 2008, 773 . 775 RFC 5890 Klensin, J., "Internationalized Domain Names for 776 Applications (IDNA): Definitions and Document Framework", 777 RFC 5890, DOI 10.17487/RFC5890, August 2010, 778 . 780 RFC 6055 Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts 781 on Encodings for Internationalized Domain Names", RFC 6055, 782 DOI 10.17487/RFC6055, February 2011, 783 . 785 RFC 6761 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 786 RFC 6761, DOI 10.17487/RFC6761, February 2013, 787 . 789 RFC 6762 Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 790 DOI 10.17487/RFC6762, February 2013, 791 . 793 RFC 6943 Thaler, D., Ed., "Issues in Identifier Comparison for 794 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, 795 May 2013, . 797 RFC 7686 Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 798 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015, 799 . 801 MWDICT Merriam-Webster, Incorporated, Merriam-Webster's Online 802 Dictionary, 11th Edition (Merriam-Webster's Collegiate 803 Dictionary), 2003, https://www.merriam-webster.com/ 805 RENDEV Anonymous, "Tor Rendezvous Specification", Undated, 806 809 OHOST Nick Mathewson, "Special Hostnames in Tor", Undated, 810 813 IABSTMT IAB, 2013, 817 IEEE1003 The Open Group Base Specifications Issue 7, IEEE Std 818 1003.1, 2013 Edition, Copyright 2001-2013 The IEEE 819 and The Open Group, 820 823 WINSOCK URL only, 826 TONR15 "A Theory of Name Resolution", Pierre Neron, Andrew P. 827 Tolmach, Eelco Visser, Guido Wachsmuth. A Theory of Name 828 Resolution. In Jan Vitek (editor), Programming Languages 829 and Systems - 24th European Symposium on Programming, 830 ESOP 2015, Held as Part of the European Joint Conferences 831 on Theory and Practice of Software, ETAPS 2015, London, 832 UK, April 11-18, 2015, Proceedings. Lecture Notes in 833 Computer Science, Springer, April 2015. 835 WIKIAR "Automated Reasoning", Wikipedia article, 836 838 10. Author's Address 840 Edward Lewis 841 ICANN 842 801 17th Street NW 843 Suite 401 844 Washington DC, 20006 US 845 edward.lewis@icann.org 847 Lewis Expires September 27, 2017 [Page 1]