564 lines
22 KiB
Plaintext
564 lines
22 KiB
Plaintext
|
|
|
|
|
|
|
|
|
|
|
|
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]
|
|
|