idnits 2.17.1 draft-lewis-domain-names-02.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 921 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 (January 30, 2016) is 3006 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? 'IEN-116' on line 194 looks like a reference -- Missing reference section? 'RFC-799' on line 194 looks like a reference -- Missing reference section? 'RFC-819' on line 194 looks like a reference -- Missing reference section? 'RFC-830' on line 194 looks like a reference -- Missing reference section? 'RFC-882' on line 199 looks like a reference -- Missing reference section? 'RFC-883' on line 199 looks like a reference -- Missing reference section? 'Diestel' on line 343 looks like a reference -- Missing reference section? 'RFC 20' on line 363 looks like a reference -- Missing reference section? 'ANSIX34' on line 364 looks like a reference -- Missing reference section? 'RFC 3596' on line 476 looks like a reference -- Missing reference section? 'RFC 6055' on line 559 looks like a reference -- Missing reference section? 'RENDEV' on line 581 looks like a reference -- Missing reference section? 'OHOST' on line 582 looks like a reference -- Missing reference section? 'IEEE1003.1' on line 618 looks like a reference -- Missing reference section? 'WINSOCK' on line 619 looks like a reference -- Missing reference section? 'RFC 819' on line 692 looks like a reference Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 18 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: July 30, 2016 Date: January 30, 2016 4 Intended Status: unknown 6 Domain Names 7 draft-lewis-domain-names-02.txt 9 Abstract 11 This document states a definition of Domain Name beyond the use of 12 the term within the Domain Name System. The document includes a 13 survey of the diverse ways Domain Names have been interpreted within 14 various protocols over time. The purpose of this is to give a solid 15 foundation for work on Domain Names across all protocols making use 16 of Domain Names. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 30, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 0. NOTE TO RFC EDITOR AND REVIEWERS . . . . . . . . . . . . . . 1 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 54 2. Reaching a definition of a Domain Name . . . . . . . . . . . 1 55 3. Subtypes of Domain Names . . . . . . . . . . . . . . . . . . 1 56 4. Interoperability Considerations . . . . . . . . . . . . . . 1 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 1 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 1 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 1 61 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 1 63 0. NOTE TO RFC EDITOR AND REVIEWERS 65 A suitable venue for discussion of this document is the dnsop working 66 group. Private comments may also be directed at the editor. 68 This document will be presented to the Dispatch WG as it relates 69 to the use of identifiers across protocols, despite perceptions 70 that the DNS defines Domain Names. 72 This section (and sub-sections) **probably** should be removed 73 prior to publication. 75 0.1 Backstory 77 Editorial note - I'm not sure whether 0.1 and 0.2 will remain in 78 the document. Despite the "probably should" above. 80 Why bother to define Domain Names now, three decades after the 81 earliest mentions in RFC documents? There are many examples of 82 names as identifiers in existence, a lot of running code. There is 83 a large industry built on management of names as well, a lot of 84 financial investment made. Would not a definition appearing now be 85 merely an academic exercise or worse, a disruption to what seems to 86 be a reliable system? 88 The tipping point related to addressing the lack of a definition is 89 the call to apply a special meaning to certain Domain Names, with 90 special meaning "not managed via the DNS." The DNS, whose history 91 and explanation follow, has been created to manage Domain Names and 92 over time evolved to become the defining force behind Domain Names. 93 The emergence of other name management systems, in the sense of 94 "permissionless innovation", have called into question whether DNS 95 is the defining force for Domain Names. 97 There are good reasons to call this into question. The DNS 98 definition makes some simplifyng assumptions about Domain Names, 99 carving out some functionality that the newer name management systems 100 wish to explore. To foster this innovation, better definitions, 101 boundaries and even an architectural review of Domain Names is 102 benefical. 104 The beneficiaries of such work include both the developers of 105 software that makes use of names and identifiers. A single piece of 106 code code be used in different nameing environments if the code can 107 determine how to process a name. With code reusable across different 108 environments, another beneficiary are those exploring new means of 109 identifying objects. 111 0.2 Goal 113 The work ahead has the ingredients of a "clarification" - a loose 114 or poorly worded initial definition, multiple diverse valid 115 interpretations in use, and a need to converge on a more precise 116 definition which may cause some issues with backwards compatibility. 117 Before knowing what a precise definition means, the goal ought to be 118 stated. 120 Already proposed, including a definition in this document, are 121 accurate but purely conceptual (or theoretical or mathematical) 122 definitions that, on the one hand, are pure to the idea but not 123 helpful to developing code. Walking from the land of theory into 124 what is helpful means adding elements to the definition, for better 125 or worse. 127 What should the definition address? There are many environments for 128 names and identifiers, what is the scope of Domain Names? How can 129 one tell if a protocol, service, or application handles identifiers 130 according to the definition of domain names or not? Can an 131 application deviate "slightly" from the definition or is it 132 all-or-nothing? Purporting to support Domain Names may appear to 133 be more of a branding issue then a techinical one, that is, merely 134 a name and not a clear distinction. 136 0.3 Benchmark for revising this document 138 Given the numbering, there will come a time to re-organize the draft, 139 add in sensible paging, etc., or abandon it altogether. The point 140 at which this document ought to "molt" into a more mature document 141 could be when - there is a clearer sense of necessity for the work, 142 a vague notion of a goal, and once the "deliverables" from the 143 document are clearer. E.g., what is the definition, what is the 144 scope of the definition, and possible how we apply rules for 145 resolving names (is it DNS? is it not DNS?). 147 1. Introduction 149 Two or three decades into the history of Domain Names, a popular 150 notion has taken hold that Domains Names were defined and specified 151 STD 13, the definition of the Domain Name System (DNS). The 152 definitions within RFC 1034 and RFC 1035 have become the 153 apparently-authoritative source for discussions on what is a Domain 154 Name. 156 The truth is, RFC 1034 and RFC 1035 do not define Domain Names, those 157 documents define only how Domain Names are used and processed in the 158 DNS. But the way in which those RFCs are written seem to lend to the 159 confusion. 161 Throughout this document the term "Domain Names" is capitalized to 162 emphasize the concept of the names and DNS is used to describe the 163 protocol and algorithms described in STD 13, including any applicable 164 updates, related standards track documents and experimental track 165 documents. 167 The term domain is a generic term. And there are many naming 168 systems in existence. The use of the term Domain Names in this 169 document refers to the roughly-defined set of protocols and their 170 applications use of a naming structure that is prevalent amongst 171 many protocols defined in IETF RFC documents. 173 If there is a use of Domain Names not listed here it is merely an 174 omission. The goal in this document is to provide a survey that 175 is sufficent to avoid hand-waving arguments, recognizing the dimishing 176 return in trying to build a complete roster of uses of Domain Names. 177 If there are omissions that ought to be included, please send 178 references for the use case to the author (while this is an Internet 179 Draft, that is). 181 1.1 Deconstructing RFC 1034's Introduction 183 RFC 1034, section 2 begins with this text: 185 "This RFC introduces domain style names, their use for Internet mail 186 and host address support, and the protocols and servers used to 187 implement domain name facilities." 189 Which seems to indicate that RFC 1034 is the origin of Domain Names. 190 Immediately following is section 2.1, entitled "The history of domain 191 names" which includes the following text. 193 "The result was several ideas about name spaces and their management 194 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a 195 common thread was the idea of a hierarchical name space, with the 196 hierarchy roughly corresponding to organizational structure, and names 197 using "." as the character to mark the boundary between hierarchy 198 levels. A design using a distributed database and generalized 199 resources was described in [RFC-882, RFC-883]. Based on experience 200 with several implementations, the system evolved into the scheme 201 described in this memo." 203 The DNS as it is known today did not invent Domain Names (work on the 204 Simple Mail Transfer Protocol did) and, for what it's worth, wasn't 205 the first attempt at an Internet naming system (described in RFC 819 206 "The Domain Naming Convention for Internet User Applications"). 208 One important phrase to keep in mind is: 210 "To simplify implementations," 212 which appears in both RFC 1034 and RFC 1035 as well as their 213 predecessors RFC 882 and RFC 883. This gives credence to the notion 214 that Domain Names exist beyond the DNS. 216 1.2 Purpose of the Document 218 This document has a goal of establishing a definition of Domain Names 219 for the purpose of continuing efforts to innovate in naming systems. 220 The path by which this document aims to meet the goal is to describe 221 in more detail the original definition of Domain Names (which never 222 seems to have been documented in an RFC) and then to illustrate how 223 Domain Names have been interpreted in the DNS, SMTP, X.509 Certificate 224 (PKIX), URNs and other environments. 226 1.3 Why Write This Now? 228 RFC 6761 defines "Special Use Domain Names" which has engendered much 229 confusion of the role of Domain Names with respect to the DNS, 230 particularly Top-Level Domains, which have come to have special 231 meanings. 233 One of the outcomes from the recent discussion on RFC 6761 [this 234 section is written informally] is an assumption that client software, 235 that is an application receiving a string that looks like a name 236 without any supplimental context, will be able to determine how 237 to treat the string within the appropriate naming context. Within 238 the familiar world of domain names today, certain top-level names 239 are recognized as special (such as those whose last label is local). 240 To date there are a limited number of special names, as the number 241 scales up, there will be more work for client software developers. 242 (See section 4.1 of this document.) 244 Note that whether or not the last label takes on this role is 245 suggested here solely as an example. Whether it does or not is a 246 something for "a solution" for which we don't even have the starting 247 point nailed down. Hence, it isn't clear 4.1 should be in this 248 document. 250 Given a lack of an explicit starting point, meaning a clear definition 251 of what Domain Name means, this document is striving to provide a 252 foundation. 254 2. Reaching a definition of a Domain Name 256 Domain Names emerged from the need to build a hierarchy around the 257 growing number of identified hosts exchanging email. RFC 788, "SIMPLE 258 MAIL TRANSFER PROTOCOL", explains, in its section 3.7: 260 "At some not too distant future time it might be necessary to 261 expand the mailbox format to include a region or name domain 262 identifier. There is quite a bit of discussion on this at 263 present, and is likely that SMTP will be revised in the future to 264 take into account naming domains." 266 2.1 Historical Perspective 268 Knowing the origins of a concept helps setting the correct boundaries 269 for discussion. The past isn't meant to restrict the future but 270 meant to help provide a context, include forgotten ideas, and help 271 identify rational for scope creep. 273 RFC 799 "Internet Name Domains" has (arguably) the first formation of 274 what is a Domain Name: 276 "In its most general form, a standard internet mailbox name has 277 the syntax 279 .@ , 281 where is the name of a user known at the host in the 282 name domain ." 284 Prior to this, domain referred to principally an administrative 285 domain, such as the initial organizations involved in networks at the 286 time. 288 RFC 801 "NCP/TCP TRANSITION PLAN" contains this, indicating the 289 passage from the host tables: 291 "It might be advantageous to do away with the host name table and 292 use a Name Server instead, or to keep a relatively small table as 293 a cache of recently used host names." 295 RFC 805 "Computer Mail Meeting Notes" contains this: 297 "The conclusion in this area was that the current "user@host" mailbox 298 identifier should be extended to 'user@host.domain' where 'domain' 299 could be a hierarchy of domains." 301 RFC 819 "The Domain Naming Convention for Internet User Applications" 302 contains this: 304 "A decision has recently been reached to 305 replace the simple name field, "", by a composite name field, 306 '' " 308 A domain name began to take on its current form: 310 "Internet Convention: Fred@F.ISI.ARPA" 312 In addition, "simple name" is defined as what we now call a label, and 313 a "complete (fully qualified) name" is defined as "concatenation of 314 the simple names of the domain structure tree nodes starting with its 315 own name and ending with the top level node name". Noticeably 316 absent is a terminating dot or any mention or representation of a 317 root. 319 RFC 819 defines ARPA as a top-level name (as opposed to top-level 320 domain name). This is an early mention of the role of top-level 321 names. 323 This walk through history relies solely on the record left behind 324 inside RFCs. The precise chain of events is likely slightly 325 different and nuanced. The point of the exercise is to show that 326 Domain Names are a concept the emerged over time, spawned the DNS 327 with its domain names, a definition of host names derived from the 328 host tables, and was heavily influenced by SMTP as the driving 329 application. The definition of the FTP protocol, originally defined 330 in RFC 959 "FILE TRANSFER PROTOCOL", never mentions hosts, domains or 331 host names. But no formal definition of Domain Names has been 332 written and recorded. 334 2.2 Newly Stated Definition of "Domain Name" 336 Looking through the early documents, and using the experience of the 337 past decades, this new definition of Domain Names is stated: 339 A Domain Name is a sequence of labels concatenated by a designated 340 separating character. The Domain Name Space is organized in a strict 341 hierarchical manner with a recognized root Domain Name. The 342 organization follows the rules of tree structure as defined by the 343 field of graph theory in mathematics [Diestel]. 345 Each label represents a node in a conceptual tree. The sequence of 346 labels is concatenated from the deepest node in the tree up to the 347 root node. "Fully qualified" refers to a sequence that ends with the 348 root node. 350 When considering a fully qualifed name, the first label of the name 351 is the name of the deepest node in the tree, the last label is the 352 name of the node is the root. The top-level label, top-level name, 353 or top-level domain is the label just before the root (or last) 354 label. 356 Excluded from the definition is the appearance or representation of 357 the labels, the designated separator character's representation, the 358 ordering of the sequence in appearance, such as left-to-right or 359 right-to-left, nor the written script nor encoding. The definition 360 is purely conceptual. 362 In RFC 819 "Simple Mail Transfer Protocol", the designated separating 363 character is the dot ('.') as represented in the ASCII [RFC 20] 364 [ANSIX34] character set. This is the earliest application definition 365 of how it represents Domain Names. 367 2.2.1 Definition from Lyman Chapin 369 Included here is an emailed definition from Lyman Chapin, appearing 370 in the archives of inip-discuss@ietf.org. The definition is in-line 371 with the one in 2.2 except that it refers to a finite name space due 372 to length restrictions. 374 "In graph-theoretic terms, the domain name space constitutes a 375 labelled directed rooted tree in which the syntax of the label 376 associated with each vertex other than the unlabelled root is 377 defined by RFCs 1035, 1123, and 2181. The term "nth level domain 378 name label" refers to a member of the set of all vertices for which 379 the path to the root contains n edges. For n=1 the term most often 380 used is "top level domain name label" or simply "top level domain" 381 (TLD). A fully qualified domain name is a sequence of labels that 382 represents a path from the root to a leaf vertex of the domain name 383 space. The shorter term "domain name" is not formally defined; in 384 common usage it may be the shorthand equivalent of "fully qualified 385 domain name" (FQDN) or refer to any non-empty subset of the sequence 386 of labels formally identified by a fully qualified domain name. 388 "In this formulation, the term "domain name space" refers to the 389 complete graph consisting of all possible vertices and edges - not 390 just those with which a specific meaning has been associated (what 391 we might call "allocated" labels). It is a finite graph because the 392 length of the longest possible FQDN is finite. At any point in time, 393 there is another labelled directed rooted tree - a sub-graph of the 394 domain name space - containing only vertices that represent 395 allocated labels." 397 2.3 Limitation 399 There are many ways to build a name space, Domain Names are just one 400 example. Domain Names are intended to build a name space that can 401 scale tremendously as opposed to a name space for closed cluster of 402 involved objects. Domain Names are used across many protocols 403 defined inside and outside the IETF and have been defined to 404 interoperate across implementations and protocols. This does not 405 make Domain Names an official or required standard despite the name 406 space's widespread use. 408 2.4 Is This a Domain Name? 410 In the vein of questions like "but is it art?" as to whether an 411 object is art worthy of display in a museum, one can question 412 whether any string with a dot in it is a Domain name. For example, 413 is this multi-sentence paragraph a domain name? It has 414 characters and dots in it. 416 The important question is not whether a string is an example of a 417 Domain Name based on its appearence. The use of a string is what 418 makes it a Domain Name. A path name of a file with an extension 419 looks like a Domain Name with the extension separated by a dot, if one 420 allows the directory seperating character (a '/' perhaps) as a legal 421 member of a label. Within an OS, this is a file/path name. In a 422 protocol it might be used as if it were a domain name. 424 3. Subtypes of Domain Names 426 Subtypes of Domain Names have come to be defined for different 427 protocols, evolving and sometimes building on previous definitions. 429 3.1 Domain Names as Restricted for DNS 431 The DNS protocol place size restrictions on Domain Names and defines 432 rules for matching domain names, treating sets of Domain Names as 433 equivalent to each other. (This matching refers to treating upper 434 case and lower case ASCII letters as equivalent.) The DNS defines 435 the format used to transmit the names across the network as well as 436 rules for displaying them inside text zone files. The DNS creates 437 the notion that names are assigned by an authority per zone. 439 Placing size restrictions on Domain Names is significant in reducing 440 the overall population of names that can be represented in the DNS. 441 The matching rules have the effect of creating (to use a term from 442 graph theory) cliques, distorting the tree-nature of the Domain Name 443 graph. A clique is a completely connected sub-graph implying cyclic 444 paths, a tree is a graph that is acyclic. In sum, the treatment of 445 ASCII (and only ASCII) cases as equivalent is a distortion of the 446 Domain Name hierarchy. 448 DNS defines two formats for domain names. One is the "on-the-wire" 449 format used inside messages, a flags-and-length octet followed by 450 some count of octets for each label with the final length of 0 451 representing the root. The other is a version that can be rendered 452 in printable ASCII characters, complete with a means to represent 453 other characters via an escape sequence. This does not alter the 454 Domain Name concept but has implications when it comes to 455 interoperating with other protocol definitions of their domain name 456 use. 458 DNS assumes that there is, in concept, a central authority creating 459 names within the DNS management structure (called a zone). Although 460 the DNS does not define how a central authority is implemented nor 461 how it coins names, the names have to come from a single point to 462 appear in a zone. There are other means for claiming names, an 463 example will be mentioned later. 465 DNS domain names could appear to be the same as address literals, such 466 as "192.0.2.1" or "0:0:0:0:0:FFFF::192.0.2.1". Such DNS domain 467 names are not used for two reasons. Applications expecting a 468 Domain Name (as a comment line parameter as an example) would 469 opt to treat the string as an address literal and would therefore 470 not look for the string in the DNS domain name space. The management 471 model of the DNS would prefer to aggregate (as in routing) addresses 472 belonging together in the same zone, resulting in labels appearing in 473 reverse order. E.g., the network address 192.0.2.1 would be 474 represented by a DNS domain name as "1.2.0.192.in-addr.arpa." 475 as described in RFC 1035. For IPv6, the convention used is documented 476 in "DNS Extensions to Support IP Version 6" [RFC 3596], section 2.5. 478 DNS domain names have become the dominant definition of domain names 479 due to the success (scale) of the DNS on the public Internet. Many 480 protocols interact with the DNS but instead of supporting the 481 complete definition of DNS domain names, the protocols rely on a 482 subset more commonly called host names. 484 3.2 Host Names 486 Work on the definition of a host name began well before the issuance 487 of the STD 13 documents defining DNS. The rules for the Preferred 488 Syntax in RFC 1034 conform to the host name rules outlined in RFC 489 952. The host name definition was presented again in RFC 1123 490 "Requirements for Internet Hosts -- Application and Support" (which 491 is part of STD 3). In section 2.1 of RFC 1123, one (of two mentions) 492 definition of host name is presented, noting that the definition is a 493 relaxation of what is in RFC 952. 495 Host names are subsets of DNS domain names in the sense that the 496 character set is limited. In particular, only "let" (i.e., 497 presumably letters a-z), "digits" and "hyphen" can be used, with 498 hyphen only internal to a label. (This description is meant to be 499 illustrative, not normative. See the grammar presented on page 5 of 500 RFC 952 for specifics.) RFC 1945 "Hypertext Transfer Protocol -- 501 HTTP/1.0", Section 3.2.2 "http URL" specifically references section 502 2.1 of RFC 1123. The reference is explicit. 504 RFC 5321 " Simple Mail Transfer Protocol" refers to RFC 1035 for a 505 definition of domain names but includes text close to what is in the 506 previous paragraph, noting that domain names as used in SMTP refer to 507 both hosts and to other entities. RFC 5321 updates RFC 1123, but 508 does not cite the latter for a definition of host names. RFC 5321 509 additionally requires brackets to surround address literals, 510 referring to the use case as an "alternative to a domain name." 512 3.3 URI Authority and Domain Names 514 In RFC 3986, also known as STD 66, "Uniform Resource Identifier 515 (URI): Generic Syntax", mentions in its section 3.2.2 (page 20) 516 that the host subcomponent of the URI Authority (section 3.2) "should 517 conform to the DNS syntax". This comes after discussion that 518 the host subcomponent is not strongly tied to the DNS, i.e., names 519 can be managed via concept other than the DNS. There's no 520 discussion on the rationale but this enables the reuse of code 521 parsing and marshalling the host subcomponent between different 522 Domain Name environments. 524 This reinforces the notion that there's a need to understand how 525 Domain Names interoperate amongst protocols and applications. And 526 reinforces the need to derive or make explicit a way for client 527 software to know how to resolve a name, that is, convert a name 528 into a network address. 530 3.4 Internet Protocol Address Literals 532 The above definition includes address literals such as 192.0.2.1 for 533 IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these 534 qualify as Domain Names. In some protocols, these domain names are 535 specified as being preceded by a "#" (find this and cite) or encased 536 in square brackets "[" and "]" (SMTP mentioned already). In the DNS, 537 as previously described in section 3.1, they are represented 538 according to appropriate conventions. 540 3.5 Internationalized Domain Names in Applications 542 The original uses of Domain Names (such as DNS domain names 543 and host names) assumed the ASCII character set. Specifically, 544 making the labels case insensitive prohibited a straightforward use 545 of any method of representation of non-ASCII characters. 547 RFC 5890 "Internationalized Domain Names for Applications (IDNA): 548 Definitions and Document Framework", with associated other documents, 549 defines IDNA2008 as a convention for handling non-ASCII characters in 550 DNS domain names. In figure 1 of that document, the sets of legal DNS 551 domain name formats are defined. Noted in the footnotes of the 552 figure, applications unaware of IDNA2008 cannot distinguish the sub 553 sets defined by the document meaning this definition is not an 554 alteration of Domain Names, but, like host names, yet another subset 555 of DNS domain names. 557 Open question - how closely is IDNA tied to DNS domain names as 558 opposed to Domain Names? "IAB Thoughts on Encodings for 559 Internationalized Domain Names" [RFC 6055], discusses the 560 representations of IDNs. 562 3.6 Restricted for DNS Registration 564 RFC 4290 "Suggested Practices for Registration of Internationalized 565 Domain Names (IDN)" presents reasons why registration of DNS domain 566 names is restricted, in the context of IDN. (That RFC refers to an 567 older form than IDNA2008, but the concepts still apply.) This is yet 568 another convention related to DNS domain names, excluding names that 569 would lead to undesirable outcomes. 571 3.7 Tor Network Names 573 The Tor network is an activity organized by the Tor Project, Inc., 574 described on its main web page 575 "https://www.torproject.org/index.html.en". One component of the 576 network are Domain Names ending in ".onion". (There are other 577 suffixes in use, but it isn't very clear how they are used, defined 578 or whether they are active.) 580 The way in which Domain Names are used in Tor is described in two web 581 documents "Tor Rendezvous Specification" [RENDEV] and "Special 582 Hostnames in Tor" [OHOST] available from the project's website. 584 Syntactically, a Tor domain name fits within the DNS domain name 585 definition but the manner of assignment is different in a manner 586 incompatible with the DNS. (Not better or worse, still significantly 587 different.) Tor domain names are derived from cryptographic keys and 588 organized by distributed hash tables, instead of assigned by a central 589 authority per zone. 591 3.8 X.509 593 In RFC 5280 "Internet X.509 Public Key Infrastructure Certificate and 594 Certificate Revocation List (CRL) Profile", section 4.2.1.6 "Subject 595 Alternative Name" a dNSName is defined to be a host name, with the 596 further restriction that the name " " cannot be used. 598 3.9 Multicast DNS 600 Multicast DNS uses a name space ending with ".local." as described in 601 RFC 6762, "Multicast DNS". The rules for Multicast DNS domain names 602 differ from DNS domain names. Multicast DNS domain names are encoded 603 as Net-Unicode as defined in RFC5198 " Unicode Format for Network 604 Interchange" with the DNS domain name tradition of case folding the 605 ASCII letters when matching names. Appendix F of RFC 6762 gives an 606 explanation of why the punycode algorithm is not used. 608 3.10 /etc/hosts 610 The precursor to DNS, host tables, still exists in remnants in many 611 operating systems. There are library functions, used by applications 612 to resolve DNS domain names, that can return names of arbitrary 613 length (meaning, for example longer than what DNS domain names are 614 defined to be). 616 RFC 3493, "Basic Socket Interface Extensions for IPv6", addresses 617 this in Section 6, further documentation can be found as part of 618 The Open Group Base Specificatoins Issue 7 [IEEE1003.1] and Microsoft 619 Winsock Functions [WINSOCK]. 621 3.11 Other Protocols 623 This section is used to enumerate other protocols that use Domain 624 Names but in general do not impose any other restrictions that what 625 has been mentioned above. 627 SSH [RFC 4251 "The Secure Shell (SSH) Protocol Architecture"] uses 628 host names, using the name when storing public keys of hosts. SSH 629 clients, not necessarily the protocol, illustrate how applications 630 juggle the different forms of Domain Names. SSH can be invoked to 631 open a secure shell with a host via its DNS domain name/host name or 632 it can be used to open a secure shell with a host via its Multicast 633 DNS domain name. 635 FTP [RFC 959 " FILE TRANSFER PROTOCOL (FTP)"] is silent on domain 636 names but client implementations of the protocol behave as SSH 637 clients, being un aware the differences between definitions of Domain 638 Names (DNS vs. MulticastDNS). 640 DHCP [RFC 2131 "Dynamic Host Configuration Protocol"] includes domain 641 names in its Domain Search Option [RFC 3397 "Dynamic Host 642 Configuration Protocol (DHCP) Domain Search Option"]. The encoding of 643 Domain Names used is the on-the-wire format of the DNS, using 644 DNS-defined message compression. DHCP handles Domain Names in other 645 options such as in RFC 4702 defined "The DHCP Client FQDN Option", in 646 the same format. The significance of this is that most other 647 protocols represent DNS domain names or host names in a human readable 648 form, DHCP is using the machine-friendly format. 650 4. Interoperability Considerations 652 Any single protocol is able to define a format for a conceptual Domain 653 Name. Examples given above show that many protocol have done so. 654 From the examples it is clear that the way in which protocols have 655 interpreted Domain Names has varied, leading to, at least, user 656 interfaces having to have built-in intelligence when handling names 657 and, at worst, a growing confusion over how the Domain Name space is 658 to be managed. 660 When protocols having different formats and rules for Domain Names 661 interact, software implementing the protocols translate one protocol's 662 domain name format to another's format. Even when the translation is 663 straightforward, software often fails to handle error conditions well. 664 (Is there a citation for that?) 666 Often times the clash of definitions impacts the design of a new 667 protocol and/or an extension of a protocol. For example, adding 668 non-ASCII domain names has to be done with backwards compatibility 669 with an installed base of ASCII-assuming code. This clash can 670 inhibit new uses of Domain Names. 672 Search lists are a Domain Name mechanism studied in SAC064 "SSAC 673 Advisory on DNS 'Search List' Processing". One of the particular 674 use cases related to this topic is the issuance of search lists via 675 DHCP and then used by any user-client protocol implementation. This 676 emphasizes an interoperability consideration for how Domain Names 677 are treated in different protocols, not just among implementations of 678 one protocol. 680 The definition of a Fully Qualified Domain Name has two forms. The 681 discussion over FQDN involved human-readable names. The principle 682 question is whether to require the terminating dot or to assume it 683 when the end of an input string is hit. Many protocol clients will 684 silently add a dot when a user types in a name to a command line. But 685 some definitions, such as the one in SAC064 require the terminating 686 dot to be included before a name is considered to be fully qualified. 688 The Special Use Domain Names registry defined in RFC 6761 lists Domain 689 Names that are to be treated in a manner inconsistent with the DNS 690 normal processing rules. This registry contains Domain Names 691 regardless of whether the name is a DNS domain name and regardless 692 whether the name is a top-level (domain) name [RFC 819] or is 693 positioned elsewhere in the tree structure. 695 These are reasons this document is needed. The reason for the 696 confusion over what's a legal domain name stems from 697 application-defined restrictions. For example, using a one-label 698 domain name ("dotless") for sending email is not a problem with the 699 DNS nor the name in concept, but is a problem for mail implementations 700 that expect more than one label. (One-label names may be assumed to 701 be in ARPA host table format.) 703 4.1(*) Use of Top-Level Domains as Protocol Identifiers 705 (Would like to have "dns" and "dns" added to the Special Use 706 Domain Names registry. As well as the digits [address literals].) 708 (*) - I am not sure this belongs in this document. The idea is what 709 one can select a name space by the top-level domain (label). I 710 believe this would be scope creep for this document. Leaving it 711 here for consideration. 713 5. Acknowledgements 715 Input received from Andrew Sullivan and Paul Hoffman. Not to imply 716 endorsements of the text. 718 The definition in 2.2.1 was lifted from an email from Lyman Chapin. 719 The URL for that message is (combine the two lines): 721 https://mailarchive.ietf.org/arch/msg/inip-discuss/ 722 cqvFTt3_ve9EBOQfA9TlcqgTIFc 724 Comments from George Michaelson, Kevin Darcy, Joe Abley, Jim Reid, 725 Tony Finch, Robert Edmonds, hellekin, Stephane Bortzmeyer, Ray Bellis, 726 Bob Harold, Alec Muffett, Stuart Cheshire and a growing list of 727 others I am losing track of. Not to imply endorsement. 729 6. IANA Considerations 731 None. 733 7. Security Considerations 735 Nothing direct. This document proposes a definition of the term 736 "Domain Name" and surveys how it has been variously applied. In 737 some sense, loosely defined terms give rise to security hazards. 738 Beyond that, there is no impact of "security." 740 8. References 742 Many references are in-line throughout the text with titles to ease 743 comprehension of the prose. All documents cited are listed here. 744 Whether there is a normative/informative split will depend what, if 745 any, track this document is processed. For now, consider this a 746 reading list on the topic. 748 ANSIX34 American National Standards Institute (formerly United 749 States of America Standards Institute), "USA Code for 750 Information Interchange", ANSI X3.4-1968, 1968 752 RFC 20 Cerf, V., "ASCII format for network interchange", STD 80, 753 RFC 20, DOI 10.17487/RFC0020, October 1969, 754 . 756 RFC 788 Postel, J., "Simple Mail Transfer Protocol", RFC 788, DOI 757 10.17487/RFC0788, November 1981, 758 . 760 RFC 799 Mills, D., "Internet name domains", RFC 799, DOI 761 10.17487/RFC0799, September 1981, 762 . 764 RFC 801 Postel, J., "NCP/TCP transition plan", RFC 801, DOI 765 10.17487/RFC0801, November 1981, 766 . 768 RFC 805 Postel, J., "Computer mail meeting notes", RFC 805, DOI 769 10.17487/RFC0805, February 1982, 770 . 772 RFC 819 Postel, J., "Computer mail meeting notes", RFC 805, DOI 773 10.17487/RFC0805, February 1982, 774 . 776 RFC 882 Mockapetris, P., "Domain names: Concepts and facilities", 777 RFC 882, DOI 10.17487/RFC0882, November 1983, 778 . 780 RFC 883 Mockapetris, P., "Domain names: Implementation 781 specification", RFC 883, DOI 10.17487/RFC0883, November 782 1983, . 784 RFC 952 Mockapetris, P., "Domain names: Implementation 785 specification", RFC 883, DOI 10.17487/RFC0883, November 786 1983, . 788 RFC 959 Postel, J. and J. Reynolds, "File Transfer Protocol", STD 789 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 790 . 792 RFC 1034 Mockapetris, P., "Domain names - concepts and facilities", 793 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 794 . 796 RFC 1035 Mockapetris, P., "Domain names - implementation and 797 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 798 November 1987, . 800 RFC 1123 Braden, R., Ed., "Requirements for Internet Hosts - 801 Application and Support", STD 3, RFC 1123, DOI 802 10.17487/RFC1123, October 1989, 803 . 805 RFC 1945 Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 806 Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 807 10.17487/RFC1945, May 1996, 808 . 810 RFC 2131 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 811 DOI 10.17487/RFC2131, March 1997, 812 . 814 RFC 3397 Aboba, B. and S. Cheshire, "Dynamic Host Configuration 815 Protocol (DHCP) Domain Search Option", RFC 3397, 816 DOI 10.17487/RFC3397, November 2002, 817 . 819 RFC 3492 Costello, A., "Punycode: A Bootstring encoding of Unicode 820 for Internationalized Domain Names in Applications (IDNA)", 821 RFC 3492, DOI 10.17487/RFC3492, March 2003, 822 . 824 RFC 3493 Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 825 Stevens, "Basic Socket Interface Extensions for IPv6", 826 RFC 3493, DOI 10.17487/RFC3493, February 2003, 827 . 829 RFC 3596 Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 830 "DNS Extensions to Support IP Version 6", RFC 3596, 831 DOI 10.17487/RFC3596, October 2003, 832 . 834 RFC 3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 835 Resource Identifier (URI): Generic Syntax", STD 66, RFC 836 3986, DOI 10.17487/RFC3986, January 2005, 837 . 839 RFC 4251 Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 840 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 841 January 2006, . 843 RFC 4290 Klensin, J., "Suggested Practices for Registration of 844 Internationalized Domain Names (IDN)", RFC 4290, DOI 845 10.17487/RFC4290, December 2005, 846 . 848 RFC 4702 Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 849 Configuration Protocol (DHCP) Client Fully Qualified Domain 850 Name (FQDN) Option", RFC 4702, DOI 10.17487/RFC4702, 851 October 2006, . 853 RFC 5198 Klensin, J. and M. Padlipsky, "Unicode Format for Network 854 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 855 . 857 RFC 5280 Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 858 Housley, R., and W. Polk, "Internet X.509 Public Key 859 Infrastructure Certificate and Certificate Revocation 860 List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 861 May 2008, . 863 RFC 5321 Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 864 10.17487/RFC5321, October 2008, 865 . 867 RFC 5890 Klensin, J., "Internationalized Domain Names for 868 Applications (IDNA): Definitions and Document Framework", 869 RFC 5890, DOI 10.17487/RFC5890, August 2010, 870 . 872 RFC 6055 Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts 873 on Encodings for Internationalized Domain Names", RFC 6055, 874 DOI 10.17487/RFC6055, February 2011, 875 . 877 RFC 6761 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 878 RFC 6761, DOI 10.17487/RFC6761, February 2013, 879 . 881 RFC 6762 Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 882 DOI 10.17487/RFC6762, February 2013, 883 . 885 Diestel Diestel, R., "Graph Theory", Springer-Verlag, Heidelberg 886 Graduate Texts in Mathematics, Volume 173 ISBN 887 978-3-642-14278-9, July 2010 (2005, 2000, 1997), 888 890 SAC064 ICANN Security and Stability Committee, "SSAC Advisory on 891 Search List Processing", SAC064, February 2014, 892 894 RENDEV Anonymous, "Tor Rendezvous Specification", Undated, 895 898 OHOST Nick Mathewson, "Special Hostnames in Tor", Undated, 899 902 IEEE1003 The Open Group Base Specifications Issue 7, IEEE Std 903 1003.1, 2013 Edition, Copyright 2001-2013 The IEEE 904 and The Open Group, 905 908 WINSOCK URL only, 911 9. Author's Address 913 Edward Lewis 914 ICANN 915 801 17th Street NW 916 Suite 401 917 Washington DC, 20006 US 918 edward.lewis@icann.org 920 Lewis Expires July 30, 2016 [Page 1]