idnits 2.17.1 draft-lewis-domain-names-00.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 684 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 19, 2015) is 3140 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 104 looks like a reference -- Missing reference section? 'RFC-799' on line 104 looks like a reference -- Missing reference section? 'RFC-819' on line 104 looks like a reference -- Missing reference section? 'RFC-830' on line 104 looks like a reference -- Missing reference section? 'RFC-882' on line 109 looks like a reference -- Missing reference section? 'RFC-883' on line 109 looks like a reference -- Missing reference section? 'Diestel' on line 232 looks like a reference -- Missing reference section? 'RFC 20' on line 246 looks like a reference -- Missing reference section? 'ANSIX34' on line 247 looks like a reference -- Missing reference section? 'RENDEV' on line 386 looks like a reference -- Missing reference section? 'OHOST' on line 387 looks like a reference -- Missing reference section? 'DNSOP1' on line 398 looks like a reference -- Missing reference section? 'RFC 819' on line 488 looks like a reference -- Missing reference section? 'DNSOP' on line 667 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 19, 2016 Date: September 19, 2015 4 Intended Status: unknown 6 Domain Names 7 draft-lewis-domain-names-00.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 19, 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 section (and sub-sections) should be removed prior to 69 publication. 71 1. Introduction 73 Two or three decades into the history of Domain Names, a popular 74 notion has taken hold that Domains Names were defined and specified 75 STD 13, the definition of the Domain Name System (DNS). The 76 definitions within RFC 1034 and RFC 1035 have become the 77 apparently-authoritative source for discussions on what is a Domain 78 Name. 80 The truth is, RFC 1034 and RFC 1035 do not define Domain Names, those 81 documents define only how Domain Names are used and processed in the 82 DNS. But the way in which those RFCs are written seem to lend to the 83 confusion. 85 Throughout this document the term "Domain Names" is capitalized to 86 emphasize the concept of the names and DNS is used to describe the 87 protocol and algorithms described in STD 13, including any applicable 88 updates, related standards track documents and experimental track 89 documents. 91 1.1 Deconstructing RFC 1034's Introduction 93 RFC 1034, section 2 begins with this text: 95 "This RFC introduces domain style names, their use for Internet mail 96 and host address support, and the protocols and servers used to 97 implement domain name facilities." 99 Which seems to indicate that RFC 1034 is the origin of Domain Names. 100 Immediately following is section 2.1, entitled "The history of domain 101 names" which includes the following text. 103 "The result was several ideas about name spaces and their management 104 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a 105 common thread was the idea of a hierarchical name space, with the 106 hierarchy roughly corresponding to organizational structure, and names 107 using "." as the character to mark the boundary between hierarchy 108 levels. A design using a distributed database and generalized 109 resources was described in [RFC-882, RFC-883]. Based on experience 110 with several implementations, the system evolved into the scheme 111 described in this memo." 113 The DNS as it is known today did not invent Domain Names (work on the 114 Simple Mail Transfer Protocol did) and, for what it's worth, wasn't 115 the first attempt at an Internet naming system (described in RFC 819 116 "The Domain Naming Convention for Internet User Applications"). 118 One important phrase to keep in mind is: 120 "To simplify implementations," 122 which appears in both RFC 1034 and RFC 1035 as well as their 123 predecessors RFC 882 and RFC 883. This gives credence to the notion 124 that Domain Names exist beyond the DNS. 126 1.2 Purpose of the Document 128 This document has a goal of establishing a definition of Domain Names 129 for the purpose of continuing efforts to innovate in naming systems. 130 The path by which this document aims to meet the goal is to describe 131 in more detail the original definition of Domain Names (which never 132 seems to have been documented in an RFC) and then to illustrate how 133 Domain Names have been interpreted in the DNS, SMTP, X.509 Certificate 134 (PKIX), URNs and other environments. 136 1.3 Why Write This Now? 138 RFC 6761 defines "Special Use Domain Names" which has engendered much 139 confusion of the role of Domain Names with respect to the DNS, 140 particularly Top-Level Domains, which have come to have special 141 meanings. 143 2. Reaching a definition of a Domain Name 145 Domain Names emerged from the need to build a hierarchy around the 146 growing number of identified hosts exchanging email. RFC 788, "SIMPLE 147 MAIL TRANSFER PROTOCOL", explains, in its section 3.7: 149 "At some not too distant future time it might be necessary to 150 expand the mailbox format to include a region or name domain 151 identifier. There is quite a bit of discussion on this at 152 present, and is likely that SMTP will be revised in the future to 153 take into account naming domains." 155 2.1 Historical Perspective 157 Knowing the origins of a concept helps setting the correct boundaries 158 for discussion. The past isn't meant to restrict the future but 159 meant to help provide a context, include forgotten ideas, and help 160 identify rational for scope creep. 162 RFC 799 "Internet Name Domains" has (arguably) the first formation of 163 what is a Domain Name: 165 "In its most general form, a standard internet mailbox name has 166 the syntax 168 .@ , 170 where is the name of a user known at the host in the 171 name domain ." 173 Prior to this, domain referred to principally an administrative 174 domain, such as the initial organizations involved in networks at the 175 time. 177 RFC 801 "NCP/TCP TRANSITION PLAN" contains this, indicating the 178 passage from the host tables: 180 "It might be advantageous to do away with the host name table and 181 use a Name Server instead, or to keep a relatively small table as 182 a cache of recently used host names." 184 RFC 805 "Computer Mail Meeting Notes" contains this: 186 "The conclusion in this area was that the current "user@host" mailbox 187 identifier should be extended to 'user@host.domain' where 'domain' 188 could be a hierarchy of domains." 190 RFC 819 "The Domain Naming Convention for Internet User Applications" 191 contains this: 193 "A decision has recently been reached to 194 replace the simple name field, "", by a composite name field, 195 '' " 197 A domain name began to take on its current form: 199 "Internet Convention: Fred@F.ISI.ARPA" 201 In addition, "simple name" is defined as what we now call a label, and 202 a "complete (fully qualified) name" is defined as "concatenation of 203 the simple names of the domain structure tree nodes starting with its 204 own name and ending with the top level node name". Noticeably 205 absent is a terminating dot or any mention or representation of a 206 root. 208 RFC 819 defines ARPA as a top-level name (as opposed to top-level 209 domain name). This is an early mention of the role of top-level 210 names. 212 This walk through history relies solely on the record left behind 213 inside RFCs. The precise chain of events is likely slightly 214 different and nuanced. The point of the exercise is to show that 215 Domain Names are a concept the emerged over time, spawned the DNS 216 with its domain names, a definition of host names derived from the 217 host tables, and was heavily influenced by SMTP as the driving 218 application. The definition of the FTP protocol, originally defined 219 in RFC 959 "FILE TRANSFER PROTOCOL", never mentions hosts, domains or 220 host names. But no formal definition of Domain Names has been 221 written and recorded. 223 2.2 Newly Stated Definition of "Domain Name" 225 Looking through the early documents, and using the experience of the 226 past decades, this new definition of Domain Names is stated: 228 A Domain Name is a sequence of labels concatenated by a designated 229 separating character. The Domain Name Space is organized in a strict 230 hierarchical manner with a recognized root Domain Name. The 231 organization follows the rules of tree structure as defined by the 232 field of graph theory in mathematics [Diestel]. 234 Each label represents a node in a conceptual tree. The sequence of 235 labels is concatenated from the deepest node in the tree up to the 236 root node. "Fully qualified" refers to a sequence that ends with the 237 root node. 239 What is excluded in this definition is the appearance or 240 representation of the labels, the designated separator character's 241 representation, the ordering of the sequence, such as left-to-right 242 or right-to-left, nor the written script nor encoding. This 243 definition is purely conceptual. 245 In RFC 819 "Simple Mail Transfer Protocol", the designated separating 246 character is the dot ('.') as represented in the ASCII [RFC 20] 247 [ANSIX34] character set. This is the earliest application definition 248 of how it represents domain names. 250 2.3 Limitation 252 There are many ways to build a name space, Domain Names are just one 253 example. Domain Names are intended to build a name space that can 254 scale tremendously as opposed to a name space for closed cluster of 255 involved objects. Domain Names are used across many protocols 256 defined inside and outside the IETF and have been defined to 257 interoperate across implementations and protocols. This does not 258 make Domain Names an official or required standard despite the name 259 space's widespread use. 261 3. Subtypes of Domain Names 263 Subtypes of Domain Names have come to be defined for different 264 protocols, evolving and sometimes building on previous definitions. 266 3.1 Domain Names as Restricted for DNS 268 The DNS protocol place size restrictions on Domain Names and defines 269 rules for matching domain names, treating sets of Domain Names as 270 equivalent to each other. (This matching refers to treating upper 271 case and lower case ASCII letters as equivalent.) The DNS defines 272 the format used to transmit the names across the network as well as 273 rules for displaying them inside text zone files. The DNS creates 274 the notion that names are assigned by an authority per zone. 276 Placing size restrictions on Domain Names is significant in reducing 277 the overall population of names that can be represented in the DNS. 278 The matching rules have the effect of creating (to use a term from 279 graph theory) cliques, distorting the tree-nature of the Domain Name 280 graph. A clique is a completely connected sub-graph implying cyclic 281 paths, a tree is a graph that is acyclic. In sum, the treatment of 282 ASCII (and only ASCII) cases as equivalent is a distortion of the 283 Domain Name hierarchy. 285 DNS defines two formats for domain names. One is the "on-the-wire" 286 format used inside messages, a flags-and-length octet followed by 287 some count of octets for each label with the final length of 0 288 representing the root. The other is a version that can be rendered 289 in printable ASCII characters, complete with a means to represent 290 other characters via an escape sequence. This does not alter the 291 Domain Name concept but has implications when it comes to 292 interoperating with other protocol definitions of their domain name 293 use. 295 DNS assumes that there is, in concept, a central authority creating 296 names within the DNS management structure (called a zone). Although 297 the DNS does not define how a central authority is implemented nor 298 how it coins names, the names have to come from a single point to 299 appear in a zone. There are other means for claiming names, an 300 example will be mentioned later. 302 A DNS domain name "192.0.2.1." can be configured and used in the 303 protocol. The usefulness of this is limited by the concerns 304 described later on in Interoperability Considerations. An outcome of 305 that the convention of representing the Domain Name "192.0.2.1." as 306 "1.2.0.192.in-addr.arpa." 308 DNS domain names have become the dominant definition of domain names 309 due to the success (scale) of the DNS on the public Internet. Many 310 protocols interact with the DNS but instead of supporting the 311 complete definition of DNS domain names, the protocols rely on a 312 subset more commonly called host names. 314 3.2 Host Names 316 Work on the definition of a host name began well before the issuance 317 of the STD 13 documents defining DNS. The rules for the Preferred 318 Syntax in RFC 1034 conform to the host name rules outlined in RFC 319 952. The host name definition was presented again in RFC 1123 320 "Requirements for Internet Hosts -- Application and Support" (which 321 is part of STD 3). In section 2.1 of RFC 1123, one (of two mentions) 322 definition of host name is presented, noting that the definition is a 323 relaxation of what is in RFC 952. 325 Host names are subsets of DNS domain names in the sense that the 326 character set is limited. In particular, only "let" (i.e., 327 presumably letters a-z), "digits" and "hyphen" can be used, with 328 hyphen only internal to a label. (This description is meant to be 329 illustrative, not normative. See the grammar presented on page 5 of 330 RFC 952 for specifics.) RFC 1945 "Hypertext Transfer Protocol -- 331 HTTP/1.0", Section 3.2.2 "http URL" specifically references section 332 2.1 of RFC 1123. The reference is explicit. 334 RFC 5321 " Simple Mail Transfer Protocol" refers to RFC 1035 for a 335 definition of domain names but includes text close to what is in the 336 previous paragraph, noting that domain names as used in SMTP refer to 337 both hosts and to other entities. RFC 5321 updates RFC 1123, but 338 does not cite the latter for a definition of host names. RFC 5321 339 additionally requires brackets to surround address literals, 340 referring to the use case as an "alternative to a domain name." 342 3.3 Internet Protocol Address Literals 344 The above definition includes address literals such as 192.0.2.1 for 345 IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these 346 qualify as Domain Names. In some protocols, these domain names are 347 specified as being preceded by a "#" (find this and cite) or encased 348 in square brackets "[" and "]" (SMTP mentioned already). 350 3.4 Internationalized Domain Names in Applications 352 The original definitions of Domain Names (such as DNS domain names 353 and host names) assumed the ASCII character set. Specifically, 354 making the labels case insensitive prohibited a straightforward use 355 of any method of representation of non-ASCII characters. 357 RFC 5890 "Internationalized Domain Names for Applications (IDNA): 358 Definitions and Document Framework", with associated other documents, 359 defines IDNA2008 as a convention for handling non-ASCII characters in 360 DNS domain names. In figure 1 of that document, the sets of legal DNS 361 domain name formats are defined. Noted in the footnotes of the 362 figure, applications unaware of IDNA2008 cannot distinguish the sub 363 sets defined by the document meaning this definition is not an 364 alteration of Domain Names, but, like host names, yet another subset 365 of DNS domain names. 367 3.5 Restricted for DNS Registration 369 RFC 4290 "Suggested Practices for Registration of Internationalized 370 Domain Names (IDN)" presents reasons why registration of DNS domain 371 names is restricted, in the context of IDN. (That RFC refers to an 372 older form than IDNA2008, but the concepts still apply.) This is yet 373 another convention related to DNS domain names, excluding names that 374 would lead to undesirable outcomes. 376 3.6 Tor Network Names 378 The Tor network is an activity organized by the Tor Project, Inc., 379 described on its main web page 380 "https://www.torproject.org/index.html.en". One component of the 381 network are Domain Names ending in ".onion". (There are other 382 suffixes in use, but it isn't very clear how they are used, defined 383 or whether they are active.) 385 The way in which Domain Names are used in Tor is described in two web 386 documents "Tor Rendezvous Specification" [RENDEV] and "Special 387 Hostnames in Tor" [OHOST] available from the project's website. 389 Syntactically, a Tor domain name fits within the DNS domain name 390 definition but the manner of assignment is different in a manner 391 incompatible with the DNS. (Not better or worse, still significantly 392 different.) Tor domain names are derived from cryptographic keys and 393 organized by distributed hash tables, instead of assigned by a central 394 authority per zone. 396 According to an email message, ".onion" names may (in the future) 397 exceed the length limits of a label imposed on DNS domain names, 398 reaching 64, 80, or more bytes. [DNSOP1] 400 3.7 X.509 402 In RFC 5280 "Internet X.509 Public Key Infrastructure Certificate and 403 Certificate Revocation List (CRL) Profile", section 4.2.1.6 "Subject 404 Alternative Name" a dNSName is defined to be a host name, with the 405 further restriction that the name " " cannot be used. 407 3.8 Multicast DNS 409 Multicast DNS uses a name space ending with ".local." as described in 410 RFC 6762, "Multicast DNS". The rules for Multicast DNS domain names 411 differ from DNS domain names. Multicast DNS domain names are encoded 412 as Net-Unicode as defined in RFC5198 " Unicode Format for Network 413 Interchange" with the DNS domain name tradition of case folding the 414 ASCII letters when matching names. Appendix F of RFC 6762 gives an 415 explanation of why the punycode algorithm is not used. 417 3.9 Other Protocols 419 This section is used to enumerate other protocols that use Domain 420 Names but in general do not impose any other restrictions that what 421 has been mentioned above. 423 SSH [RFC 4251 "The Secure Shell (SSH) Protocol Architecture"] uses 424 host names, using the name when storing public keys of hosts. SSH 425 clients, not necessarily the protocol, illustrate how applications 426 juggle the different forms of Domain Names. SSH can be invoked to 427 open a secure shell with a host via its DNS domain name/host name or 428 it can be used to open a secure shell with a host via its Multicast 429 DNS domain name. 431 FTP [RFC 959 " FILE TRANSFER PROTOCOL (FTP)"] is silent on domain 432 names but client implementations of the protocol behave as SSH 433 clients, being aware the differences between definitions of Domain 434 Names (DNS vs. MulticastDNS). 436 DHCP [RFC 2131 "Dynamic Host Configuration Protocol"] includes domain 437 names in it's Domain Search Option [RFC 3397 "Dynamic Host 438 Configuration Protocol (DHCP) Domain Search Option"]. The encoding of 439 Domain Names used is the on-the-wire format of the DNS, using 440 DNS-defined message compression. DHCP handles Domain Names in other 441 options such as in RFC 4702 defined "The DHCP Client FQDN Option", in 442 the same format. The significance of this is that most other 443 protocols represent DNS domain names or host names in a human readable 444 form, DHCP is using the machine-friendly format. 446 4. Interoperability Considerations 448 Any single protocol is able to define a format for a conceptual Domain 449 Name. Examples given above show that many protocol have done so. 450 From the examples it is clear that the way in which protocols have 451 interpreted Domain Names has varied, leading to, at least, user 452 interfaces having to have built-in intelligence when handling names 453 and, at worst, a growing confusion over how the Domain Name space is 454 to be managed. 456 When protocols having different formats and rules for Domain Names 457 interact, software implementing the protocols translate one protocol's 458 domain name format to another's format. Even when the translation is 459 straightforward, software often fails to handle error conditions well. 460 (Is there a citation for that?) 462 Often times the clash of definitions impacts the design of a new 463 protocol and/or an extension of a protocol. For example, adding 464 non-ASCII domain names has to be done with backwards compatibility 465 with an installed base of ASCII-assuming code. This clash can 466 inhibit new uses of Domain Names. 468 Search lists are a Domain Name mechanism studied in SAC064 "SSAC 469 Advisory on DNS 'Search List' Processing". One of the particular 470 use cases related to this topic is the issuance of search lists via 471 DHCP and then used by any user-client protocol implementation. This 472 emphasizes an interoperability consideration for how Domain Names 473 are treated in different protocols, not just among implementations of 474 one protocol. 476 The definition of a Fully Qualified Domain Name has two forms. The 477 discussion over FQDN involved human-readable names. The principle 478 question is whether to require the terminating dot or to assume it 479 when the end of an input string is hit. Many protocol clients will 480 silently add a dot when a user types in a name to a command line. But 481 some definitions, such as the one in SAC064 require the terminating 482 dot to be included before a name is considered to be fully qualified. 484 The Special Use Domain Names registry defined in RFC 6761 lists Domain 485 Names that are to be treated in a manner inconsistent with the DNS 486 normal processing rules. This registry contains Domain Names 487 regardless of whether the name is a DNS domain name and regardless 488 whether the name is a top-level (domain) name [RFC 819] or is 489 positioned elsewhere in the tree structure. 491 These are reasons this document is needed. The reason for the 492 confusion over what's a legal domain name stems from 493 application-defined restrictions. For example, using a one-label 494 domain name ("dotless") for sending email is not a problem with the 495 DNS nor the name in concept, but is a problem for mail implementations 496 that expect more than one label. (One-label names may be assumed to 497 be in ARPA host table format.) 499 4.1(*) Use of Top-Level Domains as Protocol Identifiers 501 (Would like to have "dns" and "dns" added to the Special Use 502 Domain Names registry. As well as the digits [address literals].) 504 (*) - I am not sure this belongs in this document. The idea is what 505 one can select a name space by the top-level domain (label). I 506 believe this would be scope creep for this document. Leaving it 507 here for consideration. 509 5. Acknowledgements 511 Input received from Andrew Sullivan and Paul Hoffman. Not to imply 512 endorsements of the text. 514 6. IANA Considerations 516 None. 518 7. Security Considerations 520 Nothing direct. This document proposes a definition of the term 521 "Domain Name" and surveys how it has been variously applied. In 522 some sense, loosely defined terms give rise to security hazards. 523 Beyond that, there is no impact of "security." 525 8. References 527 Many references are in-line throughout the text with titles to ease 528 comprehension of the prose. All documents cited are listed here. 529 Whether there is a normative/informative split will depend what, if 530 any, track this document is processed. For now, consider this a 531 reading list on the topic. 533 ANSIX34 American National Standards Institute (formerly United 534 States of America Standards Institute), "USA Code for 535 Information Interchange", ANSI X3.4-1968, 1968 537 RFC 20 Cerf, V., "ASCII format for network interchange", STD 80, 538 RFC 20, DOI 10.17487/RFC0020, October 1969, 539 . 541 RFC 788 Postel, J., "Simple Mail Transfer Protocol", RFC 788, DOI 542 10.17487/RFC0788, November 1981, 543 . 545 RFC 799 Mills, D., "Internet name domains", RFC 799, DOI 546 10.17487/RFC0799, September 1981, 547 . 549 RFC 801 Postel, J., "NCP/TCP transition plan", RFC 801, DOI 550 10.17487/RFC0801, November 1981, 551 . 553 RFC 805 Postel, J., "Computer mail meeting notes", RFC 805, DOI 554 10.17487/RFC0805, February 1982, 555 . 557 RFC 819 Postel, J., "Computer mail meeting notes", RFC 805, DOI 558 10.17487/RFC0805, February 1982, 559 . 561 RFC 882 Mockapetris, P., "Domain names: Concepts and facilities", 562 RFC 882, DOI 10.17487/RFC0882, November 1983, 563 . 565 RFC 883 Mockapetris, P., "Domain names: Implementation 566 specification", RFC 883, DOI 10.17487/RFC0883, November 567 1983, . 569 RFC 952 Mockapetris, P., "Domain names: Implementation 570 specification", RFC 883, DOI 10.17487/RFC0883, November 571 1983, . 573 RFC 959 Postel, J. and J. Reynolds, "File Transfer Protocol", STD 574 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 575 . 577 RFC 1034 Mockapetris, P., "Domain names - concepts and facilities", 578 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 579 . 581 RFC 1035 Mockapetris, P., "Domain names - implementation and 582 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 583 November 1987, . 585 RFC 1123 Braden, R., Ed., "Requirements for Internet Hosts - 586 Application and Support", STD 3, RFC 1123, DOI 587 10.17487/RFC1123, October 1989, 588 . 590 RFC 1945 Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 591 Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 592 10.17487/RFC1945, May 1996, 593 . 595 RFC 2131 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 596 DOI 10.17487/RFC2131, March 1997, 597 . 599 RFC 3397 Aboba, B. and S. Cheshire, "Dynamic Host Configuration 600 Protocol (DHCP) Domain Search Option", RFC 3397, 601 DOI 10.17487/RFC3397, November 2002, 602 . 604 RFC 3492 Costello, A., "Punycode: A Bootstring encoding of Unicode 605 for Internationalized Domain Names in Applications (IDNA)", 606 RFC 3492, DOI 10.17487/RFC3492, March 2003, 607 . 609 RFC 4251 Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 610 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 611 January 2006, . 613 RFC 4290 Klensin, J., "Suggested Practices for Registration of 614 Internationalized Domain Names (IDN)", RFC 4290, DOI 615 10.17487/RFC4290, December 2005, 616 . 618 RFC 4702 Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 619 Configuration Protocol (DHCP) Client Fully Qualified Domain 620 Name (FQDN) Option", RFC 4702, DOI 10.17487/RFC4702, 621 October 2006, . 623 RFC 5198 Klensin, J. and M. Padlipsky, "Unicode Format for Network 624 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 625 . 627 RFC 5280 Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 628 Housley, R., and W. Polk, "Internet X.509 Public Key 629 Infrastructure Certificate and Certificate Revocation 630 List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 631 May 2008, . 633 RFC 5321 Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 634 10.17487/RFC5321, October 2008, 635 . 637 RFC 5890 Klensin, J., "Internationalized Domain Names for 638 Applications (IDNA): Definitions and Document Framework", 639 RFC 5890, DOI 10.17487/RFC5890, August 2010, 640 . 642 RFC 6761 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 643 RFC 6761, DOI 10.17487/RFC6761, February 2013, 644 . 646 RFC 6762 Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 647 DOI 10.17487/RFC6762, February 2013, 648 . 650 Diestel Diestel, R., "Graph Theory", Springer-Verlag, Heidelberg 651 Graduate Texts in Mathematics, Volume 173 ISBN 652 978-3-642-14278-9, July 2010 (2005, 2000, 1997), 653 655 SAC064 ICANN Security and Stability Committee, "SSAC Advisory on 656 Search List Processing", SAC064, February 2014, 657 659 RENDEV Anonymous, "Tor Rendezvous Specification", Undated, 660 663 OHOST Nick Mathewson, "Special Hostnames in Tor", Undated, 664 667 DNSOP1 Alex Muffett, "Re: [DNSOP] Last Call: 668 (The .onion Special-Use 669 Domain Name) to Proposed Standard", DNSOP@IETF.ORG archived 670 message, August 2015, 671 674 9. Author's Address 676 Edward Lewis 677 ICANN 678 801 17th Street NW 679 Suite 401 680 Washington DC, 20006 US 681 edward.lewis@icann.org 683 Lewis Expires March 19, 2016 [Page 1]