summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6303.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6303.txt')
-rw-r--r--doc/rfc/rfc6303.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc6303.txt b/doc/rfc/rfc6303.txt
new file mode 100644
index 0000000..b56eab9
--- /dev/null
+++ b/doc/rfc/rfc6303.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Andrews
+Request for Comments: 6303 ISC
+BCP: 163 July 2011
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+ Locally Served DNS Zones
+
+Abstract
+
+ Experience with the Domain Name System (DNS) has shown that there are
+ a number of DNS zones that all iterative resolvers and recursive
+ nameservers should automatically serve, unless configured otherwise.
+ 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.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6303.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Andrews Best Current Practice [Page 1]
+
+RFC 6303 Locally Served DNS Zones July 2011
+
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 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 5735 and RFC 5737 Zones ................................5
+ 4.3. Local IPv6 Unicast Addresses ...............................6
+ 4.4. IPv6 Locally Assigned Local Addresses ......................6
+ 4.5. IPv6 Link-Local Addresses ..................................7
+ 4.6. IPv6 Example Prefix ........................................7
+ 5. Zones That Are Out of Scope .....................................7
+ 6. IANA Considerations .............................................8
+ 7. Security Considerations .........................................8
+ 8. Acknowledgements ................................................9
+ 9. References ......................................................9
+ 9.1. Normative References .......................................9
+ 9.2. Informative References ....................................10
+
+1. Introduction
+
+ Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035])
+ has shown that there are a number of DNS zones that all iterative
+ resolvers and recursive nameservers SHOULD automatically serve,
+ unless intentionally configured otherwise. These zones include, but
+ are not limited to, the IN-ADDR.ARPA zones for the address space
+ allocated by [RFC1918] and the IP6.ARPA zones for locally assigned
+ unique local IPv6 addresses defined in [RFC4193].
+
+
+
+
+
+
+
+
+
+Andrews Best Current Practice [Page 2]
+
+RFC 6303 Locally Served DNS Zones July 2011
+
+
+ This recommendation is made because data has shown that significant
+ leakage of queries for these namespaces is occurring, despite
+ instructions to restrict them, and because it has therefore become
+ necessary to deploy sacrificial nameservers to protect the immediate
+ parent nameservers for these zones from excessive, unintentional
+ query load [AS112] [RFC6304] [RFC6305]. 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 namespaces, but drop the
+ responses, put a significant load on the root servers (forward zones
+ but not reverse zones are 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.
+
+ [RFC4193] recommends that queries for D.F.IP6.ARPA be handled
+ locally. This document extends the recommendation to cover the
+ IN-ADDR.ARPA zones for [RFC1918] 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
+ that are using [RFC1918] addresses but do not follow the last
+ paragraph in Section 3 of [RFC1918].
+
+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 [RFC2119].
+
+2. Effects on Sites Using RFC 1918 Addresses
+
+ For most sites using [RFC1918] 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 that have local copies of the zone. Therefore, this
+ recommendation will not be relevant.
+
+
+
+Andrews Best Current Practice [Page 3]
+
+RFC 6303 Locally Served DNS Zones July 2011
+
+
+ The most significant impact will be felt at sites that make use of
+ delegations for [RFC1918] 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
+ all at once 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. It is RECOMMENDED 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 (Resource Record's) target. The SOA RNAME
+ SHOULD default to "nobody.invalid." [RFC2606]. Implementations
+ SHOULD provide a mechanism to set these values. No address records
+ need to be provided for the nameserver.
+
+ Below is an example of a generic empty zone in master file format.
+ It will produce a negative cache Time to Live (TTL) of 3 hours.
+
+ @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
+ @ 10800 IN NS @
+
+ The SOA RR is needed to support negative caching [RFC2308] 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 [RFC2136] clients use NS queries
+ to discover the zone to be updated. Having no address records for
+ the nameserver is expected to abort UPDATE processing in the client.
+
+
+
+Andrews Best Current Practice [Page 4]
+
+RFC 6303 Locally Served DNS Zones July 2011
+
+
+4. Lists Of Zones Covered
+
+ The following subsections are the initial contents of the IANA
+ registry as described in the IANA Considerations section. Following
+ the caveat in that section, the list contains only reverse zones
+ corresponding to permanently assigned address space. 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
+ [RFC1918].
+
+ +----------------------+
+ | 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 |
+ +----------------------+
+
+4.2. RFC 5735 and RFC 5737 Zones
+
+ The following zones correspond to those address ranges from [RFC5735]
+ and [RFC5737] that are not expected to appear as source or
+ destination addresses on the public Internet; as such, there are no
+ globally unique names associated with the addresses in these ranges.
+
+
+
+
+
+
+
+
+
+Andrews Best Current Practice [Page 5]
+
+RFC 6303 Locally Served DNS Zones July 2011
+
+
+ The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not an
+ 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 that no
+ other coverage for these domains exists.
+
+ +------------------------------+-----------------------+
+ | Zone | Description |
+ +------------------------------+-----------------------+
+ | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
+ | 127.IN-ADDR.ARPA | IPv4 Loopback NETWORK |
+ | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
+ | 2.0.192.IN-ADDR.ARPA | IPv4 TEST-NET-1 |
+ | 100.51.198.IN-ADDR.ARPA | IPv4 TEST-NET-2 |
+ | 113.0.203.IN-ADDR.ARPA | IPv4 TEST-NET-3 |
+ | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
+ +------------------------------+-----------------------+
+
+4.3. Local IPv6 Unicast Addresses
+
+ The reverse mappings ([RFC3596], Section 2.5 ("IP6.ARPA Domain")) for
+ the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291],
+ 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 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 [RFC4193] already required special treatment of:
+
+ +--------------+
+ | Zone |
+ +--------------+
+ | D.F.IP6.ARPA |
+ +--------------+
+
+
+
+Andrews Best Current Practice [Page 6]
+
+RFC 6303 Locally Served DNS Zones July 2011
+
+
+4.5. IPv6 Link-Local Addresses
+
+ IPv6 Link-Local Addresses as described in [RFC4291], 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 |
+ +----------------+
+
+4.6. IPv6 Example Prefix
+
+ IPv6 example prefix [RFC3849].
+
+ +--------------------------+
+ | Zone |
+ +--------------------------+
+ | 8.B.D.0.1.0.0.2.IP6.ARPA |
+ +--------------------------+
+
+ Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as an example here.
+
+5. Zones That Are Out of Scope
+
+ IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and
+ 2.5.7), and IPv6 non-locally assigned local addresses ([RFC4193]) 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 the zones 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 non-locally assigned local addresses (L = 0) [RFC4193],
+ 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 nameservers are provided for these addresses.
+
+
+
+
+
+
+
+Andrews Best Current Practice [Page 7]
+
+RFC 6303 Locally Served DNS Zones July 2011
+
+
+ IP6.INT was once used to provide reverse mapping for IPv6. IP6.INT
+ was deprecated in [RFC4159] and the delegation removed from the INT
+ zone in June 2006. While it is possible that legacy software
+ continues to send queries for names under the IP6.INT domain, this
+ document does not specify that IP6.INT be considered a local zone.
+
+ This document has also deliberately ignored names immediately under
+ the root domain. While there is a subset of queries to the root
+ nameservers that 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).
+
+6. IANA Considerations
+
+ IANA has established a registry of zones that require this default
+ behaviour. The initial contents of this registry are defined in
+ Section 4. Implementors are encouraged to periodically check this
+ registry and adjust their implementations to reflect changes therein.
+
+ This registry can be amended through "IETF Review" as per [RFC5226].
+ As part of this review process, it should be noted that once a zone
+ is added it is effectively added permanently; once an address range
+ starts being configured as a local zone in systems on the Internet,
+ it will be impossible to reverse those changes.
+
+ IANA should coordinate with the RIRs to ensure that, as DNS Security
+ (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 [RFC1918]
+ 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 nameserver(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 [RFC4035] by publishing and using DNSSEC trust
+ anchors. This will protect the clients from accidental import of
+ unsigned responses from the Internet.
+
+
+
+Andrews Best Current Practice [Page 8]
+
+RFC 6303 Locally Served DNS Zones July 2011
+
+
+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
+
+ [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
+ SPECIFICATION", STD 13, RFC 1035, November 1987.
+
+ [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+ and E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, February 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
+ [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
+ Names", BCP 32, RFC 2606, June 1999.
+
+ [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IP Version 6", RFC 3596,
+ October 2003.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4159] Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
+ August 2005.
+
+ [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", RFC 4193, October 2005.
+
+
+
+
+
+
+Andrews Best Current Practice [Page 9]
+
+RFC 6303 Locally Served DNS Zones July 2011
+
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+9.2. Informative References
+
+ [AS112] "AS112 Project", <http://www.as112.net/>.
+
+ [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
+ Reserved for Documentation", RFC 3849, July 2004.
+
+ [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+ BCP 153, RFC 5735, January 2010.
+
+ [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
+ Reserved for Documentation", RFC 5737, January 2010.
+
+ [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
+ RFC 6304, July 2011.
+
+ [RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by
+ PRISONER.IANA.ORG!", RFC 6305, July 2011.
+
+Author's Address
+
+ Mark P. Andrews
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ US
+
+ EMail: marka@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews Best Current Practice [Page 10]
+