idnits 2.17.1 draft-chapin-rfc2606bis-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 31, 2011) is 4713 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) ** Downref: Normative reference to an Informational RFC: RFC 1591 (ref. '3') ** Obsolete normative reference: RFC 4234 (ref. '6') (Obsoleted by RFC 5234) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Chapin 3 Internet-Draft Interisle Consulting Group 4 Intended status: Standards Track M. McFadden 5 Expires: December 2, 2011 ICC 6 May 31, 2011 8 Reserved Top Level Domain Names 9 draft-chapin-rfc2606bis-00.txt 11 Abstract 13 The Internet Domain Name System (DNS) defines a tree of names 14 starting with root, ".", immediately below which are top level domain 15 (TLD) names such as ".com" and ".us". RFC2606 reserved a small 16 number of TLD names for use in documentation examples, private 17 testing, experiments, and other circumstances in which it is 18 desirable to avoid conflict with current or future actual TLD names 19 in the DNS. The evolution of Internet engineering and operation 20 practices since RFC2606 was published in 1999, and the expected 21 addition of new TLD names to the DNS, recommend this update to the 22 list of reserved TLD names, and the creation of a "reserved TLD name 23 registry" to which additional names may be added as new requirements 24 arise. 26 It is important to note that TLD names may be reserved, in other 27 contexts, for policy, political, or other reasons that are distinct 28 from the IETF's concern with Internet engineering and operations. 29 This document reserves TLD names only for operational and engineering 30 reasons. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 2, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Legacy Reserved Top Level Domain Names . . . . . . . . . . . . 4 68 3. Additional Reserved Top Level Domain Names and Reserved 69 TLD Name Registry . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 5. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Appendix - Initial Registry of Reserved Top Level Domain 75 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 The Internet Domain Name System is documented in RFC1034 [1], RFC1035 82 [2], RFC1591 [3] and numerous additional Requests for Comment. It 83 defines a tree of names starting with root, ".", immediately below 84 which are top level domain names such as ".com" and ".us". Below top 85 level domain names there are normally additional levels of names. 87 RFC2606 [5] reserved a small number of TLD names which, without fear 88 of conflicts with current or future actual top level domain names in 89 the global DNS, can be used for private testing of existing DNS 90 related code, examples in documentation, DNS related experimentation, 91 invalid DNS names, or other similar uses. RFC2606 [5] also noted 92 that the Internet Assigned Numbers Authority (IANA) reserves the 93 label "example" at the second level below the TLDs .com, .net, and 94 .org. 96 Since RFC2606 [5] was published in 1999, Internet engineering and 97 operation practices have evolved in ways that recommend this update 98 to the list of reserved TLD names, and the creation of a "reserved 99 TLD name registry" to which additional labels may be added as new 100 requirements arise. This update is also prompted by the expected 101 advent of new TLDs which might, in the absence of the reservations 102 for which this document provides, introduce TLD labels that could 103 create engineering and operational problems for root server operators 104 and other DNS infrastructure providers. 106 It is important to note that TLD names may be reserved, in other 107 contexts, for policy, political, or other reasons that are distinct 108 from the IETF's concern with Internet engineering and operations. 109 This document reserves TLD names only for operational and engineering 110 reasons. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [4]. 116 2. Legacy Reserved Top Level Domain Names 118 The four top level domain name labels reserved by RFC2606 [5] for 119 testing and documentation examples remain reserved: 121 o test 123 o example 125 o invalid 127 o localhost 129 ".test" is recommended for use in testing of current or new DNS 130 related code. 132 ".example" is recommended for use in documentation or as examples. 134 ".invalid" is intended for use in online construction of domain names 135 that are sure to be invalid and which it is obvious at a glance are 136 invalid. 138 The ".localhost" TLD has traditionally been statically defined in 139 host DNS implementations as having an A record pointing to the loop 140 back IP address and is reserved for such use. Any other use would 141 conflict with widely deployed code which assumes this use. 143 This document makes no changes to the IANA reservation of the label 144 "example" at the second level. 146 3. Additional Reserved Top Level Domain Names and Reserved TLD Name 147 Registry 149 In its report of a quantitative study of queries to the DNS root 150 servers entitled "Invalid Top Level Domain Queries at the Root Level 151 of the Domain Name System" [7] [or, SAC 045] ICANN's Security and 152 Stability Advisory Committee "calls attention to the potential 153 problems that may arise should a new TLD applicant use a string that 154 has been seen with measurable (and meaningful) frequency in a query 155 for resolution by the root system and the root system has previously 156 generated a response." 158 Of particular concern is the case in which a string "has been queried 159 and a root name server has responded to the query with a non-existent 160 domain (NXDOMAIN) result, i.e., the string has not been delegated but 161 has been queried." SAC 045 reports the results of a CAIDA 162 measurement study [8] which found that "NXDOMAIN responses account 163 for more than 25 percent of the total responses from root name 164 servers observed in the study, and the top ten such strings account 165 for 10 percent of the total query load." 167 SAC 045 [7] describes in detail the engineering and operational 168 problems that would ensue from the delegation, as new valid TLD 169 names, of previously invalid labels that have frequently appeared in 170 queries to the root: "If the [new TLD label] were to be approved and 171 the TLD included in the root zone, queries to the root level of the 172 DNS for a string that hitherto returned NXDOMAIN would begin to 173 return positive responses containing name servers of the new TLD." 175 Recommendation (2) of SAC 045 [7] calls for the community to develop 176 principles for "prohibiting the delegation of additional strings to 177 those already identified in RFC2606 [5]." As the first step in that 178 process, based on the data reported by SAC 045 [7], this document 179 adds to the list of names that may not be used for top-level domains 180 the following labels: 182 .local 184 .localdomain 186 .domain 188 .lan 190 .home 192 .host 193 .corp 195 To facilitate the further steps that may be taken to pursue 196 Recommendation (2) of SAC 045 [7], IANA is requested to publish a new 197 registry of TLD names reserved by the IETF. This Reserved TLD Name 198 Registry should simply list the reserved TLD names with a reference 199 in each case to the authority for reserving the name. New names may 200 be added to the registry through "IETF Specification Required" as 201 provided by RFC4234 [6]. The initial contents of the registry are 202 the names listed in Appendix A of this document. 204 4. Security Considerations 206 One of the reasons cited in Section 1 for reserving specific labels 207 that cannot be used for valid top level domain names in the global 208 DNS is to make it possible for those labels to be used safely in 209 other contexts, without risk of conflict with "real" domain names. 210 Reserving these labels therefore effectively encourages their use in 211 locally-defined domain names that may resolve differently in 212 different local contexts. An application that looks up "foo.local" 213 on private network A, for example, may get a different result if it 214 looks up "foo.local" on private network B. 216 A name that resolves differently depending on where the lookup 217 request is made presents obvious security issues for any application 218 that does not expect this behavior. These issues arise from the use 219 of any locally-defined labels in domain names, whether or not they 220 are reserved. 222 5. IAB Considerations 224 There are no architectural implications related to reserving 225 individual strings at the top level of the DNS. 227 6. IANA Considerations 229 According to RFC2606 [5], IANA agreed to the top level domain 230 reservations in that document. However, IANA was not instructed to 231 publish a list of reserved names. 233 IANA is requested to publish a new registry of TLD strings reserved 234 by the IETF. The Reserved TLD Name registry will consist of a list 235 of reserved TLD names and a reference for each entry to the document 236 that put the strings into reserved status. 238 New strings are to be added to the registry through "IETF 239 Specification Required" as provided by RFC4234 [6]. The initial 240 content of the full registry is located in the Appendix to this 241 document. 243 7. Acknowledgements 245 Several studies have shown that a large fraction of the lookup 246 queries seen by the DNS root servers request information about 247 invalid TLDs. THe authors thank CAIDA, and in particular kc claffy, 248 for their work in this area. The authors are also indebted to the 249 contributors to SAC 045 which provided the impetus for this first 250 step at identifying a particular set of strings to be reserved. 251 David Conrad provided helpful input about potential security concerns 252 surrounding the reservation of strings at the root. 254 8. Appendix - Initial Registry of Reserved Top Level Domain Names 256 This is the initial registration for the registry of Reserved Top 257 Level Names in the DNS. The IANA is asked to use this material as 258 guidance for the creation of the initial registry. Future 259 registrations in this registry will be done through "IETF 260 Specification Required" as provided by RFC4234 [6]. 262 +--------------+----------------+ 263 | Label | Reference | 264 +--------------+----------------+ 265 | .corp | RFCxxx | 266 | | | 267 | .domain | RFCxxx | 268 | | | 269 | .example | RFC2606,RFCxxx | 270 | | | 271 | .home | RFCxxx | 272 | | | 273 | .host | RFCxxx | 274 | | | 275 | .invalid | RFC2606,RFCxxx | 276 | | | 277 | .lan | RFCxxx | 278 | | | 279 | .local | RFCxxx | 280 | | | 281 | .localdomain | RFCxxx | 282 | | | 283 | localhost | RFC2606,RFCxxx | 284 | | | 285 | test | RFC2606,RFCxxx | 286 +--------------+----------------+ 288 NOTE TO RFC EDITOR: The correct number of this document should be 289 substituted in the table above upon publication. At that time this 290 editing note should be deleted. 292 Table 1 294 9. Normative References 296 [1] Mockapetris, P., "Domain names - concepts and facilities", 297 STD 13, RFC 1034, November 1987. 299 [2] Mockapetris, P., "Domain names - implementation and 300 specification", STD 13, RFC 1035, November 1987. 302 [3] Postel, J., "Domain Name System Structure and Delegation", 303 RFC 1591, March 1994. 305 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 306 Levels", BCP 14, RFC 2119, March 1997. 308 [5] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", 309 BCP 32, RFC 2606, June 1999. 311 [6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 312 Specifications: ABNF", RFC 4234, October 2005. 314 [7] 316 [8] 319 Authors' Addresses 321 Lyman Chapin 322 Interisle Consulting Group 324 Phone: +1 617 686 2527 325 Email: lyman@interisle.net 326 URI: http://www.interisle.net 328 Mark McFadden 329 InterConnect Communications Ltd 330 Merlin House 331 Station Road 332 Chepstow NP16 5PB 333 UK 335 Phone: +1 608 628 2674 336 Email: markmcfadden@icc-uk.com 337 URI: http://www.icc-uk.com