Locally-served DNS ZonesInternet Systems Consortium950 Charter StreetRedwood CityCA94063USMark_Andrews@isc.org
Experience with the Domain Name System (DNS) has shown that
there are a number of DNS zones 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.
Experience with the Domain Name System (DNS, and ) 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 and the IP6.ARPA zones for locally assigned unique local
IPv6 addresses defined in .
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
.
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 .
recommends that queries for
D.F.IP6.ARPA be handled locally. This document extends the
recommendation to cover the IN-ADDR.ARPA zones for 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 will not have to be increased,
and may in time be reduced.
This recommendation should also help DNS responsiveness for
sites which are using addresses
but do not follow the last paragraph in Section 3 of .
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 .
For most sites using 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 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.
Unless configured otherwise, an iterative resolver will now
return authoritatively (aa=1) name errors (RCODE=3) for
queries within the zones in , 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. 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." . 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.
The SOA RR is needed to support negative caching 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 processing in the client.
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.
The following zones correspond to the IPv4 address space
reserved in
.
Zone10.IN-ADDR.ARPA16.172.IN-ADDR.ARPA17.172.IN-ADDR.ARPA18.172.IN-ADDR.ARPA19.172.IN-ADDR.ARPA20.172.IN-ADDR.ARPA21.172.IN-ADDR.ARPA22.172.IN-ADDR.ARPA23.172.IN-ADDR.ARPA24.172.IN-ADDR.ARPA25.172.IN-ADDR.ARPA26.172.IN-ADDR.ARPA27.172.IN-ADDR.ARPA28.172.IN-ADDR.ARPA29.172.IN-ADDR.ARPA30.172.IN-ADDR.ARPA31.172.IN-ADDR.ARPA168.192.IN-ADDR.ARPA
The following zones correspond to those address ranges
from 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 ().
The recommendations made here simply assume no other
coverage for these domains exists.
ZoneDescription0.IN-ADDR.ARPAIPv4 "THIS" NETWORK127.IN-ADDR.ARPAIPv4 LOOP-BACK NETWORK254.169.IN-ADDR.ARPAIPv4 LINK LOCAL2.0.192.IN-ADDR.ARPAIPv4 TEST NET255.255.255.255.IN-ADDR.ARPAIPv4 BROADCAST
The reverse mappings (, Section
2.5 IP6.ARPA Domain) for the IPv6 Unspecified (::) and
Loopback (::1) addresses (,
Sections 2.4, 2.5.2 and 2.5.3) are covered by these two
zones:
Zone0.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.ARPA1.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.
Section 4.4 of already required special
treatment of:
ZoneD.F.IP6.ARPA
IPv6 Link-Local Addresses as of ,
Section 2.5.6 are covered by four distinct reverse DNS zones:
Zone8.E.F.IP6.ARPA9.E.F.IP6.ARPAA.E.F.IP6.ARPAB.E.F.IP6.ARPA
IPv6 example prefix .
Zone8.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 a example here.
IPv6 site-local addresses (deprecated, see Sections 2.4 and 2.5.7), and IPv6 Non-Locally Assigned
Local 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 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) , 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 . 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 .
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).
This document requests that IANA establish a registry of
zones which require this default behaviour. The initial
contents of this registry are defined in . 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
.
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 .
During the initial deployment phase, particularly where
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 by
publishing and using DNSSEC trust anchors. This will protect
the clients from accidental import of unsigned responses
from the Internet.
This work was supported by the US National Science Foundation
(research grant SCI-0427144) and DNS-OARC.
DOMAIN NAMES - CONCEPTS AND FACILITIESDOMAIN NAMES - IMPLEMENTATION AND SPECIFICATIONAddress Allocation for Private InternetsKey words for use in RFCs to Indicate Requirement LevelsDynamic Updates in the Domain Name System (DNS UPDATE)Negative Caching of DNS Queries (DNS NCACHE)Reserved Top Level DNS NamesDNS Extensions to Support IPv6Protocol Modifications for the DNS Security ExtensionsDeprecation of "ip6.int"Unique Local IPv6 Unicast AddressesIP Version 6 Addressing ArchitectureGuidelines for Writing an IANA Considerations Section in RFCsAS112 ProjectAS112 Nameserver OperationsI'm Being Attacked by PRISONER.IANA.ORG!Special-Use IPv4 AddressesIPv6 Address Prefix Reserved for Documentationeditorial, reference updatesnone, expiry preventionadd IPv6 example prefixnone, expiry preventionCentrally Assigned Local addresses -> Non-Locally Assigned Local addressexpanded section 4 descriptions
Added references ,
,
and
.
Revised language.RNAME now "nobody.invalid."Revised language.Revised impact description.Updated to reflect change in IP6.INT status.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.Added "Proposed Status".
Added 0.IN-ADDR.ARPA.
This Internet-Draft is being submitted for eventual publication
as an RFC with a proposed status of Best Current Practice.