One document matched: draft-ietf-dnsop-default-local-zones-15.xml
<?xml version="1.0"?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="pre5378Trust200902" category="bcp" docName="draft-ietf-dnsop-default-local-zones-15">
<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>marka@isc.org</email>
</address>
</author>
<date day="14" month="March" year="2011"/>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section toc="yes" anchor="intro" title="Introduction">
<t>
Experience with the Domain Name System (DNS, <xref
target="RFC1034" /> and <xref target="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 <xref target="RFC1918"
/> and the IP6.ARPA zones for locally assigned unique local
IPv6 addresses defined in <xref target="RFC4193" />.
</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="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 <xref
target="RFC1918" /> 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="RFC1918" /> addresses
but do not follow the last paragraph in Section 3 of <xref
target="RFC1918" />.
</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="RFC2119" />.
</t>
</section>
</section>
<section toc="yes" anchor="effects" title="Effects
on sites using RFC 1918 addresses.">
<t>
For most sites using <xref target="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.
</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="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.
</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
all at once 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="RFC2606" />. 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="RFC2308" /> 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 <xref target="RFC2136"
/> 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.
</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.
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.
</t>
<!--
<t>
It should be assumed that any zone added to this list will
be permanently for all practial purposes.
</t>
-->
<section toc="yes" anchor="rfc1918zones" title="RFC1918
Zones">
<t>
The following zones correspond to the IPv4 address space
reserved in
<xref target="RFC1918" />.
</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="rfc5735zones" title="RFC5735 and RFC5737 Zones">
<t>
The following zones correspond to those address ranges
from <xref target="RFC5735" /> and <xref target="RFC5737" />
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 1 </c>
<c>100.51.198.IN-ADDR.ARPA</c> <c>IPv4 TEST NET 2</c>
<c>113.0.203.IN-ADDR.ARPA</c> <c>IPv4 TEST NET 3</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="RFC3596" />, Section
2.5 IP6.ARPA Domain) for the IPv6 Unspecified (::) and
Loopback (::1) addresses (<xref target="RFC4291" />,
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="RFC4193" /> 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="RFC4291" />,
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 toc="yes" anchor="example" title="IPv6 Example Prefix">
<t>
IPv6 example prefix <xref target="RFC3849" />.
</t>
<texttable>
<ttcol align="left">Zone</ttcol>
<c>8.B.D.0.1.0.0.2.IP6.ARPA</c>
</texttable>
<t> Note:
8.B.D.0.1.0.0.2.IP6.ARPA is not being used as an example here.
</t>
</section>
</section>
<section toc="yes" anchor="author" title="Zones that are Out-Of-Scope">
<t>
IPv6 site-local addresses (deprecated, see <xref target="RFC4291"
/> Sections 2.4 and 2.5.7), and IPv6 Non-Locally Assigned
Local addresses (<xref target="RFC4193" />) are not covered
here.
</t>
<t>
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.
</t>
<t>
For IPv6 Non-Locally Assigned Local addresses (L = 0) <xref
target="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 <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>
IP6.INT was once used to provide reverse mapping for IPv6.
IP6.INT was deprecated in <xref target="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.
</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 this registry are defined in <xref target="list"
/>. Implementors are encouraged to periodically check this
registry and adjust their implementations to reflect changes
therein.
</t>
<t>
This registry can be amended through "IETF Review" as per
<xref target="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.
</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="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 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="RFC4035" /> 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="RFC1034">
<front>
<title>DOMAIN NAMES - CONCEPTS AND FACILITIES</title>
<author initials="P." surname="Mockapetris" fullname="P. Mockapetris">
<organization />
</author>
<date month="November" year="1987" />
</front>
<seriesInfo name="STD" value="13" />
<seriesInfo name="RFC" value="1034" />
</reference>
<reference anchor="RFC1035">
<front>
<title>DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION</title>
<author initials="P." surname="Mockapetris" fullname="P. Mockapetris">
<organization />
</author>
<date month="November" year="1987" />
</front>
<seriesInfo name="STD" value="13" />
<seriesInfo name="RFC" value="1035" />
</reference>
<reference anchor="RFC1918">
<front>
<title>Address Allocation for Private Internets</title>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization />
</author>
<author initials="B." surname="Moskowitz" fullname="B. Moskowitz">
<organization />
</author>
<author initials="D." surname="Karrenberg" fullname="D. Karrenberg">
<organization />
</author>
<author initials="G. J." surname="de Groot" fullname="G. J. de Groot">
<organization />
</author>
<author initials="E." surname="Lear" fullname="E. Lear">
<organization />
</author>
<date month="February" year="1996" />
</front>
<seriesInfo name="BCP" value="5" />
<seriesInfo name="RFC" value="1918" />
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization />
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="RFC2136">
<front>
<title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
<author initials="P." surname="Vixie" fullname="P. Vixie">
<organization />
</author>
<author initials="A." surname="Thomson" fullname="A. Thomson">
<organization />
</author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization />
</author>
<author initials="J." surname="Bound" fullname="J. Bound">
<organization />
</author>
<date month="April" year="1997" />
</front>
<seriesInfo name="RFC" value="2136" />
</reference>
<reference anchor="RFC2308">
<front>
<title>Negative Caching of DNS Queries (DNS NCACHE)</title>
<author initials="M." surname="Andrews" fullname="M. Andrews">
<organization />
</author>
<date month="March" year="1998" />
</front>
<seriesInfo name="RFC" value="2308" />
</reference>
<reference anchor="RFC2606">
<front>
<title>Reserved Top Level DNS Names</title>
<author fullname="D. Eastlake" surname="Eastlake" initials="D.">
<organization />
</author>
<author fullname="A. Panitz" surname="Panitz" initials="A.">
<organization />
</author>
<date month="June" year="1999" />
</front>
<seriesInfo name="BCP" value="32" />
<seriesInfo name="RFC" value="2606" />
</reference>
<reference anchor="RFC3596">
<front>
<title>DNS Extensions to Support IPv6</title>
<author fullname="S. Thomson" surname="Thomson" initials="S.">
<organization />
</author>
<author fullname="C. Huitema" surname="Huitema" initials="C.">
<organization />
</author>
<author fullname="V. Ksinant" surname="Ksinant" initials="V.">
<organization />
</author>
<author fullname="M. Souissi" surname="Souissi" initials="M.">
<organization />
</author>
<date month="October" year="2003" />
</front>
<seriesInfo name="RFC" value="3596" />
</reference>
<reference anchor="RFC4035">
<front>
<title>Protocol Modifications for the DNS Security Extensions</title>
<author initials="R." surname="Arends" fullname="R. Arends">
<organization />
</author>
<author initials="R." surname="Austein" fullname="R. Austein">
<organization />
</author>
<author initials="M." surname="Larson" fullname="M. Larson">
<organization />
</author>
<author initials="D." surname="Massey" fullname="D. Massey">
<organization />
</author>
<author initials="S." surname="Rose" fullname="S. Rose">
<organization />
</author>
<date month="March" year="2005" />
</front>
<seriesInfo name="RFC" value="4035" />
</reference>
<reference anchor="RFC4159">
<front>
<title>Deprecation of "ip6.int"</title>
<author initials='G.' surname='Huston' fullname='G. Huston'>
<organization />
</author>
<date year='2005' month='August' />
</front>
<seriesInfo name='BCP' value='109' />
<seriesInfo name='RFC' value='4159' />
</reference>
<reference anchor="RFC4193">
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization />
</author>
<author initials="B." surname="Haberman" fullname="B. Haberman">
<organization />
</author>
<date month="October" year="2005" />
</front>
<seriesInfo name="RFC" value="4193" />
</reference>
<reference anchor="RFC4291">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization />
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization />
</author>
<date month="February" year="2006" />
</front>
<seriesInfo name="RFC" value="4291" />
</reference>
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization />
</author>
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
<organization />
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="BCP" value="26" />
<seriesInfo name="RFC" value="5226" />
</reference>
</references>
<references title="Informative References">
<reference anchor="AS112" target="http://www.as112.net/">
<front>
<title>AS112 Project</title>
<author><organization /></author>
</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">
<organization />
</author>
<author initials="W." surname="Maton" fullname="J. Maton">
<organization />
</author>
<date month="July" year="2010" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-as112-ops-04" />
</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">
<organization />
</author>
<author initials="W." surname="Maton" fullname="J. Maton">
<organization />
</author>
<date month="July" year="2010" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-as112-under-attack-help-help-04" />
</reference>
<reference anchor="RFC3849">
<front>
<title>IPv6 Address Prefix Reserved for Documentation</title>
<author initials="G." surname="Huston" fullname="G. Huston">
<organization />
</author>
<author initials="A." surname="Lord" fullname="A. Lord">
<organization />
</author>
<author initials="P." surname="Smith" fullname="P. Smith">
<organization />
</author>
<date month="July" year="2004" />
</front>
<seriesInfo name="RFC" value="3849" />
</reference>
<reference anchor="RFC5735">
<front>
<title>Special-Use IPv4 Addresses</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization />
</author>
<author initials="L." surname="Vergoda" fullname="L. Vergoda">
<organization />
</author>
<date month="January" year="2010" />
</front>
<seriesInfo name="RFC" value="5735" />
</reference>
<reference anchor="RFC5737">
<front>
<title>IPv4 Address Blocks Reserved for Documentation</title>
<author initials="J." surname="Arkko" fullname="J. Arkko">
<organization />
</author>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization />
</author>
<author initials="L." surname="Vergoda" fullname="L. Vergoda">
<organization />
</author>
<date month="January" year="2010" />
</front>
<seriesInfo name="RFC" value="5737" />
</reference>
</references>
<section anchor="changes" title="Change History [To Be Removed on Publication]">
<section title="draft-ietf-dnsop-default-local-zones-15.txt">
<t>refresh awaiting writeup</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-14.txt">
<t>Removed ORCHID prefix.</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-13.txt">
<t>Inclusion of ORCHID prefix.</t>
<t>reference updates.</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-12.txt">
<t>Update IP6.INT's non inclusion rational.</t>
<t>Removed Appendix B, which requested BCP status, as it was redundant.</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-11.txt">
<t>Change RFC 3330 to RFC 5735</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-10.txt">
<t>added RFC 5737 zones</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-09.txt">
<t>refresh awaiting writeup</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-08.txt">
<t>editorial, reference updates</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-07.txt">
<t>none, expiry prevention</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-06.txt">
<t>add IPv6 example prefix</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-05.txt">
<t>none, expiry prevention</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-04.txt">
<t>Centrally Assigned Local addresses -> Non-Locally Assigned Local address</t>
</section>
<section title="draft-ietf-dnsop-default-local-zones-03.txt">
<t>expanded section 4 descriptions</t>
<t>
Added references <xref target="RFC2136"/>,
<xref target="RFC3596"/>,
<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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:33:13 |