idnits 2.17.1 draft-lewis-domain-names-01.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 853 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 30, 2015) is 3130 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 122 looks like a reference -- Missing reference section? 'RFC-799' on line 122 looks like a reference -- Missing reference section? 'RFC-819' on line 122 looks like a reference -- Missing reference section? 'RFC-830' on line 122 looks like a reference -- Missing reference section? 'RFC-882' on line 127 looks like a reference -- Missing reference section? 'RFC-883' on line 127 looks like a reference -- Missing reference section? 'Diestel' on line 271 looks like a reference -- Missing reference section? 'RFC 20' on line 291 looks like a reference -- Missing reference section? 'ANSIX34' on line 292 looks like a reference -- Missing reference section? 'RENDEV' on line 465 looks like a reference -- Missing reference section? 'OHOST' on line 466 looks like a reference -- Missing reference section? 'IEEE1003.1' on line 502 looks like a reference -- Missing reference section? 'WINSOCK' on line 503 looks like a reference -- Missing reference section? 'RFC 819' on line 576 looks like a reference Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 16 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 30, 2016 Date: September 30, 2015 4 Intended Status: unknown 6 Domain Names 7 draft-lewis-domain-names-01.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 March 30, 2016. 35 Copyright Notice 37 Copyright (c) 2015 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) should be removed prior to 73 publication. 75 1. Introduction 77 Two or three decades into the history of Domain Names, a popular 78 notion has taken hold that Domains Names were defined and specified 79 STD 13, the definition of the Domain Name System (DNS). The 80 definitions within RFC 1034 and RFC 1035 have become the 81 apparently-authoritative source for discussions on what is a Domain 82 Name. 84 The truth is, RFC 1034 and RFC 1035 do not define Domain Names, those 85 documents define only how Domain Names are used and processed in the 86 DNS. But the way in which those RFCs are written seem to lend to the 87 confusion. 89 Throughout this document the term "Domain Names" is capitalized to 90 emphasize the concept of the names and DNS is used to describe the 91 protocol and algorithms described in STD 13, including any applicable 92 updates, related standards track documents and experimental track 93 documents. 95 The term domain is a generic term. And there are many naming 96 systems in existence. The use of the term Domain Names in this 97 document refers to the roughly-defined set of protocols and their 98 applications use of a naming structure that is prevalent amongst 99 many protocols defined in IETF RFC documents. 101 If there is a use of Domain Names not listed here it is merely an 102 omission. The goal in this document is to provide a survey that 103 is sufficent to avoid hand-waving arguments, recognizing the dimishing 104 return in trying to build a complete roster of uses of Domain Names. 105 If there are omissions that ought to be included, please send 106 references for the use case to the author (while this is an Internet 107 Draft, that is). 109 1.1 Deconstructing RFC 1034's Introduction 111 RFC 1034, section 2 begins with this text: 113 "This RFC introduces domain style names, their use for Internet mail 114 and host address support, and the protocols and servers used to 115 implement domain name facilities." 117 Which seems to indicate that RFC 1034 is the origin of Domain Names. 118 Immediately following is section 2.1, entitled "The history of domain 119 names" which includes the following text. 121 "The result was several ideas about name spaces and their management 122 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a 123 common thread was the idea of a hierarchical name space, with the 124 hierarchy roughly corresponding to organizational structure, and names 125 using "." as the character to mark the boundary between hierarchy 126 levels. A design using a distributed database and generalized 127 resources was described in [RFC-882, RFC-883]. Based on experience 128 with several implementations, the system evolved into the scheme 129 described in this memo." 131 The DNS as it is known today did not invent Domain Names (work on the 132 Simple Mail Transfer Protocol did) and, for what it's worth, wasn't 133 the first attempt at an Internet naming system (described in RFC 819 134 "The Domain Naming Convention for Internet User Applications"). 136 One important phrase to keep in mind is: 138 "To simplify implementations," 140 which appears in both RFC 1034 and RFC 1035 as well as their 141 predecessors RFC 882 and RFC 883. This gives credence to the notion 142 that Domain Names exist beyond the DNS. 144 1.2 Purpose of the Document 146 This document has a goal of establishing a definition of Domain Names 147 for the purpose of continuing efforts to innovate in naming systems. 148 The path by which this document aims to meet the goal is to describe 149 in more detail the original definition of Domain Names (which never 150 seems to have been documented in an RFC) and then to illustrate how 151 Domain Names have been interpreted in the DNS, SMTP, X.509 Certificate 152 (PKIX), URNs and other environments. 154 1.3 Why Write This Now? 156 RFC 6761 defines "Special Use Domain Names" which has engendered much 157 confusion of the role of Domain Names with respect to the DNS, 158 particularly Top-Level Domains, which have come to have special 159 meanings. 161 One of the outcomes from the recent discussion on RFC 6761 [this 162 section is written informally] is an assumption that client software, 163 that is an application receiving a string that looks like a name 164 without any supplimental context, will be able to determine how 165 to treat the string within the appropriate naming context. Within 166 the familiar world of domain names today, certain top-level names 167 are recognized as special (such as those whose last label is local). 168 To date there are a limited number of special names, as the number 169 scales up, there will be more work for client software developers. 170 (See section 4.1 of this document.) 172 Note that whether or not the last label takes on this role is 173 suggested here solely as an example. Whether it does or not is a 174 something for "a solution" for which we don't even have the starting 175 point nailed down. Hence, it isn't clear 4.1 should be in this 176 document. 178 Given a lack of an explicit starting point, meaning a clear definition 179 of what Domain Name means, this document is striving to provide a 180 foundation. 182 2. Reaching a definition of a Domain Name 184 Domain Names emerged from the need to build a hierarchy around the 185 growing number of identified hosts exchanging email. RFC 788, "SIMPLE 186 MAIL TRANSFER PROTOCOL", explains, in its section 3.7: 188 "At some not too distant future time it might be necessary to 189 expand the mailbox format to include a region or name domain 190 identifier. There is quite a bit of discussion on this at 191 present, and is likely that SMTP will be revised in the future to 192 take into account naming domains." 194 2.1 Historical Perspective 196 Knowing the origins of a concept helps setting the correct boundaries 197 for discussion. The past isn't meant to restrict the future but 198 meant to help provide a context, include forgotten ideas, and help 199 identify rational for scope creep. 201 RFC 799 "Internet Name Domains" has (arguably) the first formation of 202 what is a Domain Name: 204 "In its most general form, a standard internet mailbox name has 205 the syntax 207 .@ , 209 where is the name of a user known at the host in the 210 name domain ." 212 Prior to this, domain referred to principally an administrative 213 domain, such as the initial organizations involved in networks at the 214 time. 216 RFC 801 "NCP/TCP TRANSITION PLAN" contains this, indicating the 217 passage from the host tables: 219 "It might be advantageous to do away with the host name table and 220 use a Name Server instead, or to keep a relatively small table as 221 a cache of recently used host names." 223 RFC 805 "Computer Mail Meeting Notes" contains this: 225 "The conclusion in this area was that the current "user@host" mailbox 226 identifier should be extended to 'user@host.domain' where 'domain' 227 could be a hierarchy of domains." 229 RFC 819 "The Domain Naming Convention for Internet User Applications" 230 contains this: 232 "A decision has recently been reached to 233 replace the simple name field, "", by a composite name field, 234 '' " 236 A domain name began to take on its current form: 238 "Internet Convention: Fred@F.ISI.ARPA" 240 In addition, "simple name" is defined as what we now call a label, and 241 a "complete (fully qualified) name" is defined as "concatenation of 242 the simple names of the domain structure tree nodes starting with its 243 own name and ending with the top level node name". Noticeably 244 absent is a terminating dot or any mention or representation of a 245 root. 247 RFC 819 defines ARPA as a top-level name (as opposed to top-level 248 domain name). This is an early mention of the role of top-level 249 names. 251 This walk through history relies solely on the record left behind 252 inside RFCs. The precise chain of events is likely slightly 253 different and nuanced. The point of the exercise is to show that 254 Domain Names are a concept the emerged over time, spawned the DNS 255 with its domain names, a definition of host names derived from the 256 host tables, and was heavily influenced by SMTP as the driving 257 application. The definition of the FTP protocol, originally defined 258 in RFC 959 "FILE TRANSFER PROTOCOL", never mentions hosts, domains or 259 host names. But no formal definition of Domain Names has been 260 written and recorded. 262 2.2 Newly Stated Definition of "Domain Name" 264 Looking through the early documents, and using the experience of the 265 past decades, this new definition of Domain Names is stated: 267 A Domain Name is a sequence of labels concatenated by a designated 268 separating character. The Domain Name Space is organized in a strict 269 hierarchical manner with a recognized root Domain Name. The 270 organization follows the rules of tree structure as defined by the 271 field of graph theory in mathematics [Diestel]. 273 Each label represents a node in a conceptual tree. The sequence of 274 labels is concatenated from the deepest node in the tree up to the 275 root node. "Fully qualified" refers to a sequence that ends with the 276 root node. 278 When considering a fully qualifed name, the first label of the name 279 is the name of the deepest node in the tree, the last label is the 280 name of the node is the root. The top-level label, top-level name, 281 or top-level domain is the label just before the root (or last) 282 label. 284 Excluded from the definition is the appearance or representation of 285 the labels, the designated separator character's representation, the 286 ordering of the sequence in appearance, such as left-to-right or 287 right-to-left, nor the written script nor encoding. The definition 288 is purely conceptual. 290 In RFC 819 "Simple Mail Transfer Protocol", the designated separating 291 character is the dot ('.') as represented in the ASCII [RFC 20] 292 [ANSIX34] character set. This is the earliest application definition 293 of how it represents Domain Names. 295 2.3 Limitation 297 There are many ways to build a name space, Domain Names are just one 298 example. Domain Names are intended to build a name space that can 299 scale tremendously as opposed to a name space for closed cluster of 300 involved objects. Domain Names are used across many protocols 301 defined inside and outside the IETF and have been defined to 302 interoperate across implementations and protocols. This does not 303 make Domain Names an official or required standard despite the name 304 space's widespread use. 306 2.4 Is This a Domain Name? 308 In the vein of questions like "but is it art?" as to whether an 309 object is art worthy of display in a museum or just a ordinary 310 piece of trap, one can question whether any string with a dot in 311 it is a Domain name. For example, is this multi-sentence paragraph 312 a domain name? It has characters and dots in it. 314 The important question is not whether a string is an example of a 315 Domain Name based on its appearence. The use of a string is what 316 makes it a Domain Name. A path name of a file with an extension 317 looks like a Domain Name with the extension separated by a dot, if one 318 allows the directory seperating character (a '/' perhaps) as a legal 319 member of a label. Within an OS, this is a file/path name. In a 320 protocol it might be used as if it were a domain name. 322 3. Subtypes 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 place 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 A DNS domain name "192.0.2.1." can be configured and used in the 364 protocol. The usefulness of this is limited by the concerns 365 described later on in Interoperability Considerations. An outcome of 366 that the convention of representing the Domain Name "192.0.2.1." as 367 "1.2.0.192.in-addr.arpa." 369 DNS domain names have become the dominant definition of domain names 370 due to the success (scale) of the DNS on the public Internet. Many 371 protocols interact with the DNS but instead of supporting the 372 complete definition of DNS domain names, the protocols rely on a 373 subset more commonly called host names. 375 3.2 Host Names 377 Work on the definition of a host name began well before the issuance 378 of the STD 13 documents defining DNS. The rules for the Preferred 379 Syntax in RFC 1034 conform to the host name rules outlined in RFC 380 952. The host name definition was presented again in RFC 1123 381 "Requirements for Internet Hosts -- Application and Support" (which 382 is part of STD 3). In section 2.1 of RFC 1123, one (of two mentions) 383 definition of host name is presented, noting that the definition is a 384 relaxation of what is in RFC 952. 386 Host names are subsets of DNS domain names in the sense that the 387 character set is limited. In particular, only "let" (i.e., 388 presumably letters a-z), "digits" and "hyphen" can be used, with 389 hyphen only internal to a label. (This description is meant to be 390 illustrative, not normative. See the grammar presented on page 5 of 391 RFC 952 for specifics.) RFC 1945 "Hypertext Transfer Protocol -- 392 HTTP/1.0", Section 3.2.2 "http URL" specifically references section 393 2.1 of RFC 1123. The reference is explicit. 395 RFC 5321 " Simple Mail Transfer Protocol" refers to RFC 1035 for a 396 definition of domain names but includes text close to what is in the 397 previous paragraph, noting that domain names as used in SMTP refer to 398 both hosts and to other entities. RFC 5321 updates RFC 1123, but 399 does not cite the latter for a definition of host names. RFC 5321 400 additionally requires brackets to surround address literals, 401 referring to the use case as an "alternative to a domain name." 403 3.3 URI Authority and Domain Names 405 In RFC 3986, also known as STD 66, "Uniform Resource Identifier 406 (URI): Generic Syntax", mentions in its section 3.2.2 (page 20) 407 that the host subcomponent of the URI Authority (section 3.2) "should 408 conform to the DNS syntax". This comes after discussion that 409 the host subcomponent is not strongly tied to the DNS, i.e., names 410 can be managed via concept other than the DNS. There's no 411 discussion on the rationale but this enables the reuse of code 412 parsing and marshalling the host subcomponent between different 413 Domain Name environments. 415 This reinforces the notion that there's a need to understand how 416 Domain Names interoperate amongst protocols and applications. And 417 reinforces the need to derive or make explicit a way for client 418 software to know how to resolve a name, that is, convert a name 419 into a network address. 421 3.4 Internet Protocol Address Literals 423 The above definition includes address literals such as 192.0.2.1 for 424 IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these 425 qualify as Domain Names. In some protocols, these domain names are 426 specified as being preceded by a "#" (find this and cite) or encased 427 in square brackets "[" and "]" (SMTP mentioned already). 429 3.5 Internationalized Domain Names in Applications 431 The original definitions of Domain Names (such as DNS domain names 432 and host names) assumed the ASCII character set. Specifically, 433 making the labels case insensitive prohibited a straightforward use 434 of any method of representation of non-ASCII characters. 436 RFC 5890 "Internationalized Domain Names for Applications (IDNA): 437 Definitions and Document Framework", with associated other documents, 438 defines IDNA2008 as a convention for handling non-ASCII characters in 439 DNS domain names. In figure 1 of that document, the sets of legal DNS 440 domain name formats are defined. Noted in the footnotes of the 441 figure, applications unaware of IDNA2008 cannot distinguish the sub 442 sets defined by the document meaning this definition is not an 443 alteration of Domain Names, but, like host names, yet another subset 444 of DNS domain names. 446 3.6 Restricted for DNS Registration 448 RFC 4290 "Suggested Practices for Registration of Internationalized 449 Domain Names (IDN)" presents reasons why registration of DNS domain 450 names is restricted, in the context of IDN. (That RFC refers to an 451 older form than IDNA2008, but the concepts still apply.) This is yet 452 another convention related to DNS domain names, excluding names that 453 would lead to undesirable outcomes. 455 3.7 Tor Network Names 457 The Tor network is an activity organized by the Tor Project, Inc., 458 described on its main web page 459 "https://www.torproject.org/index.html.en". One component of the 460 network are Domain Names ending in ".onion". (There are other 461 suffixes in use, but it isn't very clear how they are used, defined 462 or whether they are active.) 464 The way in which Domain Names are used in Tor is described in two web 465 documents "Tor Rendezvous Specification" [RENDEV] and "Special 466 Hostnames in Tor" [OHOST] available from the project's website. 468 Syntactically, a Tor domain name fits within the DNS domain name 469 definition but the manner of assignment is different in a manner 470 incompatible with the DNS. (Not better or worse, still significantly 471 different.) Tor domain names are derived from cryptographic keys and 472 organized by distributed hash tables, instead of assigned by a central 473 authority per zone. 475 3.8 X.509 477 In RFC 5280 "Internet X.509 Public Key Infrastructure Certificate and 478 Certificate Revocation List (CRL) Profile", section 4.2.1.6 "Subject 479 Alternative Name" a dNSName is defined to be a host name, with the 480 further restriction that the name " " cannot be used. 482 3.9 Multicast DNS 484 Multicast DNS uses a name space ending with ".local." as described in 485 RFC 6762, "Multicast DNS". The rules for Multicast DNS domain names 486 differ from DNS domain names. Multicast DNS domain names are encoded 487 as Net-Unicode as defined in RFC5198 " Unicode Format for Network 488 Interchange" with the DNS domain name tradition of case folding the 489 ASCII letters when matching names. Appendix F of RFC 6762 gives an 490 explanation of why the punycode algorithm is not used. 492 3.10 /etc/hosts 494 The precursor to DNS, host tables, still exists in remnants in many 495 operating systems. There are library functions, used by applications 496 to resolve DNS domain names, that can return names of arbitrary 497 length (meaning, for example longer than what DNS domain names are 498 defined to be). 500 RFC 3493, "Basic Socket Interface Extensions for IPv6", addresses 501 this in Section 6, further documentation can be found as part of 502 The Open Group Base Specificatoins Issue 7 [IEEE1003.1] and Microsoft 503 Winsock Functions [WINSOCK]. 505 3.11 Other Protocols 507 This section is used to enumerate other protocols that use Domain 508 Names but in general do not impose any other restrictions that what 509 has been mentioned above. 511 SSH [RFC 4251 "The Secure Shell (SSH) Protocol Architecture"] uses 512 host names, using the name when storing public keys of hosts. SSH 513 clients, not necessarily the protocol, illustrate how applications 514 juggle the different forms of Domain Names. SSH can be invoked to 515 open a secure shell with a host via its DNS domain name/host name or 516 it can be used to open a secure shell with a host via its Multicast 517 DNS domain name. 519 FTP [RFC 959 " FILE TRANSFER PROTOCOL (FTP)"] is silent on domain 520 names but client implementations of the protocol behave as SSH 521 clients, being aware the differences between definitions of Domain 522 Names (DNS vs. MulticastDNS). 524 DHCP [RFC 2131 "Dynamic Host Configuration Protocol"] includes domain 525 names in it's Domain Search Option [RFC 3397 "Dynamic Host 526 Configuration Protocol (DHCP) Domain Search Option"]. The encoding of 527 Domain Names used is the on-the-wire format of the DNS, using 528 DNS-defined message compression. DHCP handles Domain Names in other 529 options such as in RFC 4702 defined "The DHCP Client FQDN Option", in 530 the same format. The significance of this is that most other 531 protocols represent DNS domain names or host names in a human readable 532 form, DHCP is using the machine-friendly format. 534 4. Interoperability Considerations 536 Any single protocol is able to define a format for a conceptual Domain 537 Name. Examples given above show that many protocol have done so. 538 From the examples it is clear that the way in which protocols have 539 interpreted Domain Names has varied, leading to, at least, user 540 interfaces having to have built-in intelligence when handling names 541 and, at worst, a growing confusion over how the Domain Name space is 542 to be managed. 544 When protocols having different formats and rules for Domain Names 545 interact, software implementing the protocols translate one protocol's 546 domain name format to another's format. Even when the translation is 547 straightforward, software often fails to handle error conditions well. 548 (Is there a citation for that?) 550 Often times the clash of definitions impacts the design of a new 551 protocol and/or an extension of a protocol. For example, adding 552 non-ASCII domain names has to be done with backwards compatibility 553 with an installed base of ASCII-assuming code. This clash can 554 inhibit new uses of Domain Names. 556 Search lists are a Domain Name mechanism studied in SAC064 "SSAC 557 Advisory on DNS 'Search List' Processing". One of the particular 558 use cases related to this topic is the issuance of search lists via 559 DHCP and then used by any user-client protocol implementation. This 560 emphasizes an interoperability consideration for how Domain Names 561 are treated in different protocols, not just among implementations of 562 one protocol. 564 The definition of a Fully Qualified Domain Name has two forms. The 565 discussion over FQDN involved human-readable names. The principle 566 question is whether to require the terminating dot or to assume it 567 when the end of an input string is hit. Many protocol clients will 568 silently add a dot when a user types in a name to a command line. But 569 some definitions, such as the one in SAC064 require the terminating 570 dot to be included before a name is considered to be fully qualified. 572 The Special Use Domain Names registry defined in RFC 6761 lists Domain 573 Names that are to be treated in a manner inconsistent with the DNS 574 normal processing rules. This registry contains Domain Names 575 regardless of whether the name is a DNS domain name and regardless 576 whether the name is a top-level (domain) name [RFC 819] or is 577 positioned elsewhere in the tree structure. 579 These are reasons this document is needed. The reason for the 580 confusion over what's a legal domain name stems from 581 application-defined restrictions. For example, using a one-label 582 domain name ("dotless") for sending email is not a problem with the 583 DNS nor the name in concept, but is a problem for mail implementations 584 that expect more than one label. (One-label names may be assumed to 585 be in ARPA host table format.) 587 4.1(*) Use of Top-Level Domains as Protocol Identifiers 589 (Would like to have "dns" and "dns" added to the Special Use 590 Domain Names registry. As well as the digits [address literals].) 592 (*) - I am not sure this belongs in this document. The idea is what 593 one can select a name space by the top-level domain (label). I 594 believe this would be scope creep for this document. Leaving it 595 here for consideration. 597 5. Acknowledgements 599 Input received from Andrew Sullivan and Paul Hoffman. Not to imply 600 endorsements of the text. 602 Comments from George Michaelson, Kevin Darcy, Joe Abley, Jim Reid, 603 Tony Finch, Robert Edmonds, hellekin, Stephane Bortzmeyer, Ray Bellis, 604 Bob Harold, Alec Muffett. Not to imply endorsement. 606 6. IANA Considerations 608 None. 610 7. Security Considerations 612 Nothing direct. This document proposes a definition of the term 613 "Domain Name" and surveys how it has been variously applied. In 614 some sense, loosely defined terms give rise to security hazards. 615 Beyond that, there is no impact of "security." 617 8. References 619 Many references are in-line throughout the text with titles to ease 620 comprehension of the prose. All documents cited are listed here. 621 Whether there is a normative/informative split will depend what, if 622 any, track this document is processed. For now, consider this a 623 reading list on the topic. 625 ANSIX34 American National Standards Institute (formerly United 626 States of America Standards Institute), "USA Code for 627 Information Interchange", ANSI X3.4-1968, 1968 629 RFC 20 Cerf, V., "ASCII format for network interchange", STD 80, 630 RFC 20, DOI 10.17487/RFC0020, October 1969, 631 . 633 RFC 788 Postel, J., "Simple Mail Transfer Protocol", RFC 788, DOI 634 10.17487/RFC0788, November 1981, 635 . 637 RFC 799 Mills, D., "Internet name domains", RFC 799, DOI 638 10.17487/RFC0799, September 1981, 639 . 641 RFC 801 Postel, J., "NCP/TCP transition plan", RFC 801, DOI 642 10.17487/RFC0801, November 1981, 643 . 645 RFC 805 Postel, J., "Computer mail meeting notes", RFC 805, DOI 646 10.17487/RFC0805, February 1982, 647 . 649 RFC 819 Postel, J., "Computer mail meeting notes", RFC 805, DOI 650 10.17487/RFC0805, February 1982, 651 . 653 RFC 882 Mockapetris, P., "Domain names: Concepts and facilities", 654 RFC 882, DOI 10.17487/RFC0882, November 1983, 655 . 657 RFC 883 Mockapetris, P., "Domain names: Implementation 658 specification", RFC 883, DOI 10.17487/RFC0883, November 659 1983, . 661 RFC 952 Mockapetris, P., "Domain names: Implementation 662 specification", RFC 883, DOI 10.17487/RFC0883, November 663 1983, . 665 RFC 959 Postel, J. and J. Reynolds, "File Transfer Protocol", STD 666 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 667 . 669 RFC 1034 Mockapetris, P., "Domain names - concepts and facilities", 670 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 671 . 673 RFC 1035 Mockapetris, P., "Domain names - implementation and 674 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 675 November 1987, . 677 RFC 1123 Braden, R., Ed., "Requirements for Internet Hosts - 678 Application and Support", STD 3, RFC 1123, DOI 679 10.17487/RFC1123, October 1989, 680 . 682 RFC 1945 Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 683 Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 684 10.17487/RFC1945, May 1996, 685 . 687 RFC 2131 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 688 DOI 10.17487/RFC2131, March 1997, 689 . 691 RFC 3397 Aboba, B. and S. Cheshire, "Dynamic Host Configuration 692 Protocol (DHCP) Domain Search Option", RFC 3397, 693 DOI 10.17487/RFC3397, November 2002, 694 . 696 RFC 3492 Costello, A., "Punycode: A Bootstring encoding of Unicode 697 for Internationalized Domain Names in Applications (IDNA)", 698 RFC 3492, DOI 10.17487/RFC3492, March 2003, 699 . 701 RFC 3493 Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 702 Stevens, "Basic Socket Interface Extensions for IPv6", 703 RFC 3493, DOI 10.17487/RFC3493, February 2003, 704 . 706 RFC 3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 707 Resource Identifier (URI): Generic Syntax", STD 66, RFC 708 3986, DOI 10.17487/RFC3986, January 2005, 709 . 711 RFC 4251 Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 712 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 713 January 2006, . 715 RFC 4290 Klensin, J., "Suggested Practices for Registration of 716 Internationalized Domain Names (IDN)", RFC 4290, DOI 717 10.17487/RFC4290, December 2005, 718 . 720 RFC 4702 Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 721 Configuration Protocol (DHCP) Client Fully Qualified Domain 722 Name (FQDN) Option", RFC 4702, DOI 10.17487/RFC4702, 723 October 2006, . 725 RFC 5198 Klensin, J. and M. Padlipsky, "Unicode Format for Network 726 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 727 . 729 RFC 5280 Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 730 Housley, R., and W. Polk, "Internet X.509 Public Key 731 Infrastructure Certificate and Certificate Revocation 732 List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 733 May 2008, . 735 RFC 5321 Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 736 10.17487/RFC5321, October 2008, 737 . 739 RFC 5890 Klensin, J., "Internationalized Domain Names for 740 Applications (IDNA): Definitions and Document Framework", 741 RFC 5890, DOI 10.17487/RFC5890, August 2010, 742 . 744 RFC 6761 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 745 RFC 6761, DOI 10.17487/RFC6761, February 2013, 746 . 748 RFC 6762 Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 749 DOI 10.17487/RFC6762, February 2013, 750 . 752 Diestel Diestel, R., "Graph Theory", Springer-Verlag, Heidelberg 753 Graduate Texts in Mathematics, Volume 173 ISBN 754 978-3-642-14278-9, July 2010 (2005, 2000, 1997), 755 757 SAC064 ICANN Security and Stability Committee, "SSAC Advisory on 758 Search List Processing", SAC064, February 2014, 759 761 RENDEV Anonymous, "Tor Rendezvous Specification", Undated, 762 765 OHOST Nick Mathewson, "Special Hostnames in Tor", Undated, 766 769 IEEE1003 The Open Group Base Specifications Issue 7, IEEE Std 770 1003.1, 2013 Edition, Copyright 2001-2013 The IEEE 771 and The Open Group, 772 775 WINSOCK URL only, 778 9. Author's Address 780 Edward Lewis 781 ICANN 782 801 17th Street NW 783 Suite 401 784 Washington DC, 20006 US 785 edward.lewis@icann.org 787 Appendix A. 789 This is lifted from an email message expanding on why there's a 790 problem. The email refers to the proposal to add "alt" to the 791 Special Use Domain Names registry as well as a ficticious proposal 792 to add "carrot". This message can be found here: 794 796 The archives include a longer thread. This section will likely not 797 appear in later versions of this draft. 799 Here's the problem I see. 801 Lets say I want to write a very basic SSH client (just to make the 802 story simple). Someone can then type "eds-ssh computer-name" and 803 open up a secured connection. 805 If computer-name ends in .local, I open TCP to an IP address from the 806 lookup in mDNS. 808 If computer-name ends in .onion, I open TCP to an IP address I get via 809 Tor (assuming that .onion supports remote shell). 811 If computer-name ends in a digit, I suppose it's an address literal 812 and open TCP accordingly. 814 If computer-name ends in whatever is in the DNS root zone, I find the 815 address in DNS. 817 If computer-name ends in something not in the DNS root zone, I return 818 an error. 820 The gotchas include, what if the latter two are indistinguishable 821 because the DNS resolver sent back a landing page - or the latter 822 three if the redirection service didn't recognize .onion as special. 824 What if, in a year from now, .carrot becomes yet another way to 825 resolve names? 827 What if, in the future, .alt is defined as having special meaning? 828 (Note - the fact that .alt is in an actual ID and .carrot is purely 829 fictional means .carrot is closer to being an RFC. ;)) (Joke) 831 It seems to me that a new layer of software is emerging between the 832 UI and the stub resolver, one that will need to know where to send a 833 name resolution query. (Perhaps even amongst DNS stub resolvers on 834 different interfaces.) This emerging layer needs to know how to 835 direct it's work flow. The Special Use Domain Names Registry would be 836 the place to start (but as it's written now, the emerging layer can't 837 be future proofed). 839 These are just TLD examples, perhaps a simplification. 841 I see a fork in the codepath ahead regarding "whether the DNS is above 842 Domain Names" (like .alt) or whether "Domain Names are broader than 843 what was conveniently defined for a DNS". It's important to know 844 which of those two statements are true so we can get on with Special 845 Use Domain Names, and perhaps to find ways to objectively assign new 846 names for new uses. 848 I think defining -whether- name.onion is a Domain Name will make us 849 re-think how Domain Names interoperate amongst protocols beyond the 850 DNS. 852 Lewis Expires March 19, 2016 [Page 1]