rfc8806xml2.original.xml   rfc8806.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY rfc1035 PUBLIC "" "reference.RFC.1035.xml">
<!ENTITY rfc2119 PUBLIC "" "../reference.RFC.2119.xml">
<!ENTITY rfc4033 PUBLIC "" "reference.RFC.4033.xml">
<!ENTITY rfc8174 PUBLIC "" "reference.RFC.8174.xml">
<!ENTITY rfc8198 PUBLIC "" "reference.RFC.8198.xml">
<!ENTITY rfc8499 PUBLIC "" "reference.RFC.8499.xml">
]>
<!-- WK: Set category, IPR, docName -->
<rfc category="info" docName="draft-ietf-dnsop-7706bis" ipr="trust200902"
obsoletes="7706">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
category="info" consensus="true" docName="draft-ietf-dnsop-7706bis-12"
number="8806" ipr="trust200902" obsoletes="7706" updates="" xml:lang="en"
tocInclude="true" symRefs="true" sortRefs="true" version="3">
<?rfc compact="yes" ?> <!-- xml2rfc v2v3 conversion 2.41.0 -->
<front> <front>
<title abbrev="Root Server Local">Running a Root Server Local to a <title abbrev="Root Server Local">Running a Root Server Local to a
Resolver</title> Resolver</title>
<seriesInfo name="RFC" value="8806"/>
<author fullname="Warren Kumari" initials="W." surname="Kumari"> <author fullname="Warren Kumari" initials="W." surname="Kumari">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>Warren@kumari.net</email> <email>Warren@kumari.net</email>
</address> </address>
</author> </author>
<author fullname="Paul Hoffman" initials="P." surname="Hoffman"> <author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>ICANN</organization> <organization>ICANN</organization>
<address> <address>
<email>paul.hoffman@icann.org</email> <email>paul.hoffman@icann.org</email>
</address> </address>
</author> </author>
<date year="2020" month="June" />
<date year="2020"/> <keyword>DNS</keyword>
<keyword>local-root</keyword>
<abstract> <abstract>
<t>Some DNS recursive resolvers have longer-than-desired round-trip <t>Some DNS recursive resolvers have longer-than-desired round-trip
times to the closest DNS root server; those resolvers times to the closest DNS root server; those resolvers may have
may have difficulty getting responses from the root servers, such as difficulty getting responses from the root servers, such as during a
during a network attack. network attack. Some DNS recursive resolver operators want to prevent
Some DNS recursive resolver snooping by third parties of requests sent to DNS root servers. In both
operators want to prevent snooping by third parties of requests sent to DN cases, resolvers can greatly decrease the round-trip time and prevent
S root servers. observation of requests by serving a copy of the full root zone on the
In both cases, resolvers can greatly decrease the round-trip same server, such as on a loopback address or in the resolver
time and prevent observation of requests by serving a copy of the full software. This document shows how to start and maintain such a copy of
root zone on the same server, such as on a loopback address or in the reso the root zone that does not cause problems for other users of the DNS,
lver software. This at the cost of adding some operational fragility for the operator.</t>
document shows how to start and maintain such a copy of the root zone
that does not cause problems for other users of the DNS, at the cost of
adding some operational fragility for the operator.</t>
<t>This document obsoletes RFC 7706.</t> <t>This document obsoletes RFC 7706.</t>
<t>[ This document is being collaborated on in Github at:
https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent
version of the document, open issues, and so on should all be available
there. The authors gratefully accept pull requests. ]</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>DNS recursive resolvers have to provide answers to all queries from <t>DNS recursive resolvers have to provide answers to all queries from
their clients, even those for domain names that do not exist. For each their clients, even those for domain names that do not exist. For each
queried name that is within a top-level domain (TLD) that is not in the queried name that is within a top-level domain (TLD) that is not in the
recursive resolver's cache, the resolver must send a query to a root recursive resolver's cache, the resolver must send a query to a root
server to get the information for that TLD, or to find out that the TLD server to get the information for that TLD or to find out that the TLD
does not exist. Research shows that the vast majority of queries going does not exist. Research shows that the vast majority of queries going
to the root are for names that do not exist in the root zone.</t> to the root are for names that do not exist in the root zone.</t>
<t>Many of the queries from recursive resolvers to root servers get <t>Many of the queries from recursive resolvers to root servers get
answers that are referrals to other servers. Malicious third parties answers that are referrals to other servers. Malicious third parties
might be able to observe that traffic on the network between the might be able to observe that traffic on the network between the
recursive resolver and root servers.</t> recursive resolver and root servers.</t>
<t>The primary goals of this design are to provide more reliable answers <t>The primary goals of this design are to provide more reliable answers
for queries to the root zone during network attacks that affect the root s for queries to the root zone during network attacks that affect the root
ervers, and to prevent servers and to prevent
queries and responses from being visible on the network. This design queries and responses from being visible on the network. This design
will probably have little effect on getting faster responses to stub will probably have little effect on getting faster responses to the stub
resolver for good queries on TLDs, because the TTL for most TLDs is resolver for good queries on TLDs, because the TTL for most TLDs is
usually long-lived (on the order of a day or two) and is thus usually usually long-lived (on the order of a day or two) and is thus usually
already in the cache of the recursive resolver; the same is true for the already in the cache of the recursive resolver; the same is true for the
TTL for negative answers from the root servers. (Although the primary TTL for negative answers from the root servers. (Although the primary
goal of the design is for serving the root zone, the method can be goal of the design is for serving the root zone, the method can be
used for any zone.)</t> used for any zone.)</t>
<t>This document describes a method for the operator of a recursive <t>This document describes a method for the operator of a recursive
resolver to have a complete root zone locally, and to hide queries for the root zone resolver to have a complete root zone locally and to hide queries for the root zone
from outsiders. The basic idea is to create an up-to-date root zone from outsiders. The basic idea is to create an up-to-date root zone
service on the same host as the recursive server, and use that service service on the same host as the recursive server and use that service
when the recursive resolver looks up root information. The recursive when the recursive resolver looks up root information. The recursive
resolver validates all responses from the root service on the same host, resolver validates all responses from the root service on the same host,
just as it would validate all responses from a remote root server.</t> just as it would validate all responses from a remote root server.</t>
<t>This design explicitly only allows the new root zone service to be run <t>This design explicitly only allows the new root zone service to be run
on the same server as the recursive resolver, in order to prevent the on the same server as the recursive resolver in order to prevent the
server from serving authoritative answers to any other system. server from serving authoritative answers to any other system.
Specifically, the root service on the local system MUST be configured to Specifically, the root service on the local system <bcp14>MUST</bcp14> be
only answer queries from resolvers on the same host, and MUST NOT configured to
only answer queries from resolvers on the same host and <bcp14>MUST NOT</b
cp14>
answer queries from any other resolver.</t> answer queries from any other resolver.</t>
<t>At the time that RFC 7706 <xref target="RFC7706"/> was published, it wa <t>At the time that <xref target="RFC7706" format="default">RFC 7706</xref
s considered > was
controversial: there was not consensus on whether this was a "best published, it was considered
controversial, because there was not consensus on whether this was a "best
practice". In fact, many people felt that it is an excessively risky practice". In fact, many people felt that it is an excessively risky
practice because it introduced a new operational piece to local DNS practice, because it introduced a new operational piece to local DNS
operations where there was not one before. Since then, the DNS operations where there was not one before. Since then, the DNS
operational community has largely shifted to believing that local operational community has largely shifted to believing that local
serving of the root zone for an individual resolver is a reasonable serving of the root zone for an individual resolver is a reasonable
practice. The advantages listed above do not come free: if this new practice. The advantages listed above do not come free: if this new
system does not work correctly, users can get bad data, or the entire system does not work correctly, users can get bad data, or the entire
recursive resolution system might fail in ways that are hard to recursive resolution system might fail in ways that are hard to
diagnose.</t> diagnose.</t>
<t>This design uses an authoritative service running on the
<t>This design uses authoritative service running on the
same machine as the recursive resolver. same machine as the recursive resolver.
Common open source recursive Common open source recursive
resolver software does not need to add new functionality to resolver software does not need to add new functionality to
act as an authoritative server for some zones, but other act as an authoritative server for some zones, but other
recursive resolver software might need to be able to talk to an recursive resolver software might need to be able to talk to an
authoritative server running on the same host. authoritative server running on the same host.
Some resolver software supports being both an authoritative server Some resolver software supports being both an authoritative server
and a resolver but separated by logical "views", allowing a local and a resolver but separated by logical "views", allowing a local
root to be implemented within a single process; examples of this root to be implemented within a single process; examples of this
can be seen in <xref target="examples"/>.</t> can be seen in <xref target="examples" format="default"/>.</t>
<t>A different approach to solving some of the problems discussed in <t>A different approach to solving some of the problems discussed in
this document is described in <xref target="RFC8198"/>.</t> this document is described in <xref target="RFC8198" format="default"/>.</
t>
<t>Readers are expected to be familiar with <xref target="RFC8499"/>.</t> <t>Readers are expected to be familiar with <xref target="RFC8499"
format="default"/>.</t>
<section title="Changes from RFC 7706"> <section numbered="true" toc="default">
<t>RFC 7706 explicitly required that a root server instance be run <name>Changes from RFC 7706</name>
<t>RFC 7706 explicitly required that
a root server instance be run
on the loopback interface of the host running the validating resolver. on the loopback interface of the host running the validating resolver.
However, RFC 7706 also had examples of how to set up common software However, RFC 7706 also had examples
of how to set up common software
that did not use the loopback interface. This document loosens that did not use the loopback interface. This document loosens
the restriction on using the loopback interface and in fact the restriction on using the loopback interface and in fact
allows the use of a local service, not necessarily an allows the use of a local service, not necessarily an
authoritative server. However, the document keeps the requirement that o nly authoritative server. However, the document keeps the requirement that o nly
systems running on that single host be able to query that authoritative root systems running on that single host be able to query that authoritative root
server or service.</t> server or service.</t>
<t>This document changes the use cases for running a local root <t>This document changes the use cases for running a local root
service to be more consistent with the reasons operators said they had f or service to be more consistent with the reasons operators said they had f or
using RFC 7706.</t> using RFC 7706:</t>
<ul spacing="normal">
<t>Removed the prohibition on distribution of recursive DNS servers <li>Removed the prohibition on distribution of recursive DNS servers,
including configurations for this design because some already do, and including configurations for this design because some already do and
others have expressed an interest in doing so.</t> others have expressed an interest in doing so.</li>
<li>Added the idea that a recursive resolver using this design might
<t>Added the idea that a recursive resolver using this design might
switch to using the normal (remote) root servers if the local root switch to using the normal (remote) root servers if the local root
server fails.</t> server fails.</li>
<li>Refreshed the list of where one can get copies of the root zone.</li
<t>Refreshed the list of where one can get copies of the root zone.</t> >
<li>Added examples of other resolvers and updated the existing
<t>Added examples of other resolvers and updated the existing examples.< examples.</li>
/t> </ul>
</section> </section>
<section anchor="reqnot" numbered="true" toc="default">
<section title="Requirements Notation"> <name>Requirements Notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="reqs" numbered="true" toc="default">
<section anchor="reqs" title="Requirements"> <name>Requirements</name>
<t>In order to implement the mechanism described in this document:</t> <t>In order to implement the mechanism described in this document:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The system <bcp14>MUST</bcp14> be able to validate every signed
<t>The system MUST be able to validate every signed record in a zone w record in a zone with DNSSEC <xref target="RFC4033"
ith DNSSEC <xref format="default"/>.</li>
target="RFC4033"/>.</t> <li>The system <bcp14>MUST</bcp14> have an up-to-date copy of the
public part of the Key Signing Key (KSK) <xref target="RFC4033"
<t>The system MUST have an up-to-date copy of the public part of the K format="default"/> used to sign the DNS root.</li>
ey Signing Key (KSK) <xref <li>The system <bcp14>MUST</bcp14> be able to retrieve a copy of the ent
target="RFC4033"/> used to sign the DNS root.</t> ire root
zone (including all DNSSEC-related records).</li>
<t>The system MUST be able to retrieve a copy of the entire root <li>The system <bcp14>MUST</bcp14> be able to run an authoritative servi
zone (including all DNSSEC-related records).</t> ce for the
root zone on the same host. The authoritative root service <bcp14>MUST
<t>The system MUST be able to run an authoritative service for the </bcp14> only
root zone on the same host. The authoritative root service MUST only respond to queries from the same host. One way to ensure that the
respond to queries from the same host. One way to assure not authoritative root service does not respond to queries from other
responding to queries from other hosts is to run an authoritative hosts is to run an authoritative server for the root that responds
server for the root that responds only on only on one of the loopback addresses (that is, an address in the
one of the loopback addresses (that is, an range 127/8 for IPv4 or ::1 in IPv6). Another method is to have the
address in the range 127/8 for IPv4 or ::1 in IPv6). resolver software also act as an authoritative server for the root
Another method is to have the resolver software also act as an zone, but only for answering queries from itself.</li>
authoritative server for the root zone, but only for answering </ul>
queries from itself.</t>
</list></t>
<t>A corollary of the above list is that authoritative data in the root <t>A corollary of the above list is that authoritative data in the root
zone used on the local authoritative server MUST be identical to the zone used on the local authoritative server <bcp14>MUST</bcp14> be identic al to the
same data in the root zone for the DNS. It is possible to change the same data in the root zone for the DNS. It is possible to change the
unsigned data (the glue records) in the copy of the root zone, but such unsigned data (the glue records) in the copy of the root zone, but such
changes could cause problems for the recursive server that accesses the changes could cause problems for the recursive server that accesses the
local root zone, and therefore any changes to the glue records SHOULD local root zone, and therefore any changes to the glue records <bcp14>SHOU
NOT be made.</t> LD
NOT</bcp14> be made.</t>
</section> </section>
<section anchor="zoneop" numbered="true" toc="default">
<section anchor="zoneop" <name>Operation of the Root Zone on the Local Server</name>
title="Operation of the Root Zone on the Local Server">
<t>The operation of an authoritative server for the root in the system <t>The operation of an authoritative server for the root in the system
described here can be done separately from the operation of the described here can be done separately from the operation of the
recursive resolver, or it might be part of the configuration of the recursive resolver, or it might be part of the configuration of the
recursive resolver system.</t> recursive resolver system.</t>
<t>The steps to set up the root zone are:</t> <t>The steps to set up the root zone are:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>Retrieve a copy of the root zone. (See <xref target="sources" format
<t>Retrieve a copy of the root zone. (See <xref target="sources"/> ="default"/>
for some current locations of sources.)</t> for some current locations of sources.)</li>
<li>Start the authoritative service for the root zone in a manner that
<t>Start the authoritative service for the root zone in a manner that
prevents any system other than a recursive resolver on the same host prevents any system other than a recursive resolver on the same host
from accessing it.</t> from accessing it.</li>
</list></t> </ol>
<t>The contents of the root zone <bcp14>MUST</bcp14> be refreshed using th
<t>The contents of the root zone MUST be refreshed using the timers from e timers from
the SOA record in the root zone, as described in <xref the SOA record in the root zone, as described in
target="RFC1035"/>. This inherently means that the contents of the local <xref target="RFC1035" format="default"/>. This inherently means that
the contents of the local
root zone will likely be a little behind those of the global root root zone will likely be a little behind those of the global root
servers because those servers are updated when triggered by NOTIFY servers, because those servers are updated when triggered by NOTIFY
messages.</t> messages.</t>
<t>There is a risk that a system using a local authoritative server for th e <t>There is a risk that a system using a local authoritative server for th e
root zone cannot refresh the contents of the root zone before the expire t ime root zone cannot refresh the contents of the root zone before the expire t ime
in the SOA. A system using a local authoritative server for the root zone in the SOA. A system using a local authoritative server for the root zone
MUST NOT serve stale data for the root zone. To mitigate the risk that sta <bcp14>MUST NOT</bcp14> serve stale data for the root zone. To mitigate
le the risk that stale
data is served, the local root server MUST immediately switch to using data is served, the local root server <bcp14>MUST</bcp14> immediately swit
ch to using
non-local root servers when it detects that it would be serving state data .</t> non-local root servers when it detects that it would be serving state data .</t>
<t>In a resolver that is using an internal service for the root zone, <t>In a resolver that is using an internal service for the root zone,
if the contents of the root zone cannot be refreshed before the if the contents of the root zone cannot be refreshed before the
expire time in the SOA, the resolver MUST immediately switch to expire time in the SOA, the resolver <bcp14>MUST</bcp14> immediately switc h to
using non-local root servers.</t> using non-local root servers.</t>
<t>In the event that refreshing the contents of the root zone fails, the <t>In the event that refreshing the contents of the root zone fails, the
results can be disastrous. For example, sometimes all the NS records for results can be disastrous. For example, sometimes all the NS records for
a TLD are changed in a short period of time (such as 2 days); if the a TLD are changed in a short period of time (such as 2 days); if the
refreshing of the local root zone is broken during that time, the refreshing of the local root zone is broken during that time, the
recursive resolver will have bad data for the entire TLD zone.</t> recursive resolver will have bad data for the entire TLD zone.</t>
<t>An administrator using the procedure in this document <bcp14>SHOULD</bc
<t>An administrator using the procedure in this document SHOULD have an p14> have an
automated method to check that the contents of the local root zone are automated method to check that the contents of the local root zone are
being refreshed; this might be part of the resolver software. One way to being refreshed; this might be part of the resolver software. One way to
do this is to have a separate process that periodically checks the SOA do this is to have a separate process that periodically checks the SOA
of the local root zone and makes sure that it is of the local root zone and makes sure that it is
changing. At the time that this document is published, the SOA for the changing. At the time that this document is published, the SOA for the
root zone is the digital representation of the current date with a root zone is the digital representation of the current date with a
two-digit counter appended, and the SOA is changed every day even if the two-digit counter appended, and the SOA is changed every day even if the
contents of the root zone are unchanged. For example, the SOA of the contents of the root zone are unchanged. For example, the SOA of the
root zone on January 2, 2019 was 2019010201. A process can use this fact root zone on January 2, 2019 was 2019010201. A process can use this fact
to create a check for the contents of the local root zone (using a to create a check for the contents of the local root zone (using a
program not specified in this document).</t> program not specified in this document).</t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>A system that does not follow the DNSSEC-related requirements given <t>A system that does not follow the DNSSEC-related requirements given
in <xref target="reqs"/> can be fooled into giving bad responses in the in <xref target="reqs" format="default"/> can be fooled into giving bad re sponses in the
same way as any recursive resolver that does not do DNSSEC validation on same way as any recursive resolver that does not do DNSSEC validation on
responses from a remote root server. Anyone deploying the method responses from a remote root server. Anyone deploying the method
described in this document should be familiar with the operational described in this document should be familiar with the operational
benefits and costs of deploying DNSSEC <xref target="RFC4033"/>.</t> benefits and costs of deploying DNSSEC <xref target="RFC4033" format="defa
ult"/>.</t>
<t>As stated in <xref target="intro"/>, this design explicitly <t>As stated in <xref target="intro" format="default"/>, this design expli
citly
requires the local copy of the root zone information to be requires the local copy of the root zone information to be
available only from resolvers on that host. available only from resolvers on that host.
This has the security property of limiting damage to clients of This has the security property of limiting damage to clients of
any local resolver that might try to rely on an altered copy of the any local resolver that might try to rely on an altered copy of the
root.</t> root.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document has no actions for IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include='reference.RFC.1035'?> <name>References</name>
<references>
<?rfc include='reference.RFC.2119'?> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include='reference.RFC.4033'?> ence.RFC.1035.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include='reference.RFC.8174'?> ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include='reference.RFC.7706'?> ence.RFC.4033.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include='reference.RFC.8499'?> ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</references> ence.RFC.7706.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<references title="Informative References"> ence.RFC.8499.xml"/>
<?rfc include='reference.RFC.5936'?> </references>
<references>
<?rfc include='reference.RFC.8198'?> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<reference anchor="Manning2013" ence.RFC.5936.xml"/>
target="http://www.sfc.wide.ad.jp/dissertation/bill_e.html"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<front> ence.RFC.8198.xml"/>
<title>Client Based Naming</title>
<author fullname="William Manning" initials="W." surname="Manning"/>
<date year="2013"/> <reference anchor="Manning2013" target="http://www.sfc.wide.ad.jp/disser
</front> tation/bill_e.html">
</reference> <front>
<title>Client Based Naming</title>
<author fullname="William Manning" initials="W." surname="Manning"/>
<date month="May" year="2013"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="sources" numbered="true" toc="default">
<section anchor="sources" title="Current Sources of the Root Zone"> <name>Current Sources of the Root Zone</name>
<t>The root zone can be retrieved from anywhere as long as it comes with <t>The root zone can be retrieved from anywhere as long as it comes with
all the DNSSEC records needed for validation. Currently, one can get the all the DNSSEC records needed for validation. Currently, one can get the
root zone from ICANN by zone transfer (AXFR) <xref target="RFC5936"/> over root zone from ICANN by zone transfer AXFR
TCP from DNS servers <xref target="RFC5936" format="default"/> over TCP from DNS servers at
at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
The root zone file can be obtained using methods described at The root zone file can be obtained using methods described at
&lt;https://www.iana.org/domains/root/files&gt;.</t> &lt;<eref target="https://www.iana.org/domains/root/files"/>&gt;.</t>
<t>Currently, the root can also be retrieved by AXFR over TCP from the <t>Currently, the root can also be retrieved by AXFR over TCP from the
following root server operators:</t> following root server operators:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>b.root-servers.net</li>
<t>b.root-servers.net</t> <li>c.root-servers.net</li>
<li>d.root-servers.net</li>
<t>c.root-servers.net</t> <li>f.root-servers.net</li>
<li>g.root-servers.net</li>
<t>d.root-servers.net</t> <li>k.root-servers.net</li>
</ul>
<t>f.root-servers.net</t>
<t>g.root-servers.net</t>
<t>k.root-servers.net</t>
</list></t>
<t>It is crucial to note that none of the above services are guaranteed <t>It is crucial to note that none of the above services are guaranteed
to be available. It is possible that ICANN or some of the root server to be available. It is possible that ICANN or some of the root server
operators will turn off the AXFR capability on the servers listed above. operators will turn off the AXFR capability on the servers listed above.
Using AXFR over TCP to addresses that are likely to be anycast (as the Using AXFR over TCP to addresses that are likely to be anycast (as the
ones above are) may conceivably have transfer problems due to anycast, ones above are) may conceivably have transfer problems due to anycast,
but current practice shows that to be unlikely.</t> but current practice shows that to be unlikely.</t>
<section numbered="true" toc="default">
<section title="Root Zone Services"> <name>Root Zone Services</name>
<t>At the time that this document is published, there is one root zone s
<t>At the time that this document is published, there is one root zone ser ervice
vice that is active and one that has been announced as in the planning stages.
that is active, and one that has been announced as in the planning stages.
This section describes all known active services.</t> This section describes all known active services.</t>
<t>LocalRoot (&lt;<eref target="https://localroot.isi.edu/"/>&gt;) is an
<t>LocalRoot (&lt;https://localroot.isi.edu/&gt;) is an experimental experimental
service that embodies many of the ideas in this document. It service that embodies many of the ideas in this document. It
distributes the root zone by AXFR, and also offers DNS NOTIFY messages distributes the root zone by AXFR and also offers DNS NOTIFY messages
when the LocalRoot system sees that the root zone has changed.</t> when the LocalRoot system sees that the root zone has changed.</t>
</section> </section>
</section> </section>
<section anchor="examples" numbered="true" toc="default">
<section anchor="examples" <name>Example Configurations of Common Implementations</name>
title="Example Configurations of Common Implementations">
<t>This section shows fragments of configurations for some popular <t>This section shows fragments of configurations for some popular
recursive server software that is believed to correctly implement the recursive server software that is believed to correctly implement the
requirements given in this document. The examples have been updated requirements given in this document. The examples have been updated
since the publication of RFC 7706.</t> since the publication of <xref target="RFC7706" format="default"/>.</t>
<t>The IPv4 and IPv6 addresses in this section were checked in March 2020 by <t>The IPv4 and IPv6 addresses in this section were checked in March 2020 by
testing for AXFR over TCP from each address for the known single-letter testing for AXFR over TCP from each address for the known single-letter
names in the root-servers.net zone.</t> names in the root-servers.net zone.</t>
<section numbered="true" toc="default">
<section title="Example Configuration: BIND 9.12"> <name>Example Configuration: BIND 9.12</name>
<t>BIND 9.12 acts both as a recursive resolver and an authoritative serv er. <t>BIND 9.12 acts both as a recursive resolver and an authoritative serv er.
Because of this, there is "fate-sharing" between the two servers in Because of this, there is "fate-sharing" between the two servers in
the following configuration. That is, if the root server dies, it is the following configuration. That is, if the root server dies, it is
likely that all of BIND is dead.</t> likely that all of BIND is dead.</t>
<t>Note that a future version of BIND will support a much more robust <t>Note that a future version of BIND will support a much more robust
method for creating a local mirror of the root or other zones; see method for creating a local mirror of the root or other zones; see
<xref target="bind-9-14"/>.</t> <xref target="bind-9-14" format="default"/>.</t>
<t>Using this configuration, queries for information in the root zone <t>Using this configuration, queries for information in the root zone
are returned with the AA bit not set.</t> are returned with the Authoritative Answer (AA) bit not set.</t>
<t>When slaving a zone, BIND 9.12 will treat zone data differently if th e <t>When slaving a zone, BIND 9.12 will treat zone data differently if th e
zone is slaved into a separate view (or a separate instance of the zone is slaved into a separate view (or a separate instance of the
software) versus slaved into the same view or instance that is also software) versus slaved into the same view or instance that is also
performing the recursion.</t> performing the recursion.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Validation:</dt>
<t hangText="Validation:">When using separate views or separate <dd>When using separate views or separate
instances, the DS records in the slaved zone will be validated as instances, the DS records in the slaved zone will be validated as
the zone data is accessed by the recursive server. When using the the zone data is accessed by the recursive server. When using the
same view, this validation does not occur for the slaved zone.</t> same view, this validation does not occur for the slaved zone.</dd>
<dt>Caching:</dt>
<t hangText="Caching:">When using separate views or instances, the <dd>When using separate views or instances, the
recursive server will cache all of the queries for the slaved recursive server will cache all of the queries for the slaved
zone, just as it would using the traditional "root hints" method. zone, just as it would using the traditional "root hints" method.
Thus, as the zone in the other view or instance is refreshed or Thus, as the zone in the other view or instance is refreshed or
updated, changed information will not appear in the recursive updated, changed information will not appear in the recursive
server until the TTL of the old record times out. Currently, the server until the TTL of the old record times out. Currently, the
TTL for DS and delegation NS records is two days. When using the TTL for DS and delegation NS records is two days. When using the
same view, all zone data in the recursive server will be updated same view, all zone data in the recursive server will be updated
as soon as it receives its copy of the zone.</t> as soon as it receives its copy of the zone.</dd>
</list></t> </dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork><![CDATA[
view root { view root {
match-destinations { 127.12.12.12; }; match-destinations { 127.12.12.12; };
zone "." { zone "." {
type slave; type slave;
file "rootzone.db"; file "rootzone.db";
notify no; notify no;
masters { masters {
199.9.14.201; # b.root-servers.net 199.9.14.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net 192.33.4.12; # c.root-servers.net
199.7.91.13; # d.root-servers.net 199.7.91.13; # d.root-servers.net
skipping to change at line 457 skipping to change at line 396
view recursive { view recursive {
dnssec-validation auto; dnssec-validation auto;
allow-recursion { any; }; allow-recursion { any; };
recursion yes; recursion yes;
zone "." { zone "." {
type static-stub; type static-stub;
server-addresses { 127.12.12.12; }; server-addresses { 127.12.12.12; };
}; };
}; };
]]></artwork> ]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Example Configuration: Unbound 1.8"> <name>Example Configuration: Unbound 1.8</name>
<t>Similar to BIND, Unbound starting with version 1.8 can act both as <t>Similar to BIND, Unbound, starting with version 1.8, can act both as
a recursive resolver and an authoritative server.</t> a recursive resolver and an authoritative server.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork><![CDATA[
auth-zone: auth-zone:
name: "." name: "."
master: 199.9.14.201 # b.root-servers.net master: 199.9.14.201 # b.root-servers.net
master: 192.33.4.12 # c.root-servers.net master: 192.33.4.12 # c.root-servers.net
master: 199.7.91.13 # d.root-servers.net master: 199.7.91.13 # d.root-servers.net
master: 192.5.5.241 # f.root-servers.net master: 192.5.5.241 # f.root-servers.net
master: 192.112.36.4 # g.root-servers.net master: 192.112.36.4 # g.root-servers.net
master: 193.0.14.129 # k.root-servers.net master: 193.0.14.129 # k.root-servers.net
master: 192.0.47.132 # xfr.cjr.dns.icann.org master: 192.0.47.132 # xfr.cjr.dns.icann.org
master: 192.0.32.132 # xfr.lax.dns.icann.org master: 192.0.32.132 # xfr.lax.dns.icann.org
skipping to change at line 488 skipping to change at line 424
master: 2001:500:2d::d # d.root-servers.net master: 2001:500:2d::d # d.root-servers.net
master: 2001:500:2f::f # f.root-servers.net master: 2001:500:2f::f # f.root-servers.net
master: 2001:500:12::d0d # g.root-servers.net master: 2001:500:12::d0d # g.root-servers.net
master: 2001:7fd::1 # k.root-servers.net master: 2001:7fd::1 # k.root-servers.net
master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org
master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org
fallback-enabled: yes fallback-enabled: yes
for-downstream: no for-downstream: no
for-upstream: yes for-upstream: yes
]]></artwork> ]]></artwork>
</figure>
</section> </section>
<section anchor="bind-9-14" numbered="true" toc="default">
<section title="Example Configuration: BIND 9.14" anchor="bind-9-14"> <name>Example Configuration: BIND 9.14</name>
<t>BIND 9.14 can set up a local mirror of the root zone with a <t>BIND 9.14 can set up a local mirror of the root zone with a
small configuration option:</t> small configuration option:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork><![CDATA[
zone "." { zone "." {
type mirror; type mirror;
}; };
]]></artwork> ]]></artwork>
</figure>
<t>The simple "type mirror" configuration for the root zone works <t>The simple "type mirror" configuration for the root zone works
for the root zone because a default list of primary servers for the for the root zone because a default list of primary servers for the
IANA root zone is built into BIND 9.14. In order to set up mirroring IANA root zone is built into BIND 9.14. In order to set up mirroring
of any other zone, an explicit list of primary servers needs to be of any other zone, an explicit list of primary servers needs to be
provided.</t> provided.</t>
<t>See the documentation for BIND 9.14 for more detail <t>See the documentation for BIND 9.14 for more detail
about how to use this simplified configuration.</t> about how to use this simplified configuration.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Example Configuration: Unbound 1.9"> <name>Example Configuration: Unbound 1.9</name>
<t>Recent versions of Unbound have a "auth-zone" feature that allows loc <t>Recent versions of Unbound have an "auth-zone" feature that allows lo
al cal
mirroring of the root zone. Configuration looks like:</t> mirroring of the root zone. Configuration looks as follows:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
auth-zone: auth-zone:
name: "." name: "."
master: "b.root-servers.net" master: "b.root-servers.net"
master: "c.root-servers.net" master: "c.root-servers.net"
master: "d.root-servers.net" master: "d.root-servers.net"
master: "f.root-servers.net" master: "f.root-servers.net"
master: "g.root-servers.net" master: "g.root-servers.net"
master: "k.root-servers.net" master: "k.root-servers.net"
fallback-enabled: yes fallback-enabled: yes
for-downstream: no for-downstream: no
for-upstream: yes for-upstream: yes
zonefile: "root.zone" zonefile: "root.zone"
]]></artwork> ]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Example Configuration: Knot Resolver"> <name>Example Configuration: Knot Resolver</name>
<t>Knot Resolver uses its "prefill" module to load the root zone <t>Knot Resolver uses its "prefill" module to load the root zone
information. This is described at information. This is described at
&lt;https://knot-resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html& gt;.</t> &lt;<eref target="https://knot-resolver.readthedocs.io/en/v5.0.1/modules -rfc7706.html"/>&gt;.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Example Configuration: Microsoft Windows Server 2012"> <name>Example Configuration: Microsoft Windows Server 2012</name>
<t>Windows Server 2012 contains a DNS server in the "DNS Manager" <t>Windows Server 2012 contains a DNS server in the "DNS Manager"
component. When activated, that component acts as a recursive server. component. When activated, that component acts as a recursive server.
DNS Manager can also act as an authoritative server.</t> The DNS Manager can also act as an authoritative server.</t>
<t>Using this configuration, queries for information in the root zone <t>Using this configuration, queries for information in the root zone
are returned with the AA bit set.</t> are returned with the AA bit set.</t>
<t>The steps to configure the DNS Manager to implement the requirements
<t>The steps to configure DNS Manager to implement the requirements in in
this document are: <list style="numbers"> this document are: </t>
<t>Launch the DNS Manager GUI. This can be done from the command <ol spacing="normal" type="1">
<li>Launch the DNS Manager GUI. This can be done from the command
line ("dnsmgmt.msc") or from the Service Manager (the "DNS" line ("dnsmgmt.msc") or from the Service Manager (the "DNS"
command in the "Tools" menu).</t> command in the "Tools" menu).</li>
<li>In the hierarchy under the server on which the service is
<t>In the hierarchy under the server on which the service is
running, right-click on the "Forward Lookup Zones", and select running, right-click on the "Forward Lookup Zones", and select
"New Zone". This brings up a succession of dialog boxes.</t> "New Zone". This brings up a succession of dialog boxes.</li>
<li>In the "Zone Type" dialog box, select "Secondary zone".</li>
<t>In the "Zone Type" dialog box, select "Secondary zone".</t> <li>In the "Zone Name" dialog box, enter ".".</li>
<li>In the "Master DNS Servers" dialog box, enter
<t>In the "Zone Name" dialog box, enter ".".</t>
<t>In the "Master DNS Servers" dialog box, enter
"b.root&nbhy;servers.net". The system validates that it can do a "b.root&nbhy;servers.net". The system validates that it can do a
zone transfer from that server. (After this configuration is zone transfer from that server. (After this configuration is
completed, the DNS Manager will attempt to transfer from all of completed, the DNS Manager will attempt to transfer from all of
the root zone servers.)</t> the root zone servers.)</li>
<li>In the "Completing the New Zone Wizard" dialog box, click
<t>In the "Completing the New Zone Wizard" dialog box, click "Finish".</li>
"Finish".</t> <li>Verify that the DNS Manager is acting as a recursive resolver.
<t>Verify that the DNS Manager is acting as a recursive resolver.
Right-click on the server name in the hierarchy, choosing the Right-click on the server name in the hierarchy, choosing the
"Advanced" tab in the dialog box. See that "Disable recursion "Advanced" tab in the dialog box. See that "Disable recursion
(also disables forwarders)" is not selected, and that "Enable (also disables forwarders)" is not selected and that "Enable
DNSSEC validation for remote responses" is selected.</t> DNSSEC validation for remote responses" is selected.</li>
</list></t> </ol>
</section> </section>
</section> </section>
<section numbered="false" toc="default">
<section numbered="no" title="Acknowledgements"> <name>Acknowledgements</name>
<t>The authors fully acknowledge that running a copy of the root zone on <t>The authors fully acknowledge that running a copy of the root zone on
the loopback address is not a new concept, and that we have chatted with the loopback address is not a new concept and that we have chatted with
many people about that idea over time. For example, Bill Manning many people about that idea over time. For example, <contact fullname="Bil
l Manning"/>
described a similar solution to the problems in his doctoral described a similar solution to the problems in his doctoral
dissertation in 2013 <xref target="Manning2013"/>.</t> dissertation in 2013 <xref target="Manning2013" format="default"/>.</t>
<t><contact fullname="Evan Hunt"/> contributed greatly to the logic in
<t>Evan Hunt contributed greatly to the logic in the requirements. Other the requirements. Other
significant contributors include Wouter Wijngaards, Tony Hain, Doug significant contributors include <contact fullname="Wouter
Barton, Greg Lindsay, and Akira Kato. The authors also received many Wijngaards"/>, <contact fullname="Tony Hain"/>, <contact fullname="Doug
Barton"/>, <contact fullname="Greg Lindsay"/>, and <contact
fullname="Akira Kato"/>. The authors also received many
offline comments about making the document clear that this is just a offline comments about making the document clear that this is just a
description of a way to operate a root zone on the same host, and not a description of a way to operate a root zone on the same host and not a
recommendation to do so.</t> recommendation to do so.</t>
<t>People who contributed to this update to <xref target="RFC7706"
<t>People who contributed to this update to RFC 7706 include: Florian format="default"/> include <contact fullname="Florian Obser"/>,
Obser, nusenu, Wouter Wijngaards, Mukund Sivaraman, Bob Harold, and <contact fullname="nusenu"/>, <contact fullname="Wouter Wijngaards"/>,
Leo Vegoda.</t> <contact fullname="Mukund Sivaraman"/>, <contact fullname="Bob
Harold"/>, and <contact fullname="Leo Vegoda"/>.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 97 change blocks. 
318 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/