<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!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 --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="info" docName="draft-ietf-dnsop-7706bis" consensus="true" docName="draft-ietf-dnsop-7706bis-12"
     number="8806" 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 compact="yes" ?> obsoletes="7706" updates="" xml:lang="en"
     tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.41.0 -->

  <front>
    <title abbrev="Root Server Local">Running a Root Server Local to a
    Resolver</title>
    <seriesInfo name="RFC" value="8806"/>
    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google</organization>
      <address>
        <email>Warren@kumari.net</email>
      </address>
    </author>
    <author fullname="Paul Hoffman" initials="P." surname="Hoffman">
      <organization>ICANN</organization>
      <address>
        <email>paul.hoffman@icann.org</email>
      </address>
    </author>
    <date year="2020"/> year="2020" month="June" />

<keyword>DNS</keyword>
<keyword>local-root</keyword>

    <abstract>
      <t>Some DNS recursive resolvers have longer-than-desired round-trip
      times to the closest DNS root server; those resolvers may have
      difficulty getting responses from the root servers, such as during a
      network attack. Some DNS recursive resolver operators want to prevent
      snooping by third parties of requests sent to DNS root servers. In both
      cases, resolvers can greatly decrease the round-trip time and prevent
      observation of requests by serving a copy of the full root zone on the
      same server, such as on a loopback address or in the resolver
      software. This 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 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>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <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
      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
      server to get the information for that TLD, TLD or to find out that the TLD
      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>
      <t>Many of the queries from recursive resolvers to root servers get
      answers that are referrals to other servers. Malicious third parties
      might be able to observe that traffic on the network between the
      recursive resolver and root servers.</t>
      <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 servers,
      servers and to prevent
      queries and responses from being visible on the network. This design
      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
      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
      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
      used for any zone.)</t>
      <t>This document describes a method for the operator of a recursive
      resolver to have a complete root zone locally, locally and to hide queries for the 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, server and use that service
      when the recursive resolver looks up root information. The recursive
      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>
      <t>This design explicitly only allows the new root zone service to be run
      on the same server as the recursive resolver, resolver in order to prevent the
      server from serving authoritative answers to any other system.
      Specifically, the root service on the local system MUST <bcp14>MUST</bcp14> be configured to
      only answer queries from resolvers on the same host, host and MUST NOT <bcp14>MUST NOT</bcp14>
      answer queries from any other resolver.</t>

      <t>At the time that RFC 7706 <xref target="RFC7706"/> target="RFC7706" format="default">RFC 7706</xref> was
      published, it was considered
      controversial:
      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
      practice, because it introduced a new operational piece to local DNS
      operations where there was not one before. Since then, the DNS
      operational community has largely shifted to believing that local
      serving of the root zone for an individual resolver is a reasonable
      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
      recursive resolution system might fail in ways that are hard to
      diagnose.</t>
      <t>This design uses an authoritative service running on the
      same machine as the recursive resolver.
      Common open source recursive
      resolver software does not need to add new functionality to
      act as an authoritative server for some zones, but other
      recursive resolver software might need to be able to talk to an
      authoritative server running on the same host.
      Some resolver software supports being both an authoritative server
      and a resolver but separated by logical "views", allowing a local
      root to be implemented within a single process; examples of this
      can be seen in <xref target="examples"/>.</t> target="examples" format="default"/>.</t>
      <t>A different approach to solving some of the problems discussed in
      this document is described in <xref target="RFC8198"/>.</t> target="RFC8198" format="default"/>.</t>
      <t>Readers are expected to be familiar with <xref target="RFC8499"/>.</t> target="RFC8499"
      format="default"/>.</t>
      <section title="Changes numbered="true" toc="default">
        <name>Changes from RFC 7706"> 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.
        However, RFC 7706 also had examples
	of how to set up common software
        that did not use the loopback interface. This document loosens
        the restriction on using the loopback interface and in fact
        allows the use of a local service, not necessarily an
        authoritative server. However, the document keeps the requirement that only
        systems running on that single host be able to query that authoritative root
        server or service.</t>
        <t>This document changes the use cases for running a local root
        service to be more consistent with the reasons operators said they had for
        using RFC 7706.</t>

        <t>Removed 7706:</t>
	<ul spacing="normal">
        <li>Removed the prohibition on distribution of recursive DNS servers servers,
        including configurations for this design because some already do, do and
        others have expressed an interest in doing so.</t>

        <t>Added so.</li>
        <li>Added the idea that a recursive resolver using this design might
        switch to using the normal (remote) root servers if the local root
        server fails.</t>

        <t>Refreshed fails.</li>
        <li>Refreshed the list of where one can get copies of the root zone.</t>

        <t>Added zone.</li>
        <li>Added examples of other resolvers and updated the existing examples.</t>
	examples.</li>
	</ul>
      </section>
      <section title="Requirements Notation">
        <t>The anchor="reqnot" numbered="true" toc="default">
	<name>Requirements Notation</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="reqs" title="Requirements"> numbered="true" toc="default">
      <name>Requirements</name>
      <t>In order to implement the mechanism described in this document:</t>

      <t><list style="symbols">
          <t>The
      <ul spacing="normal">
        <li>The system MUST <bcp14>MUST</bcp14> be able to validate every signed
	record in a zone with DNSSEC <xref
          target="RFC4033"/>.</t>

          <t>The target="RFC4033"
	format="default"/>.</li>
        <li>The system MUST <bcp14>MUST</bcp14> have an up-to-date copy of the
	public part of the Key Signing Key (KSK) <xref
          target="RFC4033"/> target="RFC4033"
	format="default"/> used to sign the DNS root.</t>

          <t>The root.</li>
        <li>The system MUST <bcp14>MUST</bcp14> be able to retrieve a copy of the entire root
          zone (including all DNSSEC-related records).</t>

          <t>The records).</li>
        <li>The system MUST <bcp14>MUST</bcp14> be able to run an authoritative service for the
          root zone on the same host. The authoritative root service MUST <bcp14>MUST</bcp14> only
          respond to queries from the same host. One way to assure ensure that the
	  authoritative root service does not
          responding respond to queries from other
	  hosts is to run an authoritative server for the root that responds
	  only on one of the loopback addresses (that is, an address in the
	  range 127/8 for IPv4 or ::1 in IPv6). Another method is to have the
	  resolver software also act as an authoritative server for the root
	  zone, but only for answering queries from itself.</t>
        </list></t> itself.</li>
      </ul>
      <t>A corollary of the above list is that authoritative data in the root
      zone used on the local authoritative server MUST <bcp14>MUST</bcp14> be identical to 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
      changes could cause problems for the recursive server that accesses the
      local root zone, and therefore any changes to the glue records SHOULD
      NOT <bcp14>SHOULD
      NOT</bcp14> be made.</t>
    </section>
    <section anchor="zoneop"
             title="Operation numbered="true" toc="default">
      <name>Operation of the Root Zone on the Local Server"> Server</name>
      <t>The operation of an authoritative server for the root in the system
      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 system.</t>
      <t>The steps to set up the root zone are:</t>

      <t><list style="numbers">
          <t>Retrieve
      <ol spacing="normal" type="1">
        <li>Retrieve a copy of the root zone. (See <xref target="sources"/> target="sources" format="default"/>
          for some current locations of sources.)</t>

          <t>Start sources.)</li>
        <li>Start the authoritative service for the root zone in a manner that
          prevents any system other than a recursive resolver on the same host
          from accessing it.</t>
        </list></t> it.</li>
      </ol>
      <t>The contents of the root zone MUST <bcp14>MUST</bcp14> be refreshed using the timers from
      the SOA record in the root zone, as described in
      <xref
      target="RFC1035"/>. 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
      servers
      servers, because those servers are updated when triggered by NOTIFY
      messages.</t>
      <t>There is a risk that a system using a local authoritative server for the
      root zone cannot refresh the contents of the root zone before the expire time
      in the SOA. A system using a local authoritative server for the root zone
      MUST NOT
      <bcp14>MUST NOT</bcp14> serve stale data for the root zone. To mitigate
      the risk that stale
      data is served, the local root server MUST <bcp14>MUST</bcp14> immediately switch to using
      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,
      if the contents of the root zone cannot be refreshed before the
      expire time in the SOA, the resolver MUST <bcp14>MUST</bcp14> immediately switch to
      using non-local root servers.</t>
      <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
      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
      recursive resolver will have bad data for the entire TLD zone.</t>
      <t>An administrator using the procedure in this document SHOULD <bcp14>SHOULD</bcp14> have an
      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
      do this is to have a separate process that periodically checks the SOA
      of the local root zone and makes sure that it is
      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
      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
      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
      program not specified in this document).</t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>A system that does not follow the DNSSEC-related requirements given
      in <xref target="reqs"/> target="reqs" format="default"/> can be fooled into giving bad responses in the
      same way as any recursive resolver that does not do DNSSEC validation on
      responses from a remote root server. Anyone deploying the method
      described in this document should be familiar with the operational
      benefits and costs of deploying DNSSEC <xref target="RFC4033"/>.</t> target="RFC4033" format="default"/>.</t>
      <t>As stated in <xref target="intro"/>, target="intro" format="default"/>, this design explicitly
      requires the local copy of the root zone information to be
      available only from resolvers on that host.
      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
      root.</t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no actions for IANA.</t> IANA actions.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.1035'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.4033'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.7706'?>

      <?rfc include='reference.RFC.8499'?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7706.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
      </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.5936'?>

      <?rfc include='reference.RFC.8198'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8198.xml"/>

        <reference anchor="Manning2013" target="http://www.sfc.wide.ad.jp/dissertation/bill_e.html">
          <front>
            <title>Client Based Naming</title>
            <author fullname="William Manning" initials="W." surname="Manning"/>
            <date month="May" year="2013"/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="sources" title="Current numbered="true" toc="default">
      <name>Current Sources of the Root Zone"> Zone</name>
      <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
      root zone from ICANN by zone transfer (AXFR) AXFR
      <xref target="RFC5936"/> target="RFC5936" format="default"/> over TCP from DNS servers at
      xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
      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
      following root server operators:</t>

      <t><list style="symbols">
          <t>b.root-servers.net</t>

          <t>c.root-servers.net</t>

          <t>d.root-servers.net</t>

          <t>f.root-servers.net</t>

          <t>g.root-servers.net</t>

          <t>k.root-servers.net</t>
        </list></t>
      <ul spacing="normal">
        <li>b.root-servers.net</li>
        <li>c.root-servers.net</li>
        <li>d.root-servers.net</li>
        <li>f.root-servers.net</li>
        <li>g.root-servers.net</li>
        <li>k.root-servers.net</li>
      </ul>
      <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
      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
      ones above are) may conceivably have transfer problems due to anycast,
      but current practice shows that to be unlikely.</t>
      <section title="Root numbered="true" toc="default">
        <name>Root Zone Services"> Services</name>
        <t>At the time that this document is published, there is one root zone service
      that is active, active and one that has been announced as in the planning stages.
      This section describes all known active services.</t>
        <t>LocalRoot (&lt;https://localroot.isi.edu/&gt;) (&lt;<eref target="https://localroot.isi.edu/"/>&gt;) is an experimental
      service that embodies many of the ideas in this document. It
      distributes the root zone by AXFR, AXFR and also offers DNS NOTIFY messages
      when the LocalRoot system sees that the root zone has changed.</t>
      </section>
    </section>
    <section anchor="examples"
             title="Example numbered="true" toc="default">
      <name>Example Configurations of Common Implementations"> Implementations</name>
      <t>This section shows fragments of configurations for some popular
      recursive server software that is believed to correctly implement the
      requirements given in this document. The examples have been updated
      since the publication of RFC 7706.</t> <xref target="RFC7706" format="default"/>.</t>
      <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
      names in the root-servers.net zone.</t>
      <section title="Example numbered="true" toc="default">
        <name>Example Configuration: BIND 9.12"> 9.12</name>
        <t>BIND 9.12 acts both as a recursive resolver and an authoritative server.
        Because of this, there is "fate-sharing" between the two servers in
        the following configuration. That is, if the root server dies, it is
        likely that all of BIND is dead.</t>
        <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
        <xref target="bind-9-14"/>.</t> target="bind-9-14" format="default"/>.</t>
        <t>Using this configuration, queries for information in the root zone
        are returned with the AA Authoritative Answer (AA) bit not set.</t>
        <t>When slaving a zone, BIND 9.12 will treat zone data differently if 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
        performing the recursion.</t>

        <t><list style="hanging">
            <t hangText="Validation:">When
        <dl newline="false" spacing="normal">
          <dt>Validation:</dt>
          <dd>When using separate views or separate
            instances, the DS records in the slaved zone will be validated as
            the zone data is accessed by the recursive server. When using the
            same view, this validation does not occur for the slaved zone.</t>

            <t hangText="Caching:">When zone.</dd>
          <dt>Caching:</dt>
          <dd>When using separate views or instances, the
            recursive server will cache all of the queries for the slaved
            zone, just as it would using the traditional "root hints" method.
            Thus, as the zone in the other view or instance is refreshed or
            updated, changed information will not appear in the recursive
            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
            same view, all zone data in the recursive server will be updated
            as soon as it receives its copy of the zone.</t>
          </list></t>

        <figure>
          <artwork><![CDATA[ zone.</dd>
        </dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
view root {
    match-destinations { 127.12.12.12; };
    zone "." {
        type slave;
        file "rootzone.db";
        notify no;
        masters {
            199.9.14.201;         # b.root-servers.net
            192.33.4.12;          # c.root-servers.net
            199.7.91.13;          # d.root-servers.net
            192.5.5.241;          # f.root-servers.net
            192.112.36.4;         # g.root-servers.net
            193.0.14.129;         # k.root-servers.net
            192.0.47.132;         # xfr.cjr.dns.icann.org
            192.0.32.132;         # xfr.lax.dns.icann.org
            2001:500:200::b;      # b.root-servers.net
            2001:500:2::c;        # c.root-servers.net
            2001:500:2d::d;       # d.root-servers.net
            2001:500:2f::f;       # f.root-servers.net
            2001:500:12::d0d;     # g.root-servers.net
            2001:7fd::1;          # k.root-servers.net
            2620:0:2830:202::132; # xfr.cjr.dns.icann.org
            2620:0:2d0:202::132;  # xfr.lax.dns.icann.org
        };
    };
};

view recursive {
    dnssec-validation auto;
    allow-recursion { any; };
    recursion yes;
    zone "." {
        type static-stub;
        server-addresses { 127.12.12.12; };
    };
};
]]></artwork>
        </figure>
      </section>
      <section title="Example numbered="true" toc="default">
        <name>Example Configuration: Unbound 1.8"> 1.8</name>
        <t>Similar to BIND, Unbound Unbound, starting with version 1.8 1.8, can act both as
        a recursive resolver and an authoritative server.</t>

        <figure>
          <artwork><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[
auth-zone:
    name: "."
    master: 199.9.14.201         # b.root-servers.net
    master: 192.33.4.12          # c.root-servers.net
    master: 199.7.91.13          # d.root-servers.net
    master: 192.5.5.241          # f.root-servers.net
    master: 192.112.36.4         # g.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.32.132         # xfr.lax.dns.icann.org
    master: 2001:500:200::b      # b.root-servers.net
    master: 2001:500:2::c        # c.root-servers.net
    master: 2001:500:2d::d       # d.root-servers.net
    master: 2001:500:2f::f       # f.root-servers.net
    master: 2001:500:12::d0d     # g.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:2d0:202::132  # xfr.lax.dns.icann.org
    fallback-enabled: yes
    for-downstream: no
    for-upstream: yes
]]></artwork>
        </figure>
      </section>
      <section title="Example anchor="bind-9-14" numbered="true" toc="default">
        <name>Example Configuration: BIND 9.14" anchor="bind-9-14"> 9.14</name>
        <t>BIND 9.14 can set up a local mirror of the root zone with a
        small configuration option:</t>

        <figure>
          <artwork><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[
zone "." {
    type mirror;
};
]]></artwork>
        </figure>
        <t>The simple "type mirror" configuration for the root zone works
        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
        of any other zone, an explicit list of primary servers needs to be
        provided.</t>
        <t>See the documentation for BIND 9.14 for more detail
        about how to use this simplified configuration.</t>
      </section>
      <section title="Example numbered="true" toc="default">
        <name>Example Configuration: Unbound 1.9"> 1.9</name>
        <t>Recent versions of Unbound have a an "auth-zone" feature that allows local
        mirroring of the root zone. Configuration looks like:</t>
        <figure>
          <artwork><![CDATA[ as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
auth-zone:
    name: "."
    master: "b.root-servers.net"
    master: "c.root-servers.net"
    master: "d.root-servers.net"
    master: "f.root-servers.net"
    master: "g.root-servers.net"
    master: "k.root-servers.net"
        fallback-enabled: yes
    for-downstream: no
    for-upstream: yes
    zonefile: "root.zone"
]]></artwork>
        </figure>
      </section>
      <section title="Example numbered="true" toc="default">
        <name>Example Configuration: Knot Resolver"> Resolver</name>
        <t>Knot Resolver uses its "prefill" module to load the root zone
        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 title="Example numbered="true" toc="default">
        <name>Example Configuration: Microsoft Windows Server 2012"> 2012</name>
        <t>Windows Server 2012 contains a DNS server in the "DNS Manager"
        component. When activated, that component acts as a recursive server.
        The DNS Manager can also act as an authoritative server.</t>
        <t>Using this configuration, queries for information in the root zone
        are returned with the AA bit set.</t>
        <t>The steps to configure the DNS Manager to implement the requirements in
        this document are: <list style="numbers">
            <t>Launch </t>
        <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"
            command in the "Tools" menu).</t>

            <t>In menu).</li>
          <li>In the hierarchy under the server on which the service is
            running, right-click on the "Forward Lookup Zones", and select
            "New Zone". This brings up a succession of dialog boxes.</t>

            <t>In boxes.</li>
          <li>In the "Zone Type" dialog box, select "Secondary zone".</t>

            <t>In zone".</li>
          <li>In the "Zone Name" dialog box, enter ".".</t>

            <t>In ".".</li>
          <li>In the "Master DNS Servers" dialog box, enter
            "b.root&nbhy;servers.net". The system validates that it can do a
            zone transfer from that server. (After this configuration is
            completed, the DNS Manager will attempt to transfer from all of
            the root zone servers.)</t>

            <t>In servers.)</li>
          <li>In the "Completing the New Zone Wizard" dialog box, click
            "Finish".</t>

            <t>Verify
            "Finish".</li>
          <li>Verify that the DNS Manager is acting as a recursive resolver.
            Right-click on the server name in the hierarchy, choosing the
            "Advanced" tab in the dialog box. See that "Disable recursion
            (also disables forwarders)" is not selected, selected and that "Enable
            DNSSEC validation for remote responses" is selected.</t>
          </list></t> selected.</li>
        </ol>
      </section>
    </section>
    <section numbered="no" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors fully acknowledge that running a copy of the root zone on
      the loopback address is not a new concept, concept and that we have chatted with
      many people about that idea over time. For example, Bill Manning <contact fullname="Bill Manning"/>
      described a similar solution to the problems in his doctoral
      dissertation in 2013 <xref target="Manning2013"/>.</t>

      <t>Evan Hunt target="Manning2013" format="default"/>.</t>
      <t><contact fullname="Evan Hunt"/> contributed greatly to the logic in
      the requirements. Other
      significant contributors include Wouter Wijngaards, Tony Hain, Doug
      Barton, Greg Lindsay, and Akira Kato. <contact fullname="Wouter
      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
      description of a way to operate a root zone on the same host, host and not a
      recommendation to do so.</t>
      <t>People who contributed to this update to RFC 7706 include: Florian
      Obser, nusenu, Wouter Wijngaards, Mukund Sivaraman, Bob Harold, and
      Leo Vegoda.</t> <xref target="RFC7706"
      format="default"/> include <contact fullname="Florian Obser"/>,
      <contact fullname="nusenu"/>, <contact fullname="Wouter Wijngaards"/>,
      <contact fullname="Mukund Sivaraman"/>, <contact fullname="Bob
      Harold"/>, and <contact fullname="Leo Vegoda"/>.</t>
    </section>
  </back>
</rfc>