draft-ietf-dnsop-7706bis-12.txt   rfc8806.txt 
Network Working Group W. Kumari Internet Engineering Task Force (IETF) W. Kumari
Internet-Draft Google Request for Comments: 8806 Google
Obsoletes: 7706 (if approved) P. Hoffman Obsoletes: 7706 P. Hoffman
Intended status: Informational ICANN Category: Informational ICANN
Expires: September 14, 2020 March 13, 2020 ISSN: 2070-1721 June 2020
Running a Root Server Local to a Resolver Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-12
Abstract Abstract
Some DNS recursive resolvers have longer-than-desired round-trip Some DNS recursive resolvers have longer-than-desired round-trip
times to the closest DNS root server; those resolvers may have times to the closest DNS root server; those resolvers may have
difficulty getting responses from the root servers, such as during a difficulty getting responses from the root servers, such as during a
network attack. Some DNS recursive resolver operators want to network attack. Some DNS recursive resolver operators want to
prevent snooping by third parties of requests sent to DNS root prevent snooping by third parties of requests sent to DNS root
servers. In both cases, resolvers can greatly decrease the round- servers. In both cases, resolvers can greatly decrease the round-
trip time and prevent observation of requests by serving a copy of 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 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 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 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 for other users of the DNS, at the cost of adding some operational
fragility for the operator. fragility for the operator.
This document obsoletes RFC 7706. This document obsoletes RFC 7706.
[ 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. ]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on September 14, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8806.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Changes from RFC 7706 . . . . . . . . . . . . . . . . . . 4 1.1. Changes from RFC 7706
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Notation
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements
3. Operation of the Root Zone on the Local Server . . . . . . . 5 3. Operation of the Root Zone on the Local Server
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.1. Normative References
6.2. Informative References . . . . . . . . . . . . . . . . . 8 6.2. Informative References
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8 Appendix A. Current Sources of the Root Zone
A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 9 A.1. Root Zone Services
Appendix B. Example Configurations of Common Implementations . . 9 Appendix B. Example Configurations of Common Implementations
B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9 B.1. Example Configuration: BIND 9.12
B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 11 B.2. Example Configuration: Unbound 1.8
B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11 B.3. Example Configuration: BIND 9.14
B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 12 B.4. Example Configuration: Unbound 1.9
B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12 B.5. Example Configuration: Knot Resolver
B.6. Example Configuration: Microsoft Windows Server 2012 . . 12 B.6. Example Configuration: Microsoft Windows Server 2012
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses
1. Introduction 1. Introduction
DNS recursive resolvers have to provide answers to all queries from DNS recursive resolvers have to provide answers to all queries from
their clients, even those for domain names that do not exist. For 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 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 in the 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 a root server to get the information for that TLD or to find out that
that the TLD does not exist. Research shows that the vast majority the TLD does not exist. Research shows that the vast majority of
of queries going to the root are for names that do not exist in the queries going to the root are for names that do not exist in the root
root zone. zone.
Many of the queries from recursive resolvers to root servers get 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. recursive resolver and root servers.
The primary goals of this design are to provide more reliable answers The primary goals of this design are to provide more reliable answers
for queries to the root zone during network attacks that affect the for queries to the root zone during network attacks that affect the
root servers, and to prevent queries and responses from being visible root servers and to prevent queries and responses from being visible
on the network. This design will probably have little effect on on the network. This design will probably have little effect on
getting faster responses to stub resolver for good queries on TLDs, getting faster responses to the stub resolver for good queries on
because the TTL for most TLDs is usually long-lived (on the order of TLDs, because the TTL for most TLDs is usually long-lived (on the
a day or two) and is thus usually already in the cache of the order of a day or two) and is thus usually already in the cache of
recursive resolver; the same is true for the TTL for negative answers the recursive resolver; the same is true for the TTL for negative
from the root servers. (Although the primary goal of the design is answers from the root servers. (Although the primary goal of the
for serving the root zone, the method can be used for any zone.) design is for serving the root zone, the method can be used for any
zone.)
This document describes a method for the operator of a recursive This document describes a method for the operator of a recursive
resolver to have a complete root zone locally, and to hide queries resolver to have a complete root zone locally and to hide queries for
for the root zone from outsiders. The basic idea is to create an up- the root zone from outsiders. The basic idea is to create an up-to-
to-date root zone service on the same host as the recursive server, date root zone service on the same host as the recursive server and
and use that service when the recursive resolver looks up root use that service when the recursive resolver looks up root
information. The recursive resolver validates all responses from the information. The recursive resolver validates all responses from the
root service on the same host, just as it would validate all root service on the same host, just as it would validate all
responses from a remote root server. responses from a remote root server.
This design explicitly only allows the new root zone service to be 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 run on the same server as the recursive resolver in order to prevent
the server from serving authoritative answers to any other system. the server from serving authoritative answers to any other system.
Specifically, the root service on the local system MUST be configured Specifically, the root service on the local system MUST be configured
to only answer queries from resolvers on the same host, and MUST NOT to only answer queries from resolvers on the same host and MUST NOT
answer queries from any other resolver. answer queries from any other resolver.
At the time that RFC 7706 [RFC7706] was published, it was considered At the time that RFC 7706 [RFC7706] was published, it was considered
controversial: there was not consensus on whether this was a "best controversial, because there was not consensus on whether this was a
practice". In fact, many people felt that it is an excessively risky "best practice". In fact, many people felt that it is an excessively
practice because it introduced a new operational piece to local DNS risky practice, because it introduced a new operational piece to
operations where there was not one before. Since then, the DNS local DNS operations where there was not one before. Since then, the
operational community has largely shifted to believing that local DNS 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. diagnose.
This design uses authoritative service running on the same machine as This design uses an authoritative service running on the same machine
the recursive resolver. Common open source recursive resolver as the recursive resolver. Common open source recursive resolver
software does not need to add new functionality to act as an software does not need to add new functionality to act as an
authoritative server for some zones, but other recursive resolver authoritative server for some zones, but other recursive resolver
software might need to be able to talk to an authoritative server software might need to be able to talk to an authoritative server
running on the same host. Some resolver software supports being both running on the same host. Some resolver software supports being both
an authoritative server and a resolver but separated by logical an authoritative server and a resolver but separated by logical
"views", allowing a local root to be implemented within a single "views", allowing a local root to be implemented within a single
process; examples of this can be seen in Appendix B. process; examples of this can be seen in Appendix B.
A different approach to solving some of the problems discussed in A different approach to solving some of the problems discussed in
this document is described in [RFC8198]. this document is described in [RFC8198].
skipping to change at page 4, line 34 skipping to change at line 167
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 the that did not use the loopback interface. This document loosens the
restriction on using the loopback interface and in fact allows the restriction on using the loopback interface and in fact allows the
use of a local service, not necessarily an authoritative server. use of a local service, not necessarily an authoritative server.
However, the document keeps the requirement that only systems running However, the document keeps the requirement that only systems running
on that single host be able to query that authoritative root server on that single host be able to query that authoritative root server
or service. or service.
This document changes the use cases for running a local root service This document changes the use cases for running a local root service
to be more consistent with the reasons operators said they had for to be more consistent with the reasons operators said they had for
using RFC 7706. using RFC 7706:
Removed the prohibition on distribution of recursive DNS servers * 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
others have expressed an interest in doing so. and others have expressed an interest in doing so.
Added the idea that a recursive resolver using this design might * 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. server fails.
Refreshed the list of where one can get copies of the root zone. * Refreshed the list of where one can get copies of the root zone.
Added examples of other resolvers and updated the existing examples. * Added examples of other resolvers and updated the existing
examples.
1.2. Requirements Notation 1.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Requirements 2. Requirements
In order to implement the mechanism described in this document: In order to implement the mechanism described in this document:
o The system MUST be able to validate every signed record in a zone * The system MUST be able to validate every signed record in a zone
with DNSSEC [RFC4033]. with DNSSEC [RFC4033].
o The system MUST have an up-to-date copy of the public part of the * The system MUST have an up-to-date copy of the public part of the
Key Signing Key (KSK) [RFC4033] used to sign the DNS root. Key Signing Key (KSK) [RFC4033] used to sign the DNS root.
o The system MUST be able to retrieve a copy of the entire root zone * The system MUST be able to retrieve a copy of the entire root zone
(including all DNSSEC-related records). (including all DNSSEC-related records).
o The system MUST be able to run an authoritative service for the * The system MUST be able to run an authoritative service for the
root zone on the same host. The authoritative root service MUST root zone on the same host. The authoritative root service MUST
only respond to queries from the same host. One way to assure not only respond to queries from the same host. One way to ensure
responding to queries from other hosts is to run an authoritative that the authoritative root service does not respond to queries
server for the root that responds only on one of the loopback from other hosts is to run an authoritative server for the root
addresses (that is, an address in the range 127/8 for IPv4 or ::1 that responds only on one of the loopback addresses (that is, an
in IPv6). Another method is to have the resolver software also address in the range 127/8 for IPv4 or ::1 in IPv6). Another
act as an authoritative server for the root zone, but only for method is to have the resolver software also act as an
answering queries from itself. authoritative server for the root zone, but only for answering
queries from itself.
A corollary of the above list is that authoritative data in the root 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 MUST be identical 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 unsigned data (the glue records) in the copy of the root zone, but
such changes could cause problems for the recursive server that such changes could cause problems for the recursive server that
accesses the local root zone, and therefore any changes to the glue accesses the local root zone, and therefore any changes to the glue
records SHOULD NOT be made. records SHOULD NOT be made.
3. Operation of the Root Zone on the Local Server 3. Operation of the Root Zone on the Local Server
skipping to change at page 6, line 12 skipping to change at line 241
1. Retrieve a copy of the root zone. (See Appendix A for some 1. Retrieve a copy of the root zone. (See Appendix A for some
current locations of sources.) current locations of sources.)
2. Start the authoritative service for the root zone in a manner 2. Start the authoritative service for the root zone in a manner
that prevents any system other than a recursive resolver on the that prevents any system other than a recursive resolver on the
same host from accessing it. same host from accessing it.
The contents of the root zone MUST be refreshed using the timers from The contents of the root zone MUST be refreshed using the timers from
the SOA record in the root zone, as described in [RFC1035]. This the SOA record in the root zone, as described in [RFC1035]. This
inherently means that the contents of the local root zone will likely inherently means that the contents of the local root zone will likely
be a little behind those of the global root servers because those be a little behind those of the global root servers, because those
servers are updated when triggered by NOTIFY messages. servers are updated when triggered by NOTIFY messages.
There is a risk that a system using a local authoritative server for 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 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 expire time in the SOA. A system using a local authoritative server
for the root zone MUST NOT serve stale data for the root zone. To for the root zone MUST NOT serve stale data for the root zone. To
mitigate the risk that stale data is served, the local root server mitigate the risk that stale data is served, the local root server
MUST immediately switch to using non-local root servers when it MUST immediately switch to using non-local root servers when it
detects that it would be serving state data. detects that it would be serving state data.
skipping to change at page 7, line 15 skipping to change at line 293
benefits and costs of deploying DNSSEC [RFC4033]. benefits and costs of deploying DNSSEC [RFC4033].
As stated in Section 1, this design explicitly requires the local As stated in Section 1, this design explicitly requires the local
copy of the root zone information to be available only from resolvers copy of the root zone information to be available only from resolvers
on that host. This has the security property of limiting damage to 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 clients of any local resolver that might try to rely on an altered
copy of the root. copy of the root.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no IANA actions.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 8, line 8 skipping to change at line 329
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
6.2. Informative References 6.2. Informative References
[Manning2013] [Manning2013]
Manning, W., "Client Based Naming", 2013, Manning, W., "Client Based Naming", May 2013,
<http://www.sfc.wide.ad.jp/dissertation/bill_e.html>. <http://www.sfc.wide.ad.jp/dissertation/bill_e.html>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>. <https://www.rfc-editor.org/info/rfc5936>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>. July 2017, <https://www.rfc-editor.org/info/rfc8198>.
Appendix A. Current Sources of the Root Zone Appendix A. Current Sources of the Root Zone
The root zone can be retrieved from anywhere as long as it comes with 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 all the DNSSEC records needed for validation. Currently, one can get
the root zone from ICANN by zone transfer (AXFR) [RFC5936] over TCP the root zone from ICANN by zone transfer AXFR [RFC5936] over TCP
from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. 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 The root zone file can be obtained using methods described at
<https://www.iana.org/domains/root/files>. <https://www.iana.org/domains/root/files>.
Currently, the root can also be retrieved by AXFR over TCP from the Currently, the root can also be retrieved by AXFR over TCP from the
following root server operators: following root server operators:
o b.root-servers.net * b.root-servers.net
o c.root-servers.net * c.root-servers.net
o d.root-servers.net * d.root-servers.net
o f.root-servers.net * f.root-servers.net
o g.root-servers.net * g.root-servers.net
o k.root-servers.net * k.root-servers.net
It is crucial to note that none of the above services are guaranteed 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 to be available. It is possible that ICANN or some of the root
server operators will turn off the AXFR capability on the servers server operators will turn off the AXFR capability on the servers
listed above. Using AXFR over TCP to addresses that are likely to be listed above. Using AXFR over TCP to addresses that are likely to be
anycast (as the ones above are) may conceivably have transfer anycast (as the ones above are) may conceivably have transfer
problems due to anycast, but current practice shows that to be problems due to anycast, but current practice shows that to be
unlikely. unlikely.
A.1. Root Zone Services A.1. Root Zone Services
At the time that this document is published, there is one root zone At the time that this document is published, there is one root zone
service that is active, and one that has been announced as in the service that is active and one that has been announced as in the
planning stages. This section describes all known active services. planning stages. This section describes all known active services.
LocalRoot (<https://localroot.isi.edu/>) is an experimental service LocalRoot (<https://localroot.isi.edu/>) is an experimental service
that embodies many of the ideas in this document. It distributes the that embodies many of the ideas in this document. It distributes the
root zone by AXFR, and also offers DNS NOTIFY messages when the root zone by AXFR and also offers DNS NOTIFY messages when the
LocalRoot system sees that the root zone has changed. LocalRoot system sees that the root zone has changed.
Appendix B. Example Configurations of Common Implementations Appendix B. Example Configurations of Common Implementations
This section shows fragments of configurations for some popular 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. since the publication of [RFC7706].
The IPv4 and IPv6 addresses in this section were checked in March 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 2020 by testing for AXFR over TCP from each address for the known
single-letter names in the root-servers.net zone. single-letter names in the root-servers.net zone.
B.1. Example Configuration: BIND 9.12 B.1. Example Configuration: BIND 9.12
BIND 9.12 acts both as a recursive resolver and an authoritative BIND 9.12 acts both as a recursive resolver and an authoritative
server. Because of this, there is "fate-sharing" between the two server. Because of this, there is "fate-sharing" between the two
servers in the following configuration. That is, if the root server servers in the following configuration. That is, if the root server
dies, it is likely that all of BIND is dead. dies, it is likely that all of BIND is dead.
Note that a future version of BIND will support a much more robust 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
Appendix B.3. Appendix B.3.
Using this configuration, queries for information in the root zone Using this configuration, queries for information in the root zone
are returned with the AA bit not set. are returned with the Authoritative Answer (AA) bit not set.
When slaving a zone, BIND 9.12 will treat zone data differently if 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 zone is slaved into a separate view (or a separate instance of
the software) versus slaved into the same view or instance that is the software) versus slaved into the same view or instance that is
also performing the recursion. also performing the recursion.
Validation: When using separate views or separate instances, the DS Validation: When using separate views or separate instances, the DS
records in the slaved zone will be validated as the zone data is records in the slaved zone will be validated as the zone data is
accessed by the recursive server. When using the same view, this accessed by the recursive server. When using the same view, this
validation does not occur for the slaved zone. validation does not occur for the slaved zone.
skipping to change at page 11, line 7 skipping to change at line 467
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; };
}; };
}; };
B.2. Example Configuration: Unbound 1.8 B.2. Example Configuration: Unbound 1.8
Similar to BIND, Unbound starting with version 1.8 can act both as a Similar to BIND, Unbound, starting with version 1.8, can act both as
recursive resolver and an authoritative server. a recursive resolver and an authoritative server.
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
skipping to change at page 12, line 7 skipping to change at line 512
the root zone because a default list of primary servers for the IANA 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 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 any other zone, an explicit list of primary servers needs to be
provided. provided.
See the documentation for BIND 9.14 for more detail about how to use See the documentation for BIND 9.14 for more detail about how to use
this simplified configuration. this simplified configuration.
B.4. Example Configuration: Unbound 1.9 B.4. Example Configuration: Unbound 1.9
Recent versions of Unbound have a "auth-zone" feature that allows Recent versions of Unbound have an "auth-zone" feature that allows
local mirroring of the root zone. Configuration looks like: local mirroring of the root zone. Configuration looks as follows:
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
skipping to change at page 12, line 33 skipping to change at line 538
B.5. Example Configuration: Knot Resolver B.5. Example Configuration: Knot Resolver
Knot Resolver uses its "prefill" module to load the root zone Knot Resolver uses its "prefill" module to load the root zone
information. This is described at <https://knot- information. This is described at <https://knot-
resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html>. resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html>.
B.6. Example Configuration: Microsoft Windows Server 2012 B.6. Example Configuration: Microsoft Windows Server 2012
Windows Server 2012 contains a DNS server in the "DNS Manager" Windows Server 2012 contains a DNS server in the "DNS Manager"
component. When activated, that component acts as a recursive component. When activated, that component acts as a recursive
server. DNS Manager can also act as an authoritative server. server. The DNS Manager can also act as an authoritative server.
Using this configuration, queries for information in the root zone Using this configuration, queries for information in the root zone
are returned with the AA bit set. are returned with the AA bit set.
The steps to configure DNS Manager to implement the requirements in The steps to configure the DNS Manager to implement the requirements
this document are: in this document are:
1. Launch the DNS Manager GUI. This can be done from the command 1. 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). command in the "Tools" menu).
2. In the hierarchy under the server on which the service is 2. 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. "New Zone". This brings up a succession of dialog boxes.
3. In the "Zone Type" dialog box, select "Secondary zone". 3. In the "Zone Type" dialog box, select "Secondary zone".
skipping to change at page 13, line 17 skipping to change at line 570
transfer from that server. (After this configuration is 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.) the root zone servers.)
6. In the "Completing the New Zone Wizard" dialog box, click 6. In the "Completing the New Zone Wizard" dialog box, click
"Finish". "Finish".
7. Verify that the DNS Manager is acting as a recursive resolver. 7. 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. DNSSEC validation for remote responses" is selected.
Acknowledgements Acknowledgements
The authors fully acknowledge that running a copy of the root zone on 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 the loopback address is not a new concept and that we have chatted
with many people about that idea over time. For example, Bill with many people about that idea over time. For example, Bill
Manning described a similar solution to the problems in his doctoral Manning described a similar solution to the problems in his doctoral
dissertation in 2013 [Manning2013]. dissertation in 2013 [Manning2013].
Evan Hunt contributed greatly to the logic in the requirements. Evan Hunt contributed greatly to the logic in the requirements.
Other significant contributors include Wouter Wijngaards, Tony Hain, Other significant contributors include Wouter Wijngaards, Tony Hain,
Doug Barton, Greg Lindsay, and Akira Kato. The authors also received Doug Barton, Greg Lindsay, and Akira Kato. The authors also received
many offline comments about making the document clear that this is 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, just a description of a way to operate a root zone on the same host
and not a recommendation to do so. and not a recommendation to do so.
People who contributed to this update to RFC 7706 include: Florian People who contributed to this update to [RFC7706] include Florian
Obser, nusenu, Wouter Wijngaards, Mukund Sivaraman, Bob Harold, and Obser, nusenu, Wouter Wijngaards, Mukund Sivaraman, Bob Harold, and
Leo Vegoda. Leo Vegoda.
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
Email: Warren@kumari.net Email: Warren@kumari.net
 End of changes. 48 change blocks. 
115 lines changed or deleted 111 lines changed or added

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