idnits 2.17.1 draft-ietf-dnsop-default-local-zones-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 447. 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 Copyright Line does not match the current year -- 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 (June 8, 2007) is 6167 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 1035' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC 2434' is defined on line 333, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2398 (ref. 'RFC 2308') ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Andrews 3 Internet-Draft ISC 4 Intended status: Best Current June 8, 2007 5 Practice 6 Expires: December 10, 2007 8 Locally-served DNS Zones 9 draft-ietf-dnsop-default-local-zones-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 10, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Experience has shown that there are a number of DNS zones all 43 iterative resolvers and recursive nameservers should, unless 44 configured otherwise, automatically serve. RFC 4193 specifies that 45 this should occur for D.F.IP6.ARPA. This document extends the 46 practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space 47 and other well known zones with similar characteristics. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4 54 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4 55 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5 56 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 5 58 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6 59 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6 60 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 6 61 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 Appendix A. Change History [To Be Removed on Publication] . . . . 9 69 A.1. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 9 70 A.2. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 9 71 A.3. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 9 72 A.4. draft-andrews-full-service-resolvers-03.txt . . . . . . . 9 73 A.5. draft-andrews-full-service-resolvers-02.txt . . . . . . . 9 74 Appendix B. Proposed Status [To Be Removed on Publication] . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 Intellectual Property and Copyright Statements . . . . . . . . . . 11 78 1. Introduction 80 Experience has shown that there are a number of DNS [RFC 1034] [RFC 81 1035] zones that all iterative resolvers and recursive nameservers 82 SHOULD, unless intentionally configured otherwise, automatically 83 serve. These zones include, but are not limited to, the IN-ADDR.ARPA 84 zones for the address space allocated by [RFC 1918] and the IP6.ARPA 85 zones for locally assigned unique local IPv6 addresses, [RFC 4193]. 87 This recommendation is made because data has shown that significant 88 leakage of queries for these name spaces is occurring, despite 89 instructions to restrict them, and because it has therefore become 90 necessary to deploy sacrificial name servers to to protect the 91 immediate parent name servers for these zones from excessive, 92 unintentional, query load [AS112]. There is every expectation that 93 the query load will continue to increase unless steps are taken as 94 outlined here. 96 Additionally, queries from clients behind badly configured firewalls 97 that allow outgoing queries for these name spaces but drop the 98 responses put a significant load on the root servers. They also 99 cause operational load for the root server operators as they have to 100 reply to queries about why the root servers are "attacking" these 101 clients. Changing the default configuration will address all these 102 issues for the zones listed in Section 4. 104 [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled 105 locally. This document extends the recommendation to cover the IN- 106 ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and 107 IP6.ARPA zones for which queries should not appear on the public 108 Internet. 110 It is hoped that by doing this the number of sacrificial servers 111 [AS112] will not have to be increased, and may in time be reduced. 113 This recommendation should also help DNS responsiveness for sites 114 which are using [RFC 1918] addresses but do not follow the last 115 paragraph in Section 3 of [RFC 1918]. 117 1.1. Reserved Words 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC 2119]. 123 2. Effects on sites using RFC 1918 addresses. 125 For most sites using [RFC 1918] addresses, the changes here will have 126 little or no detrimental effect. If the site does not already have 127 the reverse tree populated the only effect will be that the name 128 error responses will be generated locally rather than remotely. 130 For sites that do have the reverse tree populated, most will either 131 have a local copy of the zones or will be forwarding the queries to 132 servers which have local copies of the zone. Therefore this 133 recommendation will not be relevant. 135 The most significant impact will be felt at sites that make use of 136 delegations for [RFC 1918] addresses and have populated these zones. 137 These sites will need to override the default configuration expressed 138 in this document to allow resolution to continue. Typically, such 139 sites will be fully disconnected from the Internet and have their own 140 root servers for their own non-Internet DNS tree. 142 3. Changes to Iterative Resolver Behaviour. 144 Unless configured otherwise, an iterative resolver will now return 145 name errors (RCODE=3) for queries within the zones in Section 4, with 146 the obvious exception of queries for the zone name itself where SOA, 147 NS and "no data" responses will be returned as appropriate to the 148 query type. One common way to do this is to serve empty (SOA and NS 149 only) zones. 151 An implementation of this recommendation MUST provide a mechanism to 152 disable this new behaviour, and SHOULD do so on a zone by zone basis. 154 If using empty zones one SHOULD NOT use the same NS and SOA records 155 as used on the public Internet servers as that will make it harder to 156 detect leakage to the public Internet servers. This document 157 recommends that the NS record defaults to the name of the zone and 158 the SOA MNAME defaults to the name of the only NS RR's target. The 159 SOA RNAME should default to "nobody.invalid." [RFC 2606]. 160 Implementations SHOULD provide a mechanism to set these values. No 161 address records need to be provided for the name server. 163 Below is an example of a generic empty zone in master file format. 164 It will produce a negative cache TTL of 3 hours. 166 @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 167 @ 10800 IN NS @ 169 The SOA RR is needed to support negative caching [RFC 2308] of name 170 error responses and to point clients to the primary master for DNS 171 dynamic updates. 173 SOA values of particular importance are the MNAME, the SOA RR's TTL 174 and the negTTL value. Both TTL values SHOULD match. The rest of the 175 SOA timer values MAY be chosen arbitrarily since it they are not 176 intended to control any zone transfer activity. 178 The NS RR is needed as some UPDATE clients use NS queries to discover 179 the zone to be updated. Having no address records for the name 180 server should abort UPDATE processing in the client. 182 4. Lists Of Zones Covered 184 4.1. RFC 1918 Zones 186 10.IN-ADDR.ARPA 187 16.172.IN-ADDR.ARPA 188 17.172.IN-ADDR.ARPA 189 18.172.IN-ADDR.ARPA 190 19.172.IN-ADDR.ARPA 191 20.172.IN-ADDR.ARPA 192 21.172.IN-ADDR.ARPA 193 22.172.IN-ADDR.ARPA 194 23.172.IN-ADDR.ARPA 195 24.172.IN-ADDR.ARPA 196 25.172.IN-ADDR.ARPA 197 26.172.IN-ADDR.ARPA 198 27.172.IN-ADDR.ARPA 199 28.172.IN-ADDR.ARPA 200 29.172.IN-ADDR.ARPA 201 30.172.IN-ADDR.ARPA 202 31.172.IN-ADDR.ARPA 203 168.192.IN-ADDR.ARPA 205 4.2. RFC 3330 Zones 207 See [RFC 3330]. 209 +------------------------------+------------------------------+ 210 | Zone | Description | 211 +------------------------------+------------------------------+ 212 | 0.IN-ADDR.ARPA | /* IPv4 "THIS" NETWORK */ | 213 | 127.IN-ADDR.ARPA | /* IPv4 LOOP-BACK NETWORK */ | 214 | 254.169.IN-ADDR.ARPA | /* IPv4 LINK LOCAL */ | 215 | 2.0.192.IN-ADDR.ARPA | /* IPv4 TEST NET */ | 216 | 255.255.255.255.IN-ADDR.ARPA | /* IPv4 BROADCAST */ | 217 +------------------------------+------------------------------+ 219 4.3. Local IPv6 Unicast Addresses 221 See [RFC 4291], Sections 2.4, 2.5.2 and 2.5.3. 223 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP 224 6.ARPA 225 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP 226 6.ARPA 228 4.4. IPv6 Locally Assigned Local Addresses 230 See [RFC 4193]. 232 D.F.IP6.ARPA 234 4.5. IPv6 Link Local Addresses 236 See [RFC 4291], Sections 2.4 and 2.5.6. 238 8.E.F.IP6.ARPA 239 9.E.F.IP6.ARPA 240 A.E.F.IP6.ARPA 241 B.E.F.IP6.ARPA 243 5. Zones that are Out-Of-Scope 245 IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.57, and IPv6 246 Centrally Assigned Local [RFC 4193] addresses are not covered here. 247 It is expected that IPv6 site-local addresses will be self correcting 248 as IPv6 implementations remove support for site-local addresses. 249 However, sacrificial servers for C.E.F.IP6.ARPA through 250 F.E.F.IP6.ARPA may still need to be deployed in the short term if the 251 traffic becomes excessive. 253 For IPv6 Centrally Assigned Local addresses (L = 0) [RFC 4193], there 254 has been no decision made about whether the registries will provide 255 delegations in this space or not. If they don't, then C.F.IP6.ARPA 256 will need to be added to the list in Section 4.4. If they do, then 257 registries will need to take steps to ensure that name servers are 258 provided for these addresses. 260 This document also ignores IP6.INT. IP6.INT has been wound up with 261 only legacy resolvers now generating reverse queries under IP6.INT. 263 This document has also deliberately ignored names immediately under 264 the root. While there is a subset of queries to the roots which 265 could be addressed using the techniques described here (e.g. .local, 266 .workgroup and IPv4 addresses), there is also a vast amount of 267 traffic that requires a different strategy (e.g. lookups for 268 unqualified hostnames, IPv6 addresses). 270 6. IANA Considerations 272 This document requests that IANA establish a registry of zones which 273 require this default behaviour. The initial contents of which are in 274 Section 4. Implementors are encouraged to check this registry and 275 adjust their implementations to reflect changes therein. 277 This registry can be amended through "IETF Consensus" as per [RFC 278 2434] or IETF Review in 2434bis. 280 ICANN should co-ordinate with the RIRs to ensure that DNSSEC 281 deployment in the reverse trees that these zone are delegated from 282 happens in the manner described in Section 7. 284 7. Security Considerations 286 During the initial deployment phase, particularly where [RFC 1918] 287 addresses are in use, there may be some clients that unexpectedly 288 receive a name error rather than a PTR record. This may cause some 289 service disruption until full service resolvers have been re- 290 configured. 292 As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA 293 namespaces, the zones listed above will need to be delegated as 294 insecure delegations. This will allow DNSSEC validation to succeed 295 for queries in these spaces despite not being answered from the 296 delegated servers. 298 It is recommended that sites actively using these namespaces secure 299 them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust 300 anchors. This will protect the clients from accidental leakage of 301 unsigned answers from the Internet. 303 8. Acknowledgements 305 This work was supported by the US National Science Foundation 306 (research grant SCI-0427144) and DNS-OARC. 308 9. References 310 9.1. Normative References 312 [RFC 1034] 313 Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 314 RFC 1034, STD 13, November 1987. 316 [RFC 1035] 317 Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND 318 SPECIFICATION", RFC 1035, STD 13, November 1987. 320 [RFC 1918] 321 Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 322 and E. Lear, "Address Allocation for Private Internets", 323 RFC 1918, February 1996. 325 [RFC 2119] 326 Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [RFC 2308] 330 Andrews, M., "Negative Caching of DNS Queries (DNS 331 NCACHE)", RFC 2398, March 1998. 333 [RFC 2434] 334 Narten, T. and H. Alvestrand, "Guidelines for Writing an 335 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 336 October 1998. 338 [RFC 2606] 339 Eastlake, D. and A. Panitz, "Reserved Top Level DNS 340 Names", BCP 32, RFC 2606, June 1999. 342 [RFC 4035] 343 Arends, R., Austein, R., Larson, M., Massey, D., and S. 344 Rose, "Protocol Modifications for the DNS Security 345 Extensions", RFC 4035, March 2005. 347 [RFC 4193] 348 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 349 Addresses", RFC 4193, October 2005. 351 [RFC 4291] 352 Hinden, R. and S. Deering, "IP Version 6 Addressing 353 Architecture", RFC 4291, February 2006. 355 9.2. Informative References 357 [AS112] "AS112 Project", . 359 [RFC 3330] 360 "Special-Use IPv4 Addresses", RFC 3330, September 2002. 362 Appendix A. Change History [To Be Removed on Publication] 364 A.1. draft-ietf-dnsop-default-local-zones-02.txt 366 RNAME now "nobody.invalid." 368 Revised language. 370 A.2. draft-ietf-dnsop-default-local-zones-01.txt 372 Revised impact description. 374 Updated to reflect change in IP6.INT status. 376 A.3. draft-ietf-dnsop-default-local-zones-00.txt 378 Adopted by DNSOP. 380 "Author's Note" re-titled "Zones that are Out-Of-Scope" 382 Add note that these zone are expected to seed the IANA registry. 384 Title changed. 386 A.4. draft-andrews-full-service-resolvers-03.txt 388 Added "Proposed Status". 390 A.5. draft-andrews-full-service-resolvers-02.txt 392 Added 0.IN-ADDR.ARPA. 394 Appendix B. Proposed Status [To Be Removed on Publication] 396 This Internet-Draft is being submitted for eventual publication as an 397 RFC with a proposed status of Best Current Practice. 399 Author's Address 401 Mark P. Andrews 402 Internet Systems Consortium 403 950 Charter Street 404 Redwood City, CA 94063 405 US 407 Email: Mark_Andrews@isc.org 409 Full Copyright Statement 411 Copyright (C) The IETF Trust (2007). 413 This document is subject to the rights, licenses and restrictions 414 contained in BCP 78, and except as set forth therein, the authors 415 retain all their rights. 417 This document and the information contained herein are provided on an 418 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 419 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 420 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 421 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 422 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 423 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 425 Intellectual Property 427 The IETF takes no position regarding the validity or scope of any 428 Intellectual Property Rights or other rights that might be claimed to 429 pertain to the implementation or use of the technology described in 430 this document or the extent to which any license under such rights 431 might or might not be available; nor does it represent that it has 432 made any independent effort to identify any such rights. Information 433 on the procedures with respect to rights in RFC documents can be 434 found in BCP 78 and BCP 79. 436 Copies of IPR disclosures made to the IETF Secretariat and any 437 assurances of licenses to be made available, or the result of an 438 attempt made to obtain a general license or permission for the use of 439 such proprietary rights by implementers or users of this 440 specification can be obtained from the IETF on-line IPR repository at 441 http://www.ietf.org/ipr. 443 The IETF invites any interested party to bring to its attention any 444 copyrights, patents or patent applications, or other proprietary 445 rights that may cover technology that may be required to implement 446 this standard. Please address the information to the IETF at 447 ietf-ipr@ietf.org. 449 Acknowledgment 451 Funding for the RFC Editor function is provided by the IETF 452 Administrative Support Activity (IASA).