One document matched: draft-ietf-dnsop-default-local-zones-03.xml
<?xml version="1.0"?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="full3978" category="bcp" docname="draft-ietf-dnsop-default-local-zones-03">
<front>
<title>Locally-served DNS Zones</title>
<author initials="M.P." surname="Andrews" fullname="Mark P. Andrews">
<organization abbrev="ISC">Internet Systems Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>
<email>Mark_Andrews@isc.org</email>
</address>
</author>
<date day="19" month="November" year="2007"/>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section toc="yes" anchor="intro" title="Introduction">
<t>
Experience has shown that there are a number of DNS <xref
target="RFC 1034" /> <xref target="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 <xref target="RFC 1918" />
and the IP6.ARPA zones for locally assigned unique local IPv6
addresses, <xref target="RFC 4193" />.
</t>
<t>
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
<xref target="AS112" />
<xref target="I-D.draft-ietf-dnsop-as112-ops" />
<xref target="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.
</t>
<t>
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 <xref target="list" />.
</t>
<t>
<xref target="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 <xref
target="RFC 1918" /> and other well known IN-ADDR.ARPA and
IP6.ARPA zones for which queries should not appear on the
public Internet.
</t>
<t>
It is hoped that by doing this the number of sacrificial
servers <xref target="AS112" /> will not have to be increased,
and may in time be reduced.
</t>
<t>
This recommendation should also help DNS responsiveness for
sites which are using <xref target="RFC 1918" /> addresses
but do not follow the last paragraph in Section 3 of <xref
target="RFC 1918" />.
</t>
<section toc="yes" anchor="reserved" title="Reserved
Words">
<t>
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 <xref target="RFC 2119" />.
</t>
</section>
</section>
<section toc="yes" anchor="effects" title="Effects
on sites using RFC 1918 addresses.">
<t>
For most sites using <xref target="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.
</t>
<t>
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.
</t>
<t>
The most significant impact will be felt at sites that make
use of delegations for <xref target="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.
</t>
</section>
<section toc="yes" anchor="full" title="Changes to
Iterative Resolver Behaviour.">
<t>
Unless configured otherwise, an iterative resolver will now
return authoritatively (aa=1) name errors (RCODE=3) for
queries within the zones in <xref target="list" />, 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.
</t>
<t>
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.
</t>
<t>
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." <xref target="RFC 2606" />. Implementations
SHOULD provide a mechanism to set these values. No address
records need to be provided for the name server.
</t>
<t>
Below is an example of a generic empty zone in master file
format. It will produce a negative cache TTL of 3 hours.
</t>
<figure>
<artwork>
@ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 @ 10800
IN NS @
</artwork>
</figure>
<t>
The SOA RR is needed to support negative caching <xref
target="RFC 2308" /> of name error responses and to point
clients to the primary master for DNS dynamic updates.
</t>
<t>
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.
</t>
<t>
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
<xref target="RFC 2136" /> processing in the client.
</t>
</section>
<section toc="yes" anchor="list" title="Lists Of
Zones Covered">
<t>
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.
</t>
<section toc="yes" anchor="rfc1918zones" title="RFC 1918
Zones">
<t>
The following zones correspond to the IPv4 address space
reserved in
<xref target="RFC 1918" />.
</t>
<texttable>
<ttcol align="left">Zone</ttcol>
<c>10.IN-ADDR.ARPA</c>
<c>16.172.IN-ADDR.ARPA</c>
<c>17.172.IN-ADDR.ARPA</c>
<c>18.172.IN-ADDR.ARPA</c>
<c>19.172.IN-ADDR.ARPA</c>
<c>20.172.IN-ADDR.ARPA</c>
<c>21.172.IN-ADDR.ARPA</c>
<c>22.172.IN-ADDR.ARPA</c>
<c>23.172.IN-ADDR.ARPA</c>
<c>24.172.IN-ADDR.ARPA</c>
<c>25.172.IN-ADDR.ARPA</c>
<c>26.172.IN-ADDR.ARPA</c>
<c>27.172.IN-ADDR.ARPA</c>
<c>28.172.IN-ADDR.ARPA</c>
<c>29.172.IN-ADDR.ARPA</c>
<c>30.172.IN-ADDR.ARPA</c>
<c>31.172.IN-ADDR.ARPA</c>
<c>168.192.IN-ADDR.ARPA</c>
</texttable>
</section>
<section toc="yes" anchor="rfc3330zones" title="RFC 3330 Zones">
<t>
The following zones correspond to those address ranges
from <xref target="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.
</t>
<t>
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 <xref target="local" />.
The recommendations made here simply assume no other
coverage for these domains exists.
</t>
<texttable>
<ttcol align="left">Zone</ttcol> <ttcol
align="left">Description</ttcol>
<c>0.IN-ADDR.ARPA</c> <c>IPv4 "THIS" NETWORK</c>
<c>127.IN-ADDR.ARPA</c> <c>IPv4 LOOP-BACK NETWORK</c>
<c>254.169.IN-ADDR.ARPA</c> <c>IPv4 LINK LOCAL</c>
<c>2.0.192.IN-ADDR.ARPA</c> <c>IPv4 TEST NET</c>
<c>255.255.255.255.IN-ADDR.ARPA</c> <c>IPv4 BROADCAST</c>
</texttable>
</section>
<section toc="yes" anchor="local" title="Local IPv6 Unicast Addresses">
<t>
The reverse mappings (<xref target="RFC 3596" />, Section
2.5 IP6.ARPA Domain) for the IPv6 Unspecified (::) and
Loopback (::1) addresses (<xref target="RFC 4291" />,
Sections 2.4, 2.5.2 and 2.5.3) are covered by these two
zones:
</t>
<texttable>
<ttcol align="left">Zone</ttcol>
<c>0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\</c><c>0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</c>
<c>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\</c><c>0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</c>
</texttable>
<t>
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.
</t>
</section>
<section toc="yes" anchor="lassigned" title="IPv6 Locally Assigned Local Addresses">
<t>
Section 4.4 of <xref target="RFC 4193" /> already required special
treatment of:
</t>
<texttable>
<ttcol align="left">Zone</ttcol>
<c>D.F.IP6.ARPA</c>
</texttable>
</section>
<section toc="yes" anchor="link" title="IPv6 Link Local Addresses">
<t>
IPv6 Link-Local Addresses as of <xref target="RFC 4291" />,
Section 2.5.6 are covered by four distinct reverse DNS zones:
</t>
<texttable>
<ttcol align="left">Zone</ttcol>
<c>8.E.F.IP6.ARPA</c>
<c>9.E.F.IP6.ARPA</c>
<c>A.E.F.IP6.ARPA</c>
<c>B.E.F.IP6.ARPA</c>
</texttable>
</section>
</section>
<section toc="yes" anchor="author" title="Zones that are Out-Of-Scope">
<t>
IPv6 site-local addresses, <xref target="RFC 4291" /> Sections 2.4
and 2.57, and IPv6 Centrally Assigned Local <xref target="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.
</t>
<t>
For IPv6 Centrally Assigned Local addresses (L = 0) <xref
target="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 <xref
target="lassigned" />. If they do, then registries will
need to take steps to ensure that name servers are provided
for these addresses.
</t>
<t>
This document also ignores IP6.INT. IP6.INT has been
wound up with only legacy resolvers now generating reverse
queries under IP6.INT <xref target="RFC 4159" />.
</t>
<t>
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).
</t>
</section>
<section toc="yes" anchor="iana" title="IANA Considerations">
<t>
This document requests that IANA establish a registry of
zones which require this default behaviour. The initial
contents of which are in <xref target="list" />. Implementors
are encouraged to check this registry and adjust their
implementations to reflect changes therein.
</t>
<t>
This registry can be amended through "IETF Consensus" as per
<xref target="RFC 2434" />.
</t>
<t>
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 <xref target="security" />.
</t>
</section>
<section toc="yes" anchor="security" title="Security Considerations">
<t>
During the initial deployment phase, particularly where
<xref target="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.
</t>
<t>
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.
</t>
<t>
It is recommended that sites actively using these namespaces
secure them using DNSSEC <xref target="RFC 4035" /> by
publishing and using DNSSEC trust anchors. This will protect
the clients from accidental import of unsigned responses
from the Internet.
</t>
</section>
<section toc="yes" anchor="ack" title="Acknowledgements">
<t>
This work was supported by the US National Science Foundation
(research grant SCI-0427144) and DNS-OARC.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC 1034">
<front>
<title>DOMAIN NAMES - CONCEPTS AND FACILITIES</title>
<author initials="P." surname="Mockapetris" fullname="P. Mockapetris" />
<date month="November" year="1987" />
</front>
<seriesInfo name="RFC" value="1034" />
<seriesInfo name="STD" value="13" />
</reference>
<reference anchor="RFC 1035">
<front>
<title>DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION</title>
<author initials="P." surname="Mockapetris" fullname="P. Mockapetris" />
<date month="November" year="1987" />
</front>
<seriesInfo name="RFC" value="1035" />
<seriesInfo name="STD" value="13" />
</reference>
<reference anchor="RFC 1918">
<front>
<title>Address Allocation for Private Internets</title>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter" />
<author initials="B." surname="Moskowitz" fullname="B. Moskowitz" />
<author initials="D." surname="Karrenberg" fullname="D. Karrenberg" />
<author initials="G. J." surname="de Groot" fullname="G. J. de Groot" />
<author initials="E." surname="Lear" fullname="E. Lear" />
<date month="February" year="1996" />
</front>
<seriesInfo name="RFC" value="1918" />
</reference>
<reference anchor="RFC 2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"/>
<date month="March" year="1997" />
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="RFC 2136">
<front>
<title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
<author initials="P." surname="Vixie" fullname="P. Vixie"/>
<author initials="A." surname="Thomson" fullname="A. Thomson"/>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter"/>
<author initials="J." surname="Bound" fullname="J. Bound"/>
<date month="April" year="1997" />
</front>
<seriesInfo name="RFC" value="2136" />
</reference>
<reference anchor="RFC 2308">
<front>
<title>Negative Caching of DNS Queries (DNS NCACHE)</title>
<author initials="M." surname="Andrews" fullname="M. Andrews" />
<date month="March" year="1998" />
</front>
<seriesInfo name="RFC" value="2398" />
</reference>
<reference anchor="RFC 2434">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials="T." surname="Narten" fullname="T. Narten" />
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand" />
<date month="October" year="1998" />
</front>
<seriesInfo name="BCP" value="26" />
<seriesInfo name="RFC" value="2434" />
</reference>
<reference anchor="RFC 2606">
<front>
<title>Reserved Top Level DNS Names</title>
<author fullname="D. Eastlake" surname="Eastlake" initials="D."/>
<author fullname="A. Panitz" surname="Panitz" initials="A."/>
<date month="June" year="1999" />
</front>
<seriesInfo name="BCP" value="32" />
<seriesInfo name="RFC" value="2606" />
</reference>
<reference anchor="RFC 3596">
<front>
<title>DNS Extensions to Support IPv6</title>
<author fullname="S. Thomson" surname="Thomson" initials="S."/>
<author fullname="C. Huitema" surname="Huitema" initials="C."/>
<author fullname="V. Ksinant" surname="Ksinant" initials="V."/>
<author fullname="M. Souissi" surname="Souissi" initials="M."/>
<date month="October" year="2003" />
</front>
<seriesInfo name="RFC" value="3596" />
</reference>
<reference anchor="RFC 4035">
<front>
<title>Protocol Modifications for the DNS Security Extensions</title>
<author initials="R." surname="Arends" fullname="R. Arends"/>
<author initials="R." surname="Austein" fullname="R. Austein"/>
<author initials="M." surname="Larson" fullname="M. Larson"/>
<author initials="D." surname="Massey" fullname="D. Massey"/>
<author initials="S." surname="Rose" fullname="S. Rose"/>
<date month="March" year="2005" />
</front>
<seriesInfo name="RFC" value="4035" />
</reference>
<reference anchor="RFC 4159">
<front>
<title>Deprecation of "ip6.int"</title>
<author initials='G.' surname='Huston' fullname='G. Huston' />
<date year='2005' month='August' />
</front>
<seriesInfo name='BCP' value='109' />
<seriesInfo name='RFC' value='4159' />
</reference>
<reference anchor="RFC 4193">
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<author initials="R." surname="Hinden" fullname="R. Hinden" />
<author initials="B." surname="Haberman" fullname="B. Haberman" />
<date month="October" year="2005" />
</front>
<seriesInfo name="RFC" value="4193" />
</reference>
<reference anchor="RFC 4291">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials="R." surname="Hinden" fullname="R. Hinden" />
<author initials="S." surname="Deering" fullname="S. Deering" />
<date month="February" year="2006" />
</front>
<seriesInfo name="RFC" value="4291" />
</reference>
</references>
<references title="Informative References">
<reference anchor="AS112" target="http://www.as112.net/">
<front>
<title>AS112 Project</title>
</front>
</reference>
<reference anchor="I-D.draft-ietf-dnsop-as112-ops">
<front>
<title>AS112 Nameserver Operations</title>
<author initials="J." surname="Abley" fullname="J. Abley" />
<author initials="W." surname="Maton" fullname="J. Maton" />
<date month="February" year="2007" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-as112-ops-00" />
</reference>
<reference anchor="I-D.draft-ietf-dnsop-as112-under-attack-help-help">
<front>
<title>I'm Being Attacked by PRISONER.IANA.ORG!</title>
<author initials="J." surname="Abley" fullname="J. Abley" />
<author initials="W." surname="Maton" fullname="J. Maton" />
<date month="February" year="2007" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-as112-under-attack-help-help-00" />
</reference>
<reference anchor="RFC 3330">
<front>
<title>Special-Use IPv4 Addresses</title>
<author fullname="IANA" />
<date month="September" year="2002" />
</front>
<seriesInfo name="RFC" value="3330" />
</reference>
</references>
<section anchor="changes" title="Change History [To Be Removed on Publication]">
<section title="draft-ietf-dnsop-default-local-zones-03.txt">
<t>expanded section 4 descriptions</t>
<t>
Added references <xref target="RFC 2136"/>,
<xref target="RFC 3596"/>,
<xref target="I-D.draft-ietf-dnsop-as112-ops" /> and
<xref target="I-D.draft-ietf-dnsop-as112-under-attack-help-help" />.
</t>
<t>Revised language.</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-02.txt">
<t>RNAME now "nobody.invalid."</t>
<t>Revised language.</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-01.txt">
<t>Revised impact description.</t>
<t>Updated to reflect change in IP6.INT status.</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-00.txt">
<t>Adopted by DNSOP.</t>
<t>"Author's Note" re-titled "Zones that are Out-Of-Scope"</t>
<t>Add note that these zone are expected to seed the IANA
registry.</t>
<t>Title changed.</t>
</section>
<section title="draft-andrews-full-service-resolvers-03.txt">
<t>Added "Proposed Status".</t>
</section>
<section title="draft-andrews-full-service-resolvers-02.txt">
<t>
Added 0.IN-ADDR.ARPA.
</t>
</section>
</section>
<section anchor="status" title="Proposed Status [To Be Removed on Publication]">
<t>
This Internet-Draft is being submitted for eventual publication
as an RFC with a proposed status of Best Current Practice.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:13:05 |