idnits 2.17.1 draft-eastlake-2606bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 254. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 246), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6765 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) == Unused Reference: 'RFC 1034' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'RFC 1591' is defined on line 264, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1591 Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Donald E. Eastlake 3rd 3 Obsoletes RFC 2606 Motorola Laboratories 4 Expires: April 2006 October 2005 6 Reserved Top Level DNS Names 7 -------- --- ----- --- ----- 8 10 Status of This Document 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Distribution of this draft is unlimited. It is intended to become 18 the new BCP 32 obsoleting RFC 2606. Comments should be sent to the 19 author or the DNS Working Group mailing list 20 . 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than a "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). All Rights Reserved. 42 Abstract 44 To reduce the likelihood of conflict and confusion, a few top level 45 and a number of other domain names are reserved for use in private 46 testing, as examples in documentation, and the like. In addition, a 47 number of other domain names labels reserved to avoid confusing names 48 or other purposes. 50 Table of Contents 52 Status of This Document....................................1 53 Copyright Notice...........................................1 54 Abstract...................................................1 56 Table of Contents..........................................2 58 1. Introduction............................................3 59 2. TLDs for Testing, & Documentation Examples..............3 60 3. Reserved Second Level Domain Names......................4 61 3.1 Labels Reserved at All Levels..........................4 62 3.2 Additional Second-Level Reservations...................5 63 3.3 Tagged Domain Names....................................5 64 3.4 Second-Level Reservations for Registry Operators.......5 65 4. IANA Considerations.....................................6 66 5. Security Considerations.................................6 67 Appendix: Changes from RFC 2606............................6 69 Copyright and Disclaimer...................................7 70 Normative References.......................................7 71 Informative Reference......................................7 73 Authors Addresses..........................................8 74 Expiration and File Name...................................8 76 1. Introduction 78 The global Internet Domain Name System is documented in [RFC 1034, 79 1035, 1591] and numerous additional Requests for Comment. It defines 80 a tree of names starting with root, ".", immediately below which are 81 top level domain names such as ".com" and ".us". Below top level 82 domain names there are normally additional levels of names. 84 2. TLDs for Testing, & Documentation Examples 86 There is a need for top level domain (TLD) names that can be used for 87 creating names which, without fear of conflicts with current or 88 future actual TLD names in the global DNS, can be used for private 89 testing of existing DNS related code, examples in documentation, DNS 90 related experimentation, invalid DNS names, or other similar uses. 92 For example, without guidance, a site might set up some local 93 additional unused top level domains for testing of its local DNS code 94 and configuration. Later, these TLDs might come into actual use on 95 the global Internet. As a result, local attempts to reference the 96 real data in these zones could be thwarted by the local test 97 versions. Or test or example code might be written that accesses a 98 TLD that is in use with the thought that the test code would only be 99 run in a restricted testbed net or the example never actually run. 100 Later, the test code could escape from the testbed or the example be 101 actually coded and run on the Internet. Depending on the nature of 102 the test or example, it might be best for it to be referencing a TLD 103 permanently reserved for such purposes. 105 To safely satisfy these needs, four domain names are reserved as 106 listed and described below. 108 .test 109 .example 110 .invalid 111 .localhost 113 ".test" is recommended for use in testing of current or new 114 DNS related code. 116 ".example" is recommended for use in documentation or as 117 examples. 119 ".invalid" is intended for use in online construction of 120 domain names that are sure to be invalid and which it is 121 obvious at a glance are invalid. 123 The ".localhost" TLD has traditionally been statically 125 defined in host DNS implementations as having an A record 126 pointing to the loop back IP address and is reserved for such 127 use. Any other use would conflict with widely deployed code 128 which assumes this use. 130 3. Reserved Second Level Domain Names 132 At the time of the issuance of [RFC 2606], the Internet Assigned 133 Numbers Authority (IANA, http://www.iana.org) had reserved the 134 following second level domain names reserved which can be used as 135 examples. 137 example.com 138 example.net 139 example.org 141 At this time, similar restrictions are by way of contract between the 142 Internet Corporation for Assigned Names and Numbers (ICANN, 143 http://www.icann.org) and the Registry Operators of many top level 144 domains. See . 146 The ICANN "Schedule of Reserved Names" most recent version, as of the 147 date of this document, is at 148 . It reserves the labels listed in the 150 following subsections, except when released by ICANN. 152 3.1 Labels Reserved at All Levels 154 These are reserved from initial registration, unless ICANN grants an 155 exemption, at the second level and at all deeper levels where the top 156 level registry operator performs registration. If they have been 157 previously registered, they may be renewed and there is no 158 restriction on their existence in delegated zones. 160 ICANN-related names: 161 aso 162 gnso 163 icann 164 internic 165 ccnso 166 IANA-related names: 167 afrinic 168 apnic 169 arin 170 example 171 gtld-servers 172 iab 173 iana 174 iana-servers 175 iesg 176 ietf 177 irtf 178 istf 179 lacnic 180 latnic 181 rfc-editor 182 ripe 183 root-servers 185 3.2 Additional Second-Level Reservations 187 The follows labels are prohibited as second level domain names: 189 All single character labels. 191 All two character labels unless a release is obtained from the 192 government and country-code manager if that two letter 193 combination is an assigned country-code or a release from the 194 ISO 3166 maintenance agency if it has not been so assigned. 196 3.3 Tagged Domain Names 198 All labels with hyphens in the third and fourth character positions 199 such as "bq--1k2n4h4b" or "xn--ndk061n". 201 3.4 Second-Level Reservations for Registry Operators 203 The following are reserved for the use of the top level domain 204 Registry Operator and will be transferred whenever the Operator 205 changes: 207 nic 208 whois 209 www 211 4. IANA Considerations 213 IANA has agreed to the four top level domain name reservations 214 specified in this document and will reserve them for the uses 215 indicated. 217 5. Security Considerations 219 Confusion and conflict can be caused by the use of a current or 220 future top level domain name in experimentation or testing, as an 221 example in documentation, to indicate invalid names, or as a synonym 222 for the loop back address. Test and experimental software can escape 223 and end up being run against the global operational DNS. Even 224 examples used "only" in documentation can end up being coded and 225 released or cause conflicts due to later real use and the possible 226 acquisition of intellectual property rights in such "example" names. 228 Similar considerations apply to second level and other domain name 229 labels, particularly confusion when such names are the well known 230 names of Internet infrastructure or standards organizations but are 231 held by arbitrary registrants in other top level domain names. 233 The reservation of several top level and other domain names for these 234 purposes by IANA and ICANN minimizes such confusion and conflict. 236 Appendix: Changes from RFC 2606 238 Addition of information about the reservation of 2nd and deeper level 239 domain names in ICANN contracts with top level domain Registry 240 Operators. 242 Copyright and Disclaimer 244 Copyright (C) The Internet Society (2005). This document is subject to 245 the rights, licenses and restrictions contained in BCP 78, and except 246 as set forth therein, the authors retain all their rights. 248 This document and the information contained herein are provided on an 249 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 250 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 251 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 252 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 253 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 254 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 256 Normative References 258 [RFC 1034] Mockapetris, P., "Domain names - concepts and facilities", 259 STD 13, RFC 1034, November 1987. 261 [RFC 1035] Mockapetris, P., "Domain names - implementation and 262 specification", STD 13, RFC 1035, November 1987. 264 [RFC 1591] Postel, J., "Domain Name System Structure and Delegation", 265 RFC 1591, March 1994. 267 Informative Reference 269 [RFC 2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 270 Names", BCP 32, RFC 2606, June 1999. 272 Authors Addresses 274 Donald E. Eastlake 3rd 275 Motorola Laboratories 276 155 Beaver Street 277 Milford, MA 01757 USA 279 Telephone: +1-508-786-7554 (w) 280 email: Donald.Eastlake@motorola.com 282 Expiration and File Name 284 This draft expires April 2006. 286 Its file name is draft-eastlake-2606bis-00.txt.