idnits 2.17.1 draft-lewis-domain-names-04.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 902 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 (September 16, 2016) is 2778 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 99 looks like a reference -- Missing reference section? 'RFC 7686' on line 101 looks like a reference -- Missing reference section? 'RFC 2860' on line 105 looks like a reference -- Missing reference section? 'RFC 6055' on line 370 looks like a reference -- Missing reference section? 'RFC 6943' on line 114 looks like a reference -- Missing reference section? 'IEN-116' on line 177 looks like a reference -- Missing reference section? 'RFC-799' on line 177 looks like a reference -- Missing reference section? 'RFC-819' on line 177 looks like a reference -- Missing reference section? 'RFC-830' on line 177 looks like a reference -- Missing reference section? 'RFC-882' on line 182 looks like a reference -- Missing reference section? 'RFC-883' on line 182 looks like a reference -- Missing reference section? 'RFC 3596' on line 329 looks like a reference -- Missing reference section? 'RFC 5321' on line 361 looks like a reference -- Missing reference section? 'RFC 3986' on line 375 looks like a reference -- Missing reference section? 'RFC 5890' on line 407 looks like a reference -- Missing reference section? 'RFC 4290' on line 419 looks like a reference -- Missing reference section? 'RENDEV' on line 435 looks like a reference -- Missing reference section? 'OHOST' on line 436 looks like a reference -- Missing reference section? 'RFC 5280' on line 448 looks like a reference -- Missing reference section? 'RFC 6762' on line 457 looks like a reference -- Missing reference section? 'IEEE1003.1' on line 474 looks like a reference -- Missing reference section? 'WINSOCK' on line 475 looks like a reference -- Missing reference section? 'RFC 4251' on line 484 looks like a reference -- Missing reference section? 'RFC 959' on line 495 looks like a reference -- Missing reference section? 'RFC 2131' on line 500 looks like a reference -- Missing reference section? 'SAC 064' on line 543 looks like a reference -- Missing reference section? 'RFC 819' on line 564 looks like a reference -- Missing reference section? 'Diestel' on line 585 looks like a reference -- Missing reference section? 'RFC 20' on line 606 looks like a reference -- Missing reference section? 'ANSIX34' on line 607 looks like a reference -- Missing reference section? 'DNSBIND' on line 643 looks like a reference Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 33 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: March 16, 2017 Date: September 16, 2016 4 Intended Status: unknown 6 Domain Names 7 draft-lewis-domain-names-04.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 March 16, 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. Defintion(s) of Domain Names . . . . . . . . . . . . . . . . . 1 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 1 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 1 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 1 64 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 1 66 0. NOTE TO RFC EDITOR AND REVIEWERS 68 The closest mailing list to this topic is arcing@ietf.org. Or maybe 69 dnsop@ietf.org. Private comments may also be directed at the editor. 71 This section (and sub-sections) **probably** should be removed 72 prior to publication. 74 Note on changes from earlier edition: 76 Minor edits plus the re-introduction of definition(s) of Domain Names. 77 The re-introduction of the definitions comes from discussions held 78 at IETF 96, if just to put the words back in a document. Whether 79 the scope of this document is to include them in a final version is 80 not clear. 82 1. Introduction 84 What is the motivation behind the document and what is the anticipated 85 result? 87 1.1 Motivation for this Document 89 Why bother to define Domain Names now, three decades after the 90 earliest mentions in RFC documents? There are many examples of 91 names as identifiers in existence, a lot of running code. There is 92 a large industry built on management of names as well, a lot of 93 financial investment made. Would not a definition appearing now be 94 merely an academic exercise or worse, a disruption to what seems to 95 be a reliable system? 97 A desire to examine this topic is a reaction to the discussion 98 related to the Special Use Domain Name Registry as described in 99 "Special Use Domain Names" [RFC 6761] and the process of adding 100 "ONION" to that registry, as described in "The '.onion' Special-Use 101 Domain Name" [RFC 7686]. Concerns raised on a mailing list used to 102 discuss the latter RFC included specific criterial to declare a name 103 as special as well as the conflict with other processes, such as the 104 process launched from "Memorandum of Understanding Concerning the 105 Technical Work of the Internet Assigned Numbers Authority" [RFC 2860], 106 for registering a name in the DNS. 108 During reviews of this document, documented studies of other 109 difficulties have surfaced. "IAB Thoughts on Encodings for 110 Internationalized Domain Names" [RFC 6055] documents issues related to 111 converting human-readable forms of Domain Names in forms useful to 112 automated applications when there is no clear architecture or precise 113 definition of how to handle Domain Names. "Issues in Identifier 114 Comparison for Security Purposes" [RFC 6943] documents issues related 115 to the same conversion as related to evaluating security policies. The 116 presence of these studies suggest a need to examine the architecture 117 of naming and identifiers. 119 The beneficiaries of such work include both the developers of software 120 that makes use of names and identifiers. A single piece of code could 121 be used in different naming environments if the code can determine how 122 to process a name. With code reusable across different environments, 123 another benefit are innovators exploring new means of identifying 124 objects. 126 1.2 Goal 128 The work ahead has the ingredients of a "clarification" - a loose 129 or poorly worded initial definition, multiple diverse valid 130 interpretations in use, and a need to converge on a more precise 131 definition which may cause some issues with backwards compatibility. 132 This document sets out to establish that a clarification is warranted. 134 1.3 Background 136 Two or three decades into the history of Domain Names, a popular 137 notion has taken hold that Domains Names were defined and specified 138 in the definition of the Domain Name System (DNS). There are two 139 documents that form the basic definition of the DNS, "Domain names - 140 concepts and facilities" and "Domain names - implementation and 141 specification" referred to as RFC 1034 and RFC 1035, respectively. 142 (Note that there is another pair of Request for Comments documents 143 with the same titles that precede RFC 1034 and RFC 1035, those were 144 declared obsolete in favor of the newer documents.) Together RFC 1034 145 and RFC 1035 form STD 13, a full standard cataloged by the RFC Editor. 146 The definitions of DNS domain names within RFC 1034 and RFC 1035 have 147 become the apparently-authoritative source for discussions on what is 148 a Domain Name. 150 Throughout this document the term "Domain Names" is capitalized to 151 emphasize the concept of the names and DNS is used to describe the 152 protocol and algorithms described in STD 13, including any applicable 153 updates, related standards track documents and experimental track 154 documents. 156 The term domain is a generic term. And there are many naming 157 systems in existence. The use of the term Domain Names in this 158 document refers to the roughly-defined set of protocols and their 159 applications' use of a naming structure that is prevalent amongst 160 many protocols defined in IETF RFC documents. 162 The truth is, STD 13 does not define Domain Names, the documents define 163 only how Domain Names are used and processed in the DNS. However the 164 way in which the RFC documents read seem to lend to the confusion. 166 RFC 1034, section 2 begins with this text: 168 "This RFC introduces domain style names, their use for Internet mail 169 and host address support, and the protocols and servers used to 170 implement domain name facilities." 172 Which seems to indicate that RFC 1034 is the origin of Domain Names. 173 Immediately following is section 2.1, entitled "The history of domain 174 names" which includes the following text. 176 "The result was several ideas about name spaces and their management 177 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a 178 common thread was the idea of a hierarchical name space, with the 179 hierarchy roughly corresponding to organizational structure, and names 180 using "." as the character to mark the boundary between hierarchy 181 levels. A design using a distributed database and generalized 182 resources was described in [RFC-882, RFC-883]. Based on experience 183 with several implementations, the system evolved into the scheme 184 described in this memo." 186 The DNS as it is known today did not invent Domain Names (work on the 187 Simple Mail Transfer Protocol did) and, for what it's worth, wasn't 188 the first attempt at an Internet naming system (described in RFC 819 189 "The Domain Naming Convention for Internet User Applications"). 191 One important phrase to keep in mind is: 193 "To simplify implementations," 195 which appears in both RFC 1034 and RFC 1035 as well as their 196 predecessors RFC 882 and RFC 883. This gives credence to the notion 197 that Domain Names exist beyond the DNS. 199 2. Emergence of Domain Names 201 Domain Names emerged from the need to build a hierarchy around the 202 growing number of identified hosts exchanging email. RFC 788, "SIMPLE 203 MAIL TRANSFER PROTOCOL", explains, in its section 3.7: 205 "At some not too distant future time it might be necessary to 206 expand the mailbox format to include a region or name domain 207 identifier. There is quite a bit of discussion on this at 208 present, and is likely that SMTP will be revised in the future to 209 take into account naming domains." 211 Knowing the origins of a concept helps setting the correct boundaries 212 for discussion. The past isn't meant to restrict the future but 213 meant to help provide a context, include forgotten ideas, and help 214 identify rational for scope creep. 216 RFC 799 "Internet Name Domains" has (arguably) the first formation of 217 what is a Domain Name: 219 "In its most general form, a standard internet mailbox name has 220 the syntax 222 .@ , 224 where is the name of a user known at the host in the 225 name domain ." 227 Prior to this, domain referred to principally an administrative 228 domain, such as the initial organizations involved in networks at the 229 time. 231 RFC 801 "NCP/TCP TRANSITION PLAN" contains this, indicating the 232 passage from the host tables: 234 "It might be advantageous to do away with the host name table and 235 use a Name Server instead, or to keep a relatively small table as 236 a cache of recently used host names." 238 RFC 805 "Computer Mail Meeting Notes" contains this: 240 "The conclusion in this area was that the current "user@host" mailbox 241 identifier should be extended to 'user@host.domain' where 'domain' 242 could be a hierarchy of domains." 244 RFC 819 "The Domain Naming Convention for Internet User Applications" 245 contains this: 247 "A decision has recently been reached to 248 replace the simple name field, "", by a composite name field, 249 '' " 251 A domain name began to take on its current form: 253 "Internet Convention: Fred@F.ISI.ARPA" 255 In addition, "simple name" is defined as what we now call a label, and 256 a "complete (fully qualified) name" is defined as "concatenation of 257 the simple names of the domain structure tree nodes starting with its 258 own name and ending with the top level node name". Noticeably 259 absent is a terminating dot or any mention or representation of a 260 root. 262 RFC 819 defines ARPA as a top-level name (as opposed to top-level 263 domain name). This is an early mention of the role of top-level 264 names. 266 This walk through history relies solely on the record left behind 267 inside RFCs. The precise chain of events is likely slightly 268 different and nuanced. The point of the exercise is to show that 269 Domain Names are a concept the emerged over time, spawned the DNS 270 with its domain names, a definition of host names derived from the 271 host tables, and was heavily influenced by SMTP as the driving 272 application. The definition of the FTP protocol, originally defined 273 in RFC 959 "FILE TRANSFER PROTOCOL", never mentions hosts, domains or 274 host names. But no formal definition of Domain Names has been 275 written and recorded. 277 3. Dialects, so to speak, of Domain Names 279 Subtypes of Domain Names have come to be defined for different 280 protocols, evolving and sometimes building on previous definitions. 282 3.1 Domain Names as Restricted for DNS 284 The DNS protocol place size restrictions on Domain Names and defines 285 rules for matching domain names, treating sets of Domain Names as 286 equivalent to each other. (This matching refers to treating upper 287 case and lower case ASCII letters as equivalent.) The DNS defines 288 the format used to transmit the names across the network as well as 289 rules for displaying them inside text zone files. The DNS creates 290 the notion that names are assigned by an authority per zone. 292 Placing size restrictions on Domain Names is significant in reducing 293 the overall population of names that can be represented in the DNS. 294 The matching rules have the effect of creating (to use a term from 295 graph theory) cliques, distorting the tree-nature of the Domain Name 296 graph. A clique is a completely connected sub-graph implying cyclic 297 paths, a tree is a graph that is acyclic. In sum, the treatment of 298 ASCII (and only ASCII) cases as equivalent is a distortion of the 299 Domain Name hierarchy. 301 DNS defines two formats for domain names. One is the "on-the-wire" 302 format used inside messages, a flags-and-length octet followed by 303 some count of octets for each label with the final length of 0 304 representing the root. The other is a version that can be rendered 305 in printable ASCII characters, complete with a means to represent 306 other characters via an escape sequence. This does not alter the 307 Domain Name concept but has implications when it comes to 308 interoperating with other protocol definitions of their domain name 309 use. 311 DNS assumes that there is, in concept, a central authority creating 312 names within the DNS management structure (called a zone). Although 313 the DNS does not define how a central authority is implemented nor 314 how it coins names, the names have to come from a single point to 315 appear in a zone. There are other means for claiming names, an 316 example will be mentioned later. 318 DNS domain names could appear to be the same as address literals, such 319 as "192.0.2.1" or "0:0:0:0:0:FFFF::192.0.2.1". Such DNS domain 320 names are not used for two reasons. Applications expecting a 321 Domain Name (as a comment line parameter as an example) would 322 opt to treat the string as an address literal and would therefore 323 not look for the string in the DNS domain name space. The management 324 model of the DNS would prefer to aggregate (as in routing) addresses 325 belonging together in the same zone, resulting in labels appearing in 326 reverse order. E.g., the network address 192.0.2.1 would be 327 represented by a DNS domain name as "1.2.0.192.in-addr.arpa." 328 as described in RFC 1035. For IPv6, the convention used is documented 329 in "DNS Extensions to Support IP Version 6" [RFC 3596], section 2.5. 331 See also "Issues in Identifier Comparison for Security Purposes" [RFC 332 6943] section 3.1, "Host Names", in particular section 3.1.1 and 3.1.2 333 on address literals, and section 4.1, "Conflation." 335 DNS domain names have become the dominant definition of domain names 336 due to the success (scale) of the DNS on the public Internet. Many 337 protocols interact with the DNS but instead of supporting the 338 complete definition of DNS domain names, the protocols rely on a 339 subset more commonly called host names. 341 3.2 Host Names 343 Work on the definition of a host name began well before the issuance 344 of the STD 13 documents defining DNS. The rules for the Preferred 345 Syntax in RFC 1034 conform to the host name rules outlined in RFC 346 952. The host name definition was presented again in RFC 1123 347 "Requirements for Internet Hosts -- Application and Support" (which 348 is part of STD 3). In section 2.1 of RFC 1123, one (of two mentions) 349 definition of host name is presented, noting that the definition is a 350 relaxation of what is in RFC 952. 352 Host names are subsets of DNS domain names in the sense that the 353 character set is limited. In particular, only "let" (i.e., 354 presumably letters a-z), "digits" and "hyphen" can be used, with 355 hyphen only internal to a label. (This description is meant to be 356 illustrative, not normative. See the grammar presented on page 5 of 357 RFC 952 for specifics.) RFC 1945 "Hypertext Transfer Protocol -- 358 HTTP/1.0", Section 3.2.2 "http URL" specifically references section 359 2.1 of RFC 1123. The reference is explicit. 361 "Simple Mail Transfer Protocol" [RFC 5321] refers to RFC 1035 for a 362 definition of domain names but includes text close to what is in the 363 previous paragraph, noting that domain names as used in SMTP refer to 364 both hosts and to other entities. RFC 5321 updates RFC 1123, but 365 does not cite the latter for a definition of host names. RFC 5321 366 additionally requires brackets to surround address literals, 367 referring to the use case as an "alternative to a domain name." 369 See also "IAB Thoughts on Encodings for Internationalized Domain Names" 370 [RFC 6055], particularly section 3 entitled "Use of Non-ASCII in DNS" 371 for more thoughts on host names. 373 3.3 URI Authority and Domain Names 375 In "Uniform Resource Identifier (URI): Generic Syntax" [RFC 3986], also 376 known as STD 66, mentions in its section 3.2.2 (page 20) that the host 377 subcomponent of the URI Authority (section 3.2) "should conform to the 378 DNS syntax". This comes after discussion that the host subcomponent 379 is not strongly tied to the DNS, i.e., names can be managed via a 380 concept other than the DNS. There's no discussion on the rationale 381 but this enables the reuse of code parsing and marshalling the host 382 subcomponent between different Domain Name environments. 384 This reinforces the notion that there's a need to understand how Domain 385 Names interoperate amongst protocols and applications. And reinforces 386 the need to derive or make explicit a way for client software to know 387 how to resolve a name, that is, convert a name into a network address. 389 3.4 Internet Protocol Address Literals 391 The above definition includes address literals such as 192.0.2.1 for 392 IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these 393 qualify as Domain Names. In some protocols, these domain names are 394 specified as being preceded by a "#" (find this and cite) or encased 395 in square brackets "[" and "]" (SMTP mentioned already). In the DNS, 396 as previously described in section 3.1, they are represented 397 according to appropriate conventions. 399 3.5 Internationalized Domain Names in Applications 401 The original uses of Domain Names (such as DNS domain names 402 and host names) assumed the ASCII character set. Specifically, 403 making the labels case insensitive prohibited a straightforward use 404 of any method of representation of non-ASCII characters. 406 "Internationalized Domain Names for Applications (IDNA): Definitions 407 and Document Framework" [RFC 5890], with associated other documents, 408 defines IDNA2008 as a convention for handling non-ASCII characters in 409 DNS domain names. In figure 1 of that document, the sets of legal DNS 410 domain name formats are defined. Noted in the footnotes of the 411 figure, applications unaware of IDNA2008 cannot distinguish the subsets 412 defined by the document meaning this definition is not an alteration 413 of Domain Names, but, like host names, yet another subset of DNS 414 domain names. 416 3.6 Restricted for DNS Registration 418 "Suggested Practices for Registration of Internationalized Domain Names 419 (IDN)" [RFC 4290] presents reasons why registration of DNS domain 420 names is restricted, in the context of IDN. (That RFC refers to an 421 older form than IDNA2008, but the concepts still apply.) This is yet 422 another convention related to DNS domain names, excluding names that 423 would lead to undesirable outcomes. 425 3.7 Tor Network Names 427 The Tor network is an activity organized by the Tor Project, Inc., 428 described on its main web page 429 "https://www.torproject.org/index.html.en". One component of the 430 network are Domain Names ending in ".onion". (There are other 431 suffixes in use, but it isn't very clear how they are used, defined 432 or whether they are active.) 434 The way in which Domain Names are used in Tor is described in two web 435 documents "Tor Rendezvous Specification" [RENDEV] and "Special 436 Hostnames in Tor" [OHOST] available from the project's website. 438 Syntactically, a Tor domain name fits within the DNS domain name 439 definition but the manner of assignment is different in a manner 440 incompatible with the DNS. (Not better or worse, still significantly 441 different.) Tor domain names are derived from cryptographic keys and 442 organized by distributed hash tables, instead of assigned by a central 443 authority per zone. 445 3.8 X.509 447 "Internet X.509 Public Key Infrastructure Certificate and Certificate 448 Revocation List (CRL) Profile" [RFC 5280], section 4.2.1.6 "Subject 449 Alternative Name" a dNSName is defined to be a host name, with the 450 further restriction that the name " " cannot be used. (The sublte 451 irony is that a name consisting of just a blank would hardly qualify 452 as a Domain Name.) 454 3.9 Multicast DNS 456 Multicast DNS uses a name space ending with ".local." as described in 457 "Multicast DNS" [RFC 6762]. The rules for Multicast DNS domain names 458 differ from DNS domain names. Multicast DNS domain names are encoded 459 as Net-Unicode as defined in RFC5198 " Unicode Format for Network 460 Interchange" with the DNS domain name tradition of case folding the 461 ASCII letters when matching names. Appendix F of RFC 6762 gives an 462 explanation of why the punycode algorithm is not used. 464 3.10 /etc/hosts 466 The precursor to DNS, host tables, still exists in remnants in many 467 operating systems. There are library functions, used by applications 468 to resolve DNS domain names, that can return names of arbitrary 469 length (meaning, for example longer than what DNS domain names are 470 defined to be). 472 RFC 3493, "Basic Socket Interface Extensions for IPv6", addresses 473 this in Section 6, further documentation can be found as part of 474 The Open Group Base Specifications Issue 7 [IEEE1003.1] and Microsoft 475 Winsock Functions [WINSOCK]. 477 3.11 Other Protocols 479 This section is used to list (some) other protocols that use Domain 480 Names but in general do not impose any other restrictions that what 481 has been mentioned above. 483 SSH, documented in "The Secure Shell (SSH) Protocol Architecture" 484 [RFC 4251] uses host names, using the name when storing public keys 485 of hosts. SSH clients, not necessarily the protocol, illustrate how 486 applications juggle the different forms of Domain Names. SSH can be 487 invoked to open a secure shell with a host via its DNS domain 488 name/host name or it can be used to open a secure shell with a host 489 via its Multicast DNS domain name. Or, many others, including name of a 490 purely local, per-user scope. (Note that SSH does not distinguish 491 between DNS names and Multicast DNS domain names in the protocol 492 definition, the difference is handled in resolution libraries belonging 493 to the computing platform.) 495 FTP, defined in "FILE TRANSFER PROTOCOL (FTP)" [RFC 959], is silent on 496 domain names but client implementations of the protocol behave as SSH 497 clients, being un aware the differences between definitions of Domain 498 Names. 500 DHCP, defined in "Dynamic Host Configuration Protocol" [RFC 2131], 501 includes domain names in its Domain Search Option [RFC 3397 "Dynamic 502 Host Configuration Protocol (DHCP) Domain Search Option"]. The 503 encoding of Domain Names used is the on-the-wire format of the DNS, 504 using DNS-defined message compression. DHCP handles Domain Names in 505 other options such as in RFC 4702 defined "The DHCP Client FQDN 506 Option", in the same format. The significance of this is that most 507 other protocols represent DNS domain names or host names in a human 508 readable form, DHCP is using the machine-friendly format. 510 3.12 Other others 512 If there is a use of Domain Names not listed here it is merely an 513 omission. The goal in this document is to provide a survey that 514 is sufficient to avoid hand-waving arguments, recognizing the 515 diminishing return in trying to build a complete roster of uses 516 of Domain Names. If there are omissions that ought to be included, 517 please send references for the use case to the author (while this is 518 an Internet Draft, that is). 520 4. Interoperability Considerations 522 Any single protocol is able to define a format for a conceptual Domain 523 Name. Examples given above show that many protocols have done so. 524 From the examples it is clear that the way in which protocols have 525 interpreted Domain Names has varied, leading to, at least, user 526 interfaces having to have built-in intelligence when handling names 527 and, at worst, a growing confusion over how the Domain Name space is 528 to be managed. 530 When protocols having different formats and rules for Domain Names 531 interact, software implementing the protocols translate one protocol's 532 domain name format to another's format. Even when the translation is 533 straightforward, software often fails to handle error conditions well. 534 (Is there a citation for that?) 536 Often times the clash of definitions impacts the design of a new 537 protocol and/or an extension of a protocol. For example, adding 538 non-ASCII domain names has to be done with backwards compatibility 539 with an installed base of ASCII-assuming code. This clash can 540 inhibit new uses of Domain Names. 542 Search lists are a Domain Name mechanism studied in "SSAC Advisory 543 on DNS 'Search List' Processing" [SAC 064]. One of the particular 544 use cases related to this topic is the issuance of search lists via 545 DHCP and then used by any user-client protocol implementation. This 546 emphasizes an interoperability consideration for how Domain Names 547 are treated in different protocols, not just among implementations of 548 one protocol. 550 The definition of a Fully Qualified Domain Name has two forms. The 551 discussion over FQDN involved human-readable names. The principle 552 question is whether to require the terminating dot or to assume it 553 when the end of an input string is hit. Some protocol clients will 554 silently add a dot when a user types in a name to a command line, 555 others will do so if there is a dot inside the name. [No reference] 556 But some definitions, such as the one in the previously referenced 557 SSAC advisory, require the terminating dot to be included before a name 558 is considered to be fully qualified. 560 The Special Use Domain Names registry lists Domain Names that are to 561 be treated in a manner inconsistent with the DNS normal processing 562 rules. This registry contains Domain Names regardless of whether the 563 name is a DNS domain name and regardless whether the name is a 564 top-level (domain) name [RFC 819] or is positioned elsewhere in the 565 tree structure. 567 These are reasons this document is needed. The reason for the 568 confusion over what's a legal domain name stems from 569 application-defined restrictions. For example, using a one-label 570 domain name ("dotless") for sending email is not a problem with the 571 DNS nor the name in concept, but is a problem for mail implementations 572 that expect more than one label. (One-label names may be assumed to 573 be in ARPA host table format.) The "IAB Statement: Dotless Domains 574 Considered Harmful" [IAB Stmt] elaborates. 576 5. Defintion(s) of Domain Names 578 Looking through the early documents, and using the experience of the 579 past decades, this new definition of Domain Names is stated: 581 A Domain Name is a sequence of labels concatenated by a designated 582 separating character. The Domain Name Space is organized in a strict 583 hierarchical manner with a recognized root Domain Name. The 584 organization follows the rules of tree structure as defined by the 585 field of graph theory in mathematics [Diestel]. 587 Each label represents a node in a conceptual tree. The sequence of 588 labels is concatenated from the deepest node in the tree up to the 589 root node. "Fully qualified" refers to a sequence that ends with the 590 root node. 592 When considering a fully qualifed name, the first label of the name 593 is the name of the deepest node in the tree, the last label is the 594 name of the node is the root. The top-level label, top-level name, 595 or top-level domain is the label just before the root (or last) 596 label. ("First" and "last" regardless of whether the name appears 597 in a left-to-right script or a right-to-left script.) 599 Excluded from the definition is the appearance or representation of 600 the labels, the designated separator character's representation, the 601 ordering of the sequence in appearance, such as left-to-right or 602 right-to-left, nor the written script nor encoding. The definition 603 is purely conceptual. 605 In RFC 819 "Simple Mail Transfer Protocol", the designated separating 606 character is the dot ('.') as represented in the ASCII [RFC 20] 607 [ANSIX34] character set. This is the earliest application definition 608 of how it represents Domain Names. 610 5.1 Definition from Lyman Chapin 612 Included here is an emailed definition from Lyman Chapin, appearing 613 in the archives of inip-discuss@ietf.org. The definition is in-line 614 with the previous one offered except that it refers to a finite name 615 space due to length restrictions. 617 "In graph-theoretic terms, the domain name space constitutes a 618 labelled directed rooted tree in which the syntax of the label 619 associated with each vertex other than the unlabelled root is 620 defined by RFCs 1035, 1123, and 2181. The term 'nth level domain 621 name label' refers to a member of the set of all vertices for which 622 the path to the root contains n edges. For n=1 the term most often 623 used is 'top level domain name label' or simply 'top level domain' 624 (TLD). A fully qualified domain name is a sequence of labels that 625 represents a path from the root to a leaf vertex of the domain name 626 space. The shorter term 'domain name' is not formally defined; in 627 common usage it may be the shorthand equivalent of 'fully qualified 628 domain name' (FQDN) or refer to any non-empty subset of the sequence 629 of labels formally identified by a fully qualified domain name. 631 "In this formulation, the term 'domain name space' refers to the 632 complete graph consisting of all possible vertices and edges - not 633 just those with which a specific meaning has been associated (what 634 we might call 'allocated' labels). It is a finite graph because the 635 length of the longest possible FQDN is finite. At any point in time, 636 there is another labelled directed rooted tree - a sub-graph of the 637 domain name space - containing only vertices that represent 638 allocated labels." 640 5.2 "Inverted" 642 Others have described or defined Domain Names in books. In "DNS and 643 BIND" [DNSBIND], a definition is published which includes the term 644 "inverted" when describing the name space, referring to botanical 645 trees as having roots beneath the trunk of a tree and the mathematical 646 tree with the root depicted at the top. For the full text of that 647 definition, consult the reference. 649 5.3 Limitation 651 There are many ways to build a name space, Domain Names are just one 652 example. Domain Names are intended to build a name space that can 653 scale tremendously as opposed to a name space for closed cluster of 654 involved objects. Domain Names are used across many protocols 655 defined inside and outside the IETF and have been defined to 656 interoperate across implementations and protocols. This does not 657 make Domain Names an official or required standard despite the name 658 space's widespread use. 660 5.4 Is This a Domain Name? 662 In the vein of questions like "but is it art?" as to whether an 663 object is art worthy of display in a museum, one can question 664 whether any string with a dot in it is a Domain Name. For example, 665 is this multi-sentence paragraph a Domain Name? It has 666 characters and dots in it. 668 The important question is not whether a string is an example of a 669 Domain Name based on its appearence. The use of a string is what 670 makes it a Domain Name. A path name of a file with an extension 671 looks like a Domain Name with the extension separated by a dot, if one 672 allows the directory seperating character (a '/' perhaps) as a legal 673 member of a label. Within an OS, this is a file/path name. In a 674 protocol it might be used as if it were a domain name. 676 6. Acknowledgements 678 The definition of domain names was lifted from an email from Lyman 679 Chapin. The URL for that message is (combine the two lines): 681 https://mailarchive.ietf.org/arch/msg/inip-discuss/ 682 cqvFTt3_ve9EBOQfA9TlcqgTIFc 684 Comments from Andrew Sullivan, Paul Hoffman, George Michaelson, 685 Kevin Darcy, Joe Abley, Jim Reid, Tony Finch, Robert Edmonds, 686 hellekin, Stephane Bortzmeyer, Ray Bellis, Bob Harold, Alec Muffett, 687 Stuart Cheshire, Dave Thaler, Niall O'Reilly and a growing list of 688 others I am losing track of. Not to imply endorsement. 690 7. IANA Considerations 692 None. 694 8. Security Considerations 696 Nothing direct. This document proposes a definition of the term 697 "Domain Name" and surveys how it has been variously applied. In 698 some sense, loosely defined terms give rise to security hazards. 699 Beyond that, there is no impact of "security." 701 9. References 703 Many references are in-line throughout the text with titles to ease 704 comprehension of the prose. All documents cited are listed here. 705 Whether there is a normative/informative split will depend what, if 706 any, track this document is processed. For now, consider this a 707 reading list on the topic. 709 ANSIX34 American National Standards Institute (formerly United 710 States of America Standards Institute), "USA Code for 711 Information Interchange", ANSI X3.4-1968, 1968 713 DNSBIND Cricket Liu, Paul Albitz, DNS and BIND (5th Edition), 714 O'Reilly Media, Inc., 2006 716 RFC 20 Cerf, V., "ASCII format for network interchange", STD 80, 717 RFC 20, DOI 10.17487/RFC0020, October 1969, 718 . 720 RFC 788 Postel, J., "Simple Mail Transfer Protocol", RFC 788, DOI 721 10.17487/RFC0788, November 1981, 722 . 724 RFC 799 Mills, D., "Internet name domains", RFC 799, DOI 725 10.17487/RFC0799, September 1981, 726 . 728 RFC 801 Postel, J., "NCP/TCP transition plan", RFC 801, DOI 729 10.17487/RFC0801, November 1981, 730 . 732 RFC 805 Postel, J., "Computer mail meeting notes", RFC 805, DOI 733 10.17487/RFC0805, February 1982, 734 . 736 RFC 819 Postel, J., "Computer mail meeting notes", RFC 805, DOI 737 10.17487/RFC0805, February 1982, 738 . 740 RFC 882 Mockapetris, P., "Domain names: Concepts and facilities", 741 RFC 882, DOI 10.17487/RFC0882, November 1983, 742 . 744 RFC 883 Mockapetris, P., "Domain names: Implementation 745 specification", RFC 883, DOI 10.17487/RFC0883, November 746 1983, . 748 RFC 952 Mockapetris, P., "Domain names: Implementation 749 specification", RFC 883, DOI 10.17487/RFC0883, November 750 1983, . 752 RFC 959 Postel, J. and J. Reynolds, "File Transfer Protocol", STD 753 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 754 . 756 RFC 1034 Mockapetris, P., "Domain names - concepts and facilities", 757 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 758 . 760 RFC 1035 Mockapetris, P., "Domain names - implementation and 761 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 762 November 1987, . 764 RFC 1123 Braden, R., Ed., "Requirements for Internet Hosts - 765 Application and Support", STD 3, RFC 1123, DOI 766 10.17487/RFC1123, October 1989, 767 . 769 RFC 1945 Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 770 Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 771 10.17487/RFC1945, May 1996, 772 . 774 RFC 2131 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 775 DOI 10.17487/RFC2131, March 1997, 776 . 778 RFC 2860 Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 779 Understanding Concerning the Technical Work of the Internet 780 Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, 781 June 2000, . 783 RFC 3397 Aboba, B. and S. Cheshire, "Dynamic Host Configuration 784 Protocol (DHCP) Domain Search Option", RFC 3397, 785 DOI 10.17487/RFC3397, November 2002, 786 . 788 RFC 3492 Costello, A., "Punycode: A Bootstring encoding of Unicode 789 for Internationalized Domain Names in Applications (IDNA)", 790 RFC 3492, DOI 10.17487/RFC3492, March 2003, 791 . 793 RFC 3493 Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 794 Stevens, "Basic Socket Interface Extensions for IPv6", 795 RFC 3493, DOI 10.17487/RFC3493, February 2003, 796 . 798 RFC 3596 Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 799 "DNS Extensions to Support IP Version 6", RFC 3596, 800 DOI 10.17487/RFC3596, October 2003, 801 . 803 RFC 3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 804 Resource Identifier (URI): Generic Syntax", STD 66, RFC 805 3986, DOI 10.17487/RFC3986, January 2005, 806 . 808 RFC 4251 Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 809 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 810 January 2006, . 812 RFC 4290 Klensin, J., "Suggested Practices for Registration of 813 Internationalized Domain Names (IDN)", RFC 4290, DOI 814 10.17487/RFC4290, December 2005, 815 . 817 RFC 4702 Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 818 Configuration Protocol (DHCP) Client Fully Qualified Domain 819 Name (FQDN) Option", RFC 4702, DOI 10.17487/RFC4702, 820 October 2006, . 822 RFC 5198 Klensin, J. and M. Padlipsky, "Unicode Format for Network 823 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 824 . 826 RFC 5280 Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 827 Housley, R., and W. Polk, "Internet X.509 Public Key 828 Infrastructure Certificate and Certificate Revocation 829 List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 830 May 2008, . 832 RFC 5321 Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 833 10.17487/RFC5321, October 2008, 834 . 836 RFC 5890 Klensin, J., "Internationalized Domain Names for 837 Applications (IDNA): Definitions and Document Framework", 838 RFC 5890, DOI 10.17487/RFC5890, August 2010, 839 . 841 RFC 6055 Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts 842 on Encodings for Internationalized Domain Names", RFC 6055, 843 DOI 10.17487/RFC6055, February 2011, 844 . 846 RFC 6761 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 847 RFC 6761, DOI 10.17487/RFC6761, February 2013, 848 . 850 RFC 6762 Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 851 DOI 10.17487/RFC6762, February 2013, 852 . 854 RFC 6943 Thaler, D., Ed., "Issues in Identifier Comparison for 855 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, 856 May 2013, . 858 RFC 7686 Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 859 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015, 860 . 862 Diestel Diestel, R., "Graph Theory", Springer-Verlag, Heidelberg 863 Graduate Texts in Mathematics, Volume 173 ISBN 864 978-3-642-14278-9, July 2010 (2005, 2000, 1997), 865 867 SAC064 ICANN Security and Stability Committee, "SSAC Advisory on 868 Search List Processing", SAC064, February 2014, 869 871 RENDEV Anonymous, "Tor Rendezvous Specification", Undated, 872 875 OHOST Nick Mathewson, "Special Hostnames in Tor", Undated, 876 879 IABStmt IAB, 2013, 883 IEEE1003 The Open Group Base Specifications Issue 7, IEEE Std 884 1003.1, 2013 Edition, Copyright 2001-2013 The IEEE 885 and The Open Group, 886 889 WINSOCK URL only, 892 10. Author's Address 894 Edward Lewis 895 ICANN 896 801 17th Street NW 897 Suite 401 898 Washington DC, 20006 US 899 edward.lewis@icann.org 901 Lewis Expires January 1, 2016 [Page 1]