+++ /dev/null
-
-
-
-Network Working Group M. Andrews
-Internet-Draft ISC
-Intended status: Best Current March 2, 2007
-Practice
-Expires: September 3, 2007
-
-
- Locally-served DNS Zones
- draft-ietf-dnsop-default-local-zones-01
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 3, 2007.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-Abstract
-
- Practice has shown that there are a number of DNS zones all iterative
- resolvers and recursive nameservers should, unless configured
- otherwise, automatically serve. RFC 4193 already specifies that this
- should occur for D.F.IP6.ARPA. This document extends the practice to
- cover the IN-ADDR.ARPA zones for RFC 1918 address space and other
- well known zones with similar usage constraints.
-
-
-
-
-Andrews Expires September 3, 2007 [Page 1]
-\f
-Internet-Draft Locally-served DNS Zones March 2007
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 3
- 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4
- 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5
- 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5
- 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 5
- 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6
- 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6
- 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 6
- 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 6
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
- Appendix A. Change History [To Be Removed on Publication] . . . . 9
- A.1. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 9
- A.2. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 9
- A.3. draft-andrews-full-service-resolvers-03.txt . . . . . . . 9
- A.4. draft-andrews-full-service-resolvers-02.txt . . . . . . . 9
- Appendix B. Proposed Status [To Be Removed on Publication] . . . 9
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
- Intellectual Property and Copyright Statements . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews Expires September 3, 2007 [Page 2]
-\f
-Internet-Draft Locally-served DNS Zones March 2007
-
-
-1. Introduction
-
- Practice has shown that there are a number of DNS [RFC 1034] [RFC
- 1035] zones all iterative resolvers and recursive nameservers should,
- unless configured otherwise, automatically serve. These zones
- include, but are not limited to, the IN-ADDR.ARPA zones for the
- address space allocated by [RFC 1918] and the IP6.ARPA zones for
- locally assigned local IPv6 addresses, [RFC 4193].
-
- This recommendation is made because data has shown that significant
- leakage of queries for these name spaces is occurring, despite
- instructions to restrict them, and because sacrificial name servers
- have been deployed to protect the immediate parent name servers for
- these zones from excessive, unintentional, query load [AS112]. There
- is every expectation that the query load will continue to increase
- unless steps are taken as outlined here.
-
- Additionally, queries from clients behind badly configured firewalls
- that allow outgoing queries but drop responses for these name spaces
- also puts a significant load on the root servers. They also cause
- operational load for the root server operators as they have to reply
- to queries about why the root servers are "attacking" these clients.
- Changing the default configuration will address all these issues for
- the zones listed below in Section 4.
-
- [RFC 4193] already recommends that queries for D.F.IP6.ARPA be
- handled locally. This document extends the recommendation to cover
- the IN-ADDR.ARPA zones for [RFC 1918] and other well known IN-
- ADDR.ARPA and IP6.ARPA zones for which queries should not appear on
- the public Internet.
-
- It is hoped that by doing this the number of sacrificial servers
- [AS112] will not have to be increased and may in time be reduced.
-
- It should also help DNS responsiveness for sites which are using [RFC
- 1918] addresses but do not follow the last paragraph in section 3 of
- [RFC 1918].
-
-1.1. Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-2. Effects on sites using RFC 1918 addresses.
-
- For most sites using [RFC 1918] addresses, the changes here will have
-
-
-
-Andrews Expires September 3, 2007 [Page 3]
-\f
-Internet-Draft Locally-served DNS Zones March 2007
-
-
- little or no detrimental effect. If the site does not already have
- the reverse tree populated the only effect will be that the answers
- are generated locally rather than remotely.
-
- For sites that do have the reverse tree populated, most will either
- have a local copy of the zones or will be forwarding the queries to
- servers which have local copies of the zone. In either case the
- local resolver has a pre-existing configuration for the namespace and
- won't add the automatic zone.
-
- The main impact will be felt at sites that make use of delegation for
- reverse lookups for [RFC 1918] addresses and have populated these
- zones. Typically, such sites will be fully disconnected from the
- Internet and have their own root servers for their own non-Internet
- DNS tree. These sites will need to override the default
- configuration expressed in this document to allow resolution to
- continue.
-
-
-3. Changes to Iterative Resolver Behaviour.
-
- Unless configured otherwise, an iterative resolver will now return
- name errors (RCODE=3) for queries within the lists of zones covered
- below, with the obvious exception of queries for the zone name itself
- where SOA, NS and "no data" responses will be returned as appropriate
- to the query type. One common way to do this is to serve empty (SOA
- and NS only) zones.
-
- A implementation doing this MUST provide a mechanism to disable this
- new behaviour, preferably on a zone by zone basis.
-
- If using empty zones one SHOULD NOT use the same NS and SOA records
- as used on the public Internet servers as that will make it harder to
- detect leakage to the public Internet servers. This document
- recommends that the NS record defaults to the name of the zone and
- the SOA MNAME defaults to the name of the only NS RR's target. The
- SOA RNAME should default to ".". Implementations SHOULD provide a
- mechanism to set these values. No address records need to be
- provided for the name server.
-
- Below is a example of a generic empty zone in master file format. It
- will produce a negative cache ttl of 3 hours.
-
- @ 10800 IN SOA @ . 1 3600 1200 604800 10800
- @ 10800 IN NS @
-
- The SOA RR is needed to support negative caching [RFC 2308] of name
- error responses and to point clients to the primary master for DNS
-
-
-
-Andrews Expires September 3, 2007 [Page 4]
-\f
-Internet-Draft Locally-served DNS Zones March 2007
-
-
- dynamic updates.
-
- SOA values of particular importance are the MNAME, the SOA RR's TTL
- and the negTTL value. Both TTL values SHOULD match. The rest of the
- SOA timer values may be chosen arbitrarily since it they are not
- intended to control any zone transfer activity.
-
- The NS RR is needed as some UPDATE clients use NS queries to discover
- they zone to be updated. Having no address records for the name
- server should abort UPDATE processing in the client
-
-
-4. Lists Of Zones Covered
-
- The lists below are expected to seed a IANA registry.
-
-4.1. RFC 1918 Zones
-
- 10.IN-ADDR.ARPA
- 16.172.IN-ADDR.ARPA
- 17.172.IN-ADDR.ARPA
- 18.172.IN-ADDR.ARPA
- 19.172.IN-ADDR.ARPA
- 20.172.IN-ADDR.ARPA
- 21.172.IN-ADDR.ARPA
- 22.172.IN-ADDR.ARPA
- 23.172.IN-ADDR.ARPA
- 24.172.IN-ADDR.ARPA
- 25.172.IN-ADDR.ARPA
- 26.172.IN-ADDR.ARPA
- 27.172.IN-ADDR.ARPA
- 28.172.IN-ADDR.ARPA
- 29.172.IN-ADDR.ARPA
- 30.172.IN-ADDR.ARPA
- 31.172.IN-ADDR.ARPA
- 168.192.IN-ADDR.ARPA
-
-4.2. RFC 3330 Zones
-
- See [RFC 3330].
-
- 0.IN-ADDR.ARPA /* IPv4 "THIS" NETWORK */
- 127.IN-ADDR.ARPA /* IPv4 LOOP-BACK NETWORK */
- 254.169.IN-ADDR.ARPA /* IPv4 LINK LOCAL */
- 2.0.192.IN-ADDR.ARPA /* IPv4 TEST NET */
- 255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */
-
-
-
-
-
-Andrews Expires September 3, 2007 [Page 5]
-\f
-Internet-Draft Locally-served DNS Zones March 2007
-
-
-4.3. Local IPv6 Unicast Addresses
-
- See [RFC 4291], sections 2.4, 2.5.2 and 2.5.3.
-
- 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
- 6.ARPA
- 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
- 6.ARPA
-
-4.4. IPv6 Locally Assigned Local Addresses
-
- See [RFC 4193].
-
- D.F.IP6.ARPA
-
-4.5. IPv6 Link Local Addresses
-
- See [RFC 4291], sections 2.4 and 2.5.6.
-
- 8.E.F.IP6.ARPA
- 9.E.F.IP6.ARPA
- A.E.F.IP6.ARPA
- B.E.F.IP6.ARPA
-
-
-5. Zones that are Out-Of-Scope
-
- IPv6 site-local addresses, [RFC 4291] sections 2.4 and 2.57, and IPv6
- Globally Assigned Local [RFC 4193] addresses are not covered here.
- It is expected that IPv6 site-local addresses will be self correcting
- as IPv6 implementations remove support for site-local addresses.
- However, sacrificial servers for C.E.F.IP6.ARPA to F.E.F.IP6.ARPA may
- still need to be deployed in the short term if the traffic becomes
- excessive.
-
- For IPv6 Globally Assigned Local addresses [RFC 4291] there has been
- no decision made about whether the registries will provide
- delegations in this space or not. If they don't, then C.F.IP6.ARPA
- will need to be added to the list above. If they do, then registries
- will need to take steps to ensure that name servers are provided for
- these addresses.
-
- This document is also ignoring IP6.INT. IP6.INT has been wound up
- with only legacy resolvers now generating reverse queries under
- IP6.INT.
-
- This document has also deliberately ignored names immediately under
- the root. While there is a subset of queries to the roots which
-
-
-
-Andrews Expires September 3, 2007 [Page 6]
-\f
-Internet-Draft Locally-served DNS Zones March 2007
-
-
- could be addressed using the techniques described here (e.g. .local
- and IPv4 addresses) there is also a vast amount of traffic that
- requires a different strategy (e.g. lookups for unqualied hostnames,
- IPv6 addresses).
-
-
-6. IANA Considerations
-
- This document recommends that IANA establish a registry of zones
- which require this default behaviour, the initial contents of which
- are in Section 4. More zones are expected to be added, and possibly
- deleted from this registry over time. Name server implementors are
- encouraged to check this registry and adjust their implementations to
- reflect changes therein.
-
- This registry can be amended through "IETF Consensus" as per [RFC
- 2434] or IETF Review in 2434bis.
-
- IANA should co-ordinate with the RIRs and ICANN to ensure the DNSSEC
- deployment in the reverse trees that these zone are delegated in a
- unsecure manner as per Security Considerations.
-
-
-7. Security Considerations
-
- During the initial deployment phase, particularly where [RFC 1918]
- addresses are in use, there may be some clients that unexpectedly
- receive a name error rather than a PTR record. This may cause some
- service disruption until full service resolvers have been re-
- configured.
-
- When DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
- namespaces, the zones listed above will need to be delegated as
- insecure delegations. This will allow DNSSEC validation to succeed
- for queries in these spaces despite not being answered from the
- delegated servers.
-
- It is recommended that sites actively using these namespaces secure
- them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
- anchors. This will protect the clients from accidental leakage of
- unsigned answers from the Internet.
-
-
-8. Acknowledgements
-
- This work was supported by the US National Science Foundation
- (research grant SCI-0427144) and DNS-OARC.
-
-
-
-
-Andrews Expires September 3, 2007 [Page 7]
-\f
-Internet-Draft Locally-served DNS Zones March 2007
-
-
-9. References
-
-9.1. Normative References
-
- [RFC 1034]
- Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- RFC 1034, STD 13, November 1987.
-
- [RFC 1035]
- Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION", RFC 1035, STD 13, November 1987.
-
- [RFC 1918]
- Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
- and E. Lear, "Address Allocation for Private Internets",
- RFC 1918, February 1996.
-
- [RFC 2119]
- Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2308]
- Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2398, March 1998.
-
- [RFC 2434]
- Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC 3330]
- "Special-Use IPv4 Addresses", RFC 3330, September 2002.
-
- [RFC 4035]
- Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC 4291]
- Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
-9.2. Informative References
-
- [AS112] "AS112 Project", <http://as112.net/>.
-
- [RFC 4193]
- Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-
-
-
-Andrews Expires September 3, 2007 [Page 8]
-\f
-Internet-Draft Locally-served DNS Zones March 2007
-
-
- Addresses", RFC 4193, October 2005.
-
-
-Appendix A. Change History [To Be Removed on Publication]
-
-A.1. draft-ietf-dnsop-default-local-zones-01.txt
-
- Revised impact description.
-
- Updated to reflect change in IP6.INT status.
-
-A.2. draft-ietf-dnsop-default-local-zones-00.txt
-
- Adopted by DNSOP.
-
- "Author's Note" re-titled "Zones that are Out-Of-Scope"
-
- Add note that these zone are expected to seed the IANA registry.
-
- Title changed.
-
-A.3. draft-andrews-full-service-resolvers-03.txt
-
- Added "Proposed Status".
-
-A.4. draft-andrews-full-service-resolvers-02.txt
-
- Added 0.IN-ADDR.ARPA.
-
-
-Appendix B. Proposed Status [To Be Removed on Publication]
-
- This Internet-Draft is being submitted for eventual publication as an
- RFC with a proposed status of Best Current Practice.
-
-
-Author's Address
-
- Mark P. Andrews
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- US
-
- Email: Mark_Andrews@isc.org
-
-
-
-
-
-
-Andrews Expires September 3, 2007 [Page 9]
-\f
-Internet-Draft Locally-served DNS Zones March 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Andrews Expires September 3, 2007 [Page 10]
-\f
-
--- /dev/null
+
+
+
+Network Working Group M. Andrews
+Internet-Draft ISC
+Intended status: Best Current November 19, 2007
+Practice
+Expires: May 22, 2008
+
+
+ Locally-served DNS Zones
+ draft-ietf-dnsop-default-local-zones-03
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on May 22, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ Experience has shown that there are a number of DNS zones all
+ iterative resolvers and recursive nameservers should, unless
+ configured otherwise, automatically serve. RFC 4193 specifies that
+ this should occur for D.F.IP6.ARPA. This document extends the
+ practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space
+ and other well known zones with similar characteristics.
+
+
+
+
+Andrews Expires May 22, 2008 [Page 1]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4
+ 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4
+ 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6
+ 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6
+ 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6
+ 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7
+ 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ Appendix A. Change History [To Be Removed on Publication] . . . . 10
+ A.1. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10
+ A.2. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10
+ A.3. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 10
+ A.4. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11
+ A.5. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11
+ A.6. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11
+ Appendix B. Proposed Status [To Be Removed on Publication] . . . 11
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews Expires May 22, 2008 [Page 2]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+1. Introduction
+
+ Experience has shown that there are a number of DNS [RFC 1034] [RFC
+ 1035] zones that all iterative resolvers and recursive nameservers
+ SHOULD, unless intentionally configured otherwise, automatically
+ serve. These zones include, but are not limited to, the IN-ADDR.ARPA
+ zones for the address space allocated by [RFC 1918] and the IP6.ARPA
+ zones for locally assigned unique local IPv6 addresses, [RFC 4193].
+
+ This recommendation is made because data has shown that significant
+ leakage of queries for these name spaces is occurring, despite
+ instructions to restrict them, and because it has therefore become
+ necessary to deploy sacrificial name servers to protect the immediate
+ parent name servers for these zones from excessive, unintentional,
+ query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
+ [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every
+ expectation that the query load will continue to increase unless
+ steps are taken as outlined here.
+
+ Additionally, queries from clients behind badly configured firewalls
+ that allow outgoing queries for these name spaces but drop the
+ responses, put a significant load on the root servers (forward but no
+ reverse zones configured). They also cause operational load for the
+ root server operators as they have to reply to enquiries about why
+ the root servers are "attacking" these clients. Changing the default
+ configuration will address all these issues for the zones listed in
+ Section 4.
+
+ [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled
+ locally. This document extends the recommendation to cover the IN-
+ ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and
+ IP6.ARPA zones for which queries should not appear on the public
+ Internet.
+
+ It is hoped that by doing this the number of sacrificial servers
+ [AS112] will not have to be increased, and may in time be reduced.
+
+ This recommendation should also help DNS responsiveness for sites
+ which are using [RFC 1918] addresses but do not follow the last
+ paragraph in Section 3 of [RFC 1918].
+
+1.1. Reserved Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+Andrews Expires May 22, 2008 [Page 3]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+2. Effects on sites using RFC 1918 addresses.
+
+ For most sites using [RFC 1918] addresses, the changes here will have
+ little or no detrimental effect. If the site does not already have
+ the reverse tree populated the only effect will be that the name
+ error responses will be generated locally rather than remotely.
+
+ For sites that do have the reverse tree populated, most will either
+ have a local copy of the zones or will be forwarding the queries to
+ servers which have local copies of the zone. Therefore this
+ recommendation will not be relevant.
+
+ The most significant impact will be felt at sites that make use of
+ delegations for [RFC 1918] addresses and have populated these zones.
+ These sites will need to override the default configuration expressed
+ in this document to allow resolution to continue. Typically, such
+ sites will be fully disconnected from the Internet and have their own
+ root servers for their own non-Internet DNS tree.
+
+
+3. Changes to Iterative Resolver Behaviour.
+
+ Unless configured otherwise, an iterative resolver will now return
+ authoritatively (aa=1) name errors (RCODE=3) for queries within the
+ zones in Section 4, with the obvious exception of queries for the
+ zone name itself where SOA, NS and "no data" responses will be
+ returned as appropriate to the query type. One common way to do this
+ is to serve empty (SOA and NS only) zones.
+
+ An implementation of this recommendation MUST provide a mechanism to
+ disable this new behaviour, and SHOULD allow this decision on a zone
+ by zone basis.
+
+ If using empty zones one SHOULD NOT use the same NS and SOA records
+ as used on the public Internet servers as that will make it harder to
+ detect the origin of the responses and thus any leakage to the public
+ Internet servers. This document recommends that the NS record
+ defaults to the name of the zone and the SOA MNAME defaults to the
+ name of the only NS RR's target. The SOA RNAME should default to
+ "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a
+ mechanism to set these values. No address records need to be
+ provided for the name server.
+
+ Below is an example of a generic empty zone in master file format.
+ It will produce a negative cache TTL of 3 hours.
+
+ @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 @ 10800
+ IN NS @
+
+
+
+Andrews Expires May 22, 2008 [Page 4]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+ The SOA RR is needed to support negative caching [RFC 2308] of name
+ error responses and to point clients to the primary master for DNS
+ dynamic updates.
+
+ SOA values of particular importance are the MNAME, the SOA RR's TTL
+ and the negTTL value. Both TTL values SHOULD match. The rest of the
+ SOA timer values MAY be chosen arbitrarily since they are not
+ intended to control any zone transfer activity.
+
+ The NS RR is needed as some UPDATE clients use NS queries to discover
+ the zone to be updated. Having no address records for the name
+ server is expected to abort UPDATE [RFC 2136] processing in the
+ client.
+
+
+4. Lists Of Zones Covered
+
+ The following subsections are intended to seed the IANA registry as
+ requested in the IANA Considerations Section. The zone name is the
+ entity to be registered.
+
+4.1. RFC 1918 Zones
+
+ The following zones correspond to the IPv4 address space reserved in
+ [RFC 1918].
+
+ +----------------------+
+ | Zone |
+ +----------------------+
+ | 10.IN-ADDR.ARPA |
+ | 16.172.IN-ADDR.ARPA |
+ | 17.172.IN-ADDR.ARPA |
+ | 18.172.IN-ADDR.ARPA |
+ | 19.172.IN-ADDR.ARPA |
+ | 20.172.IN-ADDR.ARPA |
+ | 21.172.IN-ADDR.ARPA |
+ | 22.172.IN-ADDR.ARPA |
+ | 23.172.IN-ADDR.ARPA |
+ | 24.172.IN-ADDR.ARPA |
+ | 25.172.IN-ADDR.ARPA |
+ | 26.172.IN-ADDR.ARPA |
+ | 27.172.IN-ADDR.ARPA |
+ | 28.172.IN-ADDR.ARPA |
+ | 29.172.IN-ADDR.ARPA |
+ | 30.172.IN-ADDR.ARPA |
+ | 31.172.IN-ADDR.ARPA |
+ | 168.192.IN-ADDR.ARPA |
+ +----------------------+
+
+
+
+Andrews Expires May 22, 2008 [Page 5]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+4.2. RFC 3330 Zones
+
+ The following zones correspond to those address ranges from [RFC
+ 3330] that are not expected to appear as source or destination
+ addresses on the public Internet and to not have a unique name to
+ associate with.
+
+ The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
+ attempt to discourage any practice to provide a PTR RR for
+ 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse
+ mapping should exist, but the exact setup is out of the scope of this
+ document. Similar logic applies to the reverse mapping for ::1
+ Section 4.3. The recommendations made here simply assume no other
+ coverage for these domains exists.
+
+ +------------------------------+------------------------+
+ | Zone | Description |
+ +------------------------------+------------------------+
+ | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
+ | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK |
+ | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
+ | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET |
+ | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
+ +------------------------------+------------------------+
+
+4.3. Local IPv6 Unicast Addresses
+
+ The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for
+ the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291],
+ Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
+
+ +-------------------------------------------+
+ | Zone |
+ +-------------------------------------------+
+ | 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.IP6.ARPA |
+ | 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.IP6.ARPA |
+ +-------------------------------------------+
+
+ Note: Line breaks and a escapes '\' have been inserted above for
+ readability and to adhere to line width constraints. They are not
+ parts of the zone names.
+
+4.4. IPv6 Locally Assigned Local Addresses
+
+ Section 4.4 of [RFC 4193] already required special treatment of:
+
+
+
+
+Andrews Expires May 22, 2008 [Page 6]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+ +--------------+
+ | Zone |
+ +--------------+
+ | D.F.IP6.ARPA |
+ +--------------+
+
+4.5. IPv6 Link Local Addresses
+
+ IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered
+ by four distinct reverse DNS zones:
+
+ +----------------+
+ | Zone |
+ +----------------+
+ | 8.E.F.IP6.ARPA |
+ | 9.E.F.IP6.ARPA |
+ | A.E.F.IP6.ARPA |
+ | B.E.F.IP6.ARPA |
+ +----------------+
+
+
+5. Zones that are Out-Of-Scope
+
+ IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.57, and IPv6
+ Centrally Assigned Local [RFC 4193] addresses are not covered here.
+ It is expected that IPv6 site-local addresses will be self correcting
+ as IPv6 implementations remove support for site-local addresses.
+ However, sacrificial servers for C.E.F.IP6.ARPA through
+ F.E.F.IP6.ARPA may still need to be deployed in the short term if the
+ traffic becomes excessive.
+
+ For IPv6 Centrally Assigned Local addresses (L = 0) [RFC 4193], there
+ has been no decision made about whether the Regional Internet
+ Registries (RIRs) will provide delegations in this space or not. If
+ they don't, then C.F.IP6.ARPA will need to be added to the list in
+ Section 4.4. If they do, then registries will need to take steps to
+ ensure that name servers are provided for these addresses.
+
+ This document also ignores IP6.INT. IP6.INT has been wound up with
+ only legacy resolvers now generating reverse queries under IP6.INT
+ [RFC 4159].
+
+ This document has also deliberately ignored names immediately under
+ the root domain. While there is a subset of queries to the root name
+ servers which could be addressed using the techniques described here
+ (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
+ amount of traffic that requires a different strategy (e.g. lookups
+ for unqualified hostnames, IPv6 addresses).
+
+
+
+Andrews Expires May 22, 2008 [Page 7]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+6. IANA Considerations
+
+ This document requests that IANA establish a registry of zones which
+ require this default behaviour. The initial contents of which are in
+ Section 4. Implementors are encouraged to check this registry and
+ adjust their implementations to reflect changes therein.
+
+ This registry can be amended through "IETF Consensus" as per [RFC
+ 2434].
+
+ IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
+ deployed in the reverse tree, delegations for these zones are made in
+ the manner described in Section 7.
+
+
+7. Security Considerations
+
+ During the initial deployment phase, particularly where [RFC 1918]
+ addresses are in use, there may be some clients that unexpectedly
+ receive a name error rather than a PTR record. This may cause some
+ service disruption until their recursive name server(s) have been re-
+ configured.
+
+ As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
+ namespaces, the zones listed above will need to be delegated as
+ insecure delegations, or be within insecure zones. This will allow
+ DNSSEC validation to succeed for queries in these spaces despite not
+ being answered from the delegated servers.
+
+ It is recommended that sites actively using these namespaces secure
+ them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
+ anchors. This will protect the clients from accidental import of
+ unsigned responses from the Internet.
+
+
+8. Acknowledgements
+
+ This work was supported by the US National Science Foundation
+ (research grant SCI-0427144) and DNS-OARC.
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC 1034]
+ Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
+ RFC 1034, STD 13, November 1987.
+
+
+
+Andrews Expires May 22, 2008 [Page 8]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+ [RFC 1035]
+ Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
+ SPECIFICATION", RFC 1035, STD 13, November 1987.
+
+ [RFC 1918]
+ Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+ and E. Lear, "Address Allocation for Private Internets",
+ RFC 1918, February 1996.
+
+ [RFC 2119]
+ Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC 2136]
+ Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+ [RFC 2308]
+ Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2398, March 1998.
+
+ [RFC 2434]
+ Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC 2606]
+ Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+ Names", BCP 32, RFC 2606, June 1999.
+
+ [RFC 3596]
+ Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IPv6", RFC 3596, October 2003.
+
+ [RFC 4035]
+ Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC 4159]
+ Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
+ August 2005.
+
+ [RFC 4193]
+ Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", RFC 4193, October 2005.
+
+
+
+
+Andrews Expires May 22, 2008 [Page 9]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+ [RFC 4291]
+ Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+9.2. Informative References
+
+ [AS112] "AS112 Project", <http://www.as112.net/>.
+
+ [I-D.draft-ietf-dnsop-as112-ops]
+ Abley, J. and W. Maton, "AS112 Nameserver Operations",
+ draft-ietf-dnsop-as112-ops-00 (work in progress),
+ February 2007.
+
+ [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
+ Abley, J. and W. Maton, "I'm Being Attacked by
+ PRISONER.IANA.ORG!",
+ draft-ietf-dnsop-as112-under-attack-help-help-00 (work in
+ progress), February 2007.
+
+ [RFC 3330]
+ "Special-Use IPv4 Addresses", RFC 3330, September 2002.
+
+
+Appendix A. Change History [To Be Removed on Publication]
+
+A.1. draft-ietf-dnsop-default-local-zones-03.txt
+
+ expanded section 4 descriptions
+
+ Added references [RFC 2136], [RFC 3596],
+ [I-D.draft-ietf-dnsop-as112-ops] and
+ [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
+
+ Revised language.
+
+A.2. draft-ietf-dnsop-default-local-zones-02.txt
+
+ RNAME now "nobody.invalid."
+
+ Revised language.
+
+A.3. draft-ietf-dnsop-default-local-zones-01.txt
+
+ Revised impact description.
+
+ Updated to reflect change in IP6.INT status.
+
+
+
+
+
+Andrews Expires May 22, 2008 [Page 10]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+A.4. draft-ietf-dnsop-default-local-zones-00.txt
+
+ Adopted by DNSOP.
+
+ "Author's Note" re-titled "Zones that are Out-Of-Scope"
+
+ Add note that these zone are expected to seed the IANA registry.
+
+ Title changed.
+
+A.5. draft-andrews-full-service-resolvers-03.txt
+
+ Added "Proposed Status".
+
+A.6. draft-andrews-full-service-resolvers-02.txt
+
+ Added 0.IN-ADDR.ARPA.
+
+
+Appendix B. Proposed Status [To Be Removed on Publication]
+
+ This Internet-Draft is being submitted for eventual publication as an
+ RFC with a proposed status of Best Current Practice.
+
+
+Author's Address
+
+ Mark P. Andrews
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ US
+
+ Email: Mark_Andrews@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews Expires May 22, 2008 [Page 11]
+\f
+Internet-Draft Locally-served DNS Zones November 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Andrews Expires May 22, 2008 [Page 12]
+\f
projects / thirdparty / bind9.git / commitdiff
