draft-ietf-dnsop-root-loopback-05.txt   rfc7706.txt 
Network Working Group W. Kumari Internet Engineering Task Force (IETF) W. Kumari
Internet-Draft Google Request for Comments: 7706 Google
Intended status: Informational P. Hoffman Category: Informational P. Hoffman
Expires: April 3, 2016 ICANN ISSN: 2070-1721 ICANN
October 1, 2015 November 2015
Decreasing Access Time to Root Servers by Running One on Loopback Decreasing Access Time to Root Servers by Running One on Loopback
draft-ietf-dnsop-root-loopback-05
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. Some DNS recursive resolver times to the closest DNS root server. Some DNS recursive resolver
operators want to prevent snooping of requests sent to DNS root operators want to prevent snooping of requests sent to DNS root
servers by third parties. Such resolvers can greatly decrease the servers by third parties. Such resolvers can greatly decrease the
round trip time and prevent observation of requests by running a copy round-trip time and prevent observation of requests by running a copy
of the full root zone on a loopback address (such as 127.0.0.1). of the full root zone on a loopback address (such as 127.0.0.1).
This document shows how to start and maintain such a copy of the root This document shows how to start and maintain such a copy of the root
zone that does not pose a threat to other users of the DNS, at the zone that does not pose a threat to other users of the DNS, at the
cost of adding some operational fragility for the operator. cost of adding some operational fragility for the operator.
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 http://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 a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 3, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7706.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation of the Root Zone on the Loopback Address . . . . . 4 3. Operation of the Root Zone on the Loopback Address . . . . . 5
4. Using the Root Zone Server on the Loopback Address . . . . . 5 4. Using the Root Zone Server on the Loopback Address . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7
Appendix B. Example Configurations of Common Implementations . . 8 Appendix B. Example Configurations of Common Implementations . . 8
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 8 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 9 B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10
B.3. Example Configuration: Microsoft Windows Server 2012 . . 10 B.3. Example Configuration: Microsoft Windows Server 2012 . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 customers, even those which are for domain names that do not their customers, even those for domain names that do not exist. For
exist. For each queried name that has a top level domain (TLD) that each queried name that has a top-level domain (TLD) that is not in
is not in the recursive resolver's cache, the resolver must send a the recursive resolver's cache, the resolver must send a query to a
query to a root server to get the information for that TLD, or to root server to get the information for that TLD, or to find out that
find out that the TLD does not exist. Typically, the vast majority the TLD does not exist. Typically, the vast majority of queries
of queries going to the root are for names that do not exist in the going to the root are for names that do not exist in the root zone,
root zone, and the negative answers are cached for a much shorter and the negative answers are cached for a much shorter period of
period of time. A slow path between the recursive resolver and the time. A slow path between the recursive resolver and the closest
closest root server has a negative effect on the resolver's root server has a negative effect on the resolver's customers.
customers.
Recursive resolvers currently send queries for all TLDs that are not Recursive resolvers currently send queries for all TLDs that are not
in their caches to root servers, even though most of those queries in their caches to root servers, even though most of those queries
get answers that are referrals to other servers. Malicious third get answers that are referrals to other servers. Malicious third
parties might be able to observe that traffic on the network between parties might be able to observe that traffic on the network between
the recursive resolver and one or more of the DNS roots. the recursive resolver and one or more of the DNS roots.
This document describes a method for the operator of a recursive This document describes a method for the operator of a recursive
resolver to greatly speed these queries and to hide them from resolver to greatly speed these queries and to hide them from
outsiders. The basic idea is to create an up-to-date root zone outsiders. The basic idea is to create an up-to-date root zone
server on a loopback address on the same host as the recursive server on a loopback address on the same host as the recursive
server, and use that server when the recursive resolver looks up root server, and use that server 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 server on the loopback address, just as it would all responses root server on the loopback address, just as it would all responses
from a remote root server. from a remote root server.
The primary goals of this design is to provide faster negative The primary goals of this design are to provide faster negative
responses to stub resolver queries that contain junk queries, and to responses to stub resolver queries that contain junk queries, and to
prevent queries and responses from being visible on the network. prevent queries and responses from being visible on the network.
This design will probably have little effect on getting faster This design will probably have little effect on getting faster
positive responses to stub resolver for good queries on TLDs, because positive responses to stub resolver for good queries on TLDs, because
the data for those zones is usually long-lived and already in the the data for those zones is usually long-lived and already in the
cache of the recursive resolver; thus, getting faster positive cache of the recursive resolver; thus, getting faster positive
responses is a non-goal of this design. responses is a non-goal of this design.
This design explicitly only allows the new root zone server to be run This design explicitly only allows the new root zone server to be run
on a loopback address, in order to prevent the server from serving on a loopback address, in order to prevent the server from serving
authoritative answers to any system other than the recursive authoritative answers to any system other than the recursive
resolver. resolver.
It is important to note that this design is being described here is It is important to note that the design being described here is not
not considered a "best practice". In fact, many people feel that it considered a "best practice". In fact, many people feel that it is
is an excessively risky practice because it introduces a new an excessively risky practice because it introduces a new operational
operational piece to local DNS operations where there was not one piece to local DNS operations where there was not one before. The
before. The advantages listed above do not come free: if this new advantages listed above do not come free: if this new system does not
system does not work correctly, users can get bad data, or the entire work correctly, users can get bad data, or the entire recursive
recursive resolution system might fail in ways that are hard to resolution system might fail in ways that are hard to diagnose.
diagnose.
This design requires the addition of authoritative name server This design requires the addition of authoritative name server
software running on the same machine as the recursive resolver. software running on the same machine as the recursive resolver.
Thus, recursive resolver software such as BIND will not need to add Thus, recursive resolver software such as BIND will not need to add
much new functionality, but recursive resolver software such as much new functionality, but recursive resolver software such as
Unbound will need to be able to talk to an authoritative server (such Unbound will need to be able to talk to an authoritative server (such
as NSD) running on the same host. as NSD) running on the same host.
Because of the significant operational risks described in this Because of the significant operational risks described in this
document, distributions of recursive DNS servers MUST NOT include document, distributions of recursive DNS servers MUST NOT include
skipping to change at page 4, line 51 skipping to change at page 5, line 25
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 server with the root zone on a loopback 2. Start the authoritative server with the root zone on a loopback
address that is not in use. For IPv4, this would typically be address that is not in use. For IPv4, this would typically be
127.0.0.1, but if that address is in use, any address in 127/8 is 127.0.0.1, but if that address is in use, any address in 127/8 is
acceptable. For IPv6, this would be ::1. acceptable. For IPv6, this would be ::1.
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 root zone, as described in [RFC1035]. This the SOA record in the root zone, as described in [RFC1035]. This
inherently means that the conents 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 triggered by NOTIFY messages. If the contents of servers are updated when triggered by NOTIFY messages. If the
the zone cannot be refreshed before the expire time, the server MUST contents of the zone cannot be refreshed before the expire time, the
return a SERVFAIL error response for all queries until the zone can server MUST return a SERVFAIL error response for all queries until
be successfully be set up again. the zone can be successfully be set up again.
In the event that refreshing the contents of the root zone fails, the In the event that refreshing the contents of the root zone fails, the
results can be disastrous. For example, sometimes all the NS records results can be disastrous. For example, sometimes all the NS records
for a TLD are changed in a short period of time; if the local root for a TLD are changed in a short period of time (such as 2 days); if
zone refreshing is broken during that time, the recursive resolver the refreshing of the local root zone is broken during that time, the
will have bad data for the entire TLD zone. recursive resolver will have bad data for the entire TLD zone.
An administrator using the procedure in this document SHOULD have an An administrator using the procedure in this document SHOULD have an
automated method to check that the contents of the local root zone automated method to check that the contents of the local root zone
are being refreshed. One way to do this is to have a separate are being refreshed. One way to do this is to have a separate
process that periodically checks the SOA of the root zone from the process that periodically checks the SOA of the root zone from the
local root zone and makes sure that they are changing. At the time local root zone and makes sure that it is changing. At the time that
that this document is published, the SOA for the root zone is the this document is published, the SOA for the root zone is the digital
digital representation of the current date with a two-digit counter representation of the current date with a two-digit counter appended,
appended, and the SOA is changed every day even if the contents of and the SOA is changed every day even if the contents of the root
the root zone are unchanged. For example, the SOA of the root zone zone are unchanged. For example, the SOA of the root zone on January
on January 2, 2015 was 2015010201. A process can use this fact to 2, 2015 was 2015010201. A process can use this fact to create a
create a check for the contents of the local root zone (using a check for the contents of the local root zone (using a program not
program not specified in this document). specified in this document).
4. Using the Root Zone Server on the Loopback Address 4. Using the Root Zone Server on the Loopback Address
A recursive resolver that wants to use a root zone server operating A recursive resolver that wants to use a root zone server operating
as described in Section 3 simply specifies the local address as the as described in Section 3 simply specifies the local address as the
place to look when it is looking for information from the root. All place to look when it is looking for information from the root. All
responses from the root server must be validated using DNSSEC. responses from the root server must be validated using DNSSEC.
Note that using this configuration will cause the recursive resolver Note that using this configuration will cause the recursive resolver
to fail if the local root zone server fails. See Appendix B for more to fail if the local root zone server fails. See Appendix B for more
discussion of this for specific software. discussion of this for specific software.
To test the proper operation of the recursive resolver with the local To test the proper operation of the recursive resolver with the local
root server, use a DNS client to send a query for the SOA of the root root server, use a DNS client to send a query for the SOA of the root
to the recursive server. Make sure the response that comes back has to the recursive server. Make sure the response that comes back has
the AA bit in the message header set to 0. the AA bit in the message header set to 0.
5. IANA Considerations 5. Security Considerations
This document requires no action from the IANA.
6. Security Considerations
A system that does not follow the DNSSEC-related requirements given A system that does not follow the DNSSEC-related requirements given
in Section 2 can be fooled into giving bad responses in the same way in Section 2 can be fooled into giving bad responses in the same way
as any recursive resolver that does not do DNSSEC validation on 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 [RFC4033]. benefits and costs of deploying DNSSEC [RFC4033].
As stated in Section 1, this design explicitly only allows the new As stated in Section 1, this design explicitly only allows the new
root zone server to be run on a loopback address, in order to prevent root zone server to be run on a loopback address, in order to prevent
the server from serving authoritative answers to any system other the server from serving authoritative answers to any system other
than the recursive resolver. This has the security property of than the recursive resolver. This has the security property of
limiting damage to any other system that might try to rely on the limiting damage to any other system that might try to rely on an
copy of the root in case that copy becomes altered. altered copy of the root.
7. Acknowledgements
The editors fully acknowledge that this is not a new concept, and
that we have chatted with many people about this. In fact, this
concept may already have been implemented without the knowledge of
the authors. For example, Bill Manning described a similar solution
but to a very different problem (intermittent connectivity, instead
of constant but slow connectivity) in his doctoral dissertation in
2013 [Manning2013].
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. The authors also received
many off-line comments about making the document clear that this was
just a description of a way to operate a root zone on localhost, and
not a recommendation to do so.
8. References 6. References
8.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, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://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
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
8.2. Informative References 6.2. Informative References
[AggressiveNSEC] [AggressiveNSEC]
Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3",
draft-fujiwara-dnsop-nsec-aggressiveuse-00 (work in Work in Progress, draft-fujiwara-dnsop-nsec-
progress), 2015. aggressiveuse-02, October 2015.
[Manning2013] [Manning2013]
Maning, W., "Client Based Naming", 2013, Manning, W., "Client Based Naming", 2013,
<http://www.sfc.wide.ad.jp/dissertation/bill_e.html>. <http://www.sfc.wide.ad.jp/dissertation/bill_e.html>.
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) over TCP from DNS the root zone from ICANN by zone transfer (AXFR) over TCP from DNS
servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
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
skipping to change at page 7, line 45 skipping to change at page 8, line 29
o f.root-servers.net o f.root-servers.net
o g.root-servers.net o g.root-servers.net
o k.root-servers.net o 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 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.
To repeat the requirement from earlier in this document: if the To repeat the requirement from earlier in this document: if the
contents of the zone cannot be refreshed before the expire time, the contents of the zone cannot be refreshed before the expire time, the
server MUST return a SERVFAIL error response for all queries until server MUST return a SERVFAIL error response for all queries until
the zone can be successfully be set up again. the zone can be successfully be set up again.
Appendix B. Example Configurations of Common Implementations Appendix B. Example Configurations of Common Implementations
skipping to change at page 8, line 23 skipping to change at page 9, line 8
letter names in the root-servers.net zone. letter names in the root-servers.net zone.
The examples here use a loopback address of 127.12.12.12, but typical The examples here use a loopback address of 127.12.12.12, but typical
installations will use 127.0.0.1. The different address is used in installations will use 127.0.0.1. The different address is used in
order to emphasize that the root server does not need to be on the order to emphasize that the root server does not need to be on the
device at "localhost". device at "localhost".
B.1. Example Configuration: BIND 9.9 B.1. Example Configuration: BIND 9.9
BIND acts both as a recursive resolver and an authoritative server. BIND acts both as a recursive resolver and an authoritative server.
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. likely that all of BIND is dead.
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 AA bit not set.
When slaving a zone, BIND will treat zone data differently if it is When slaving a zone, BIND will treat zone data differently if the
slaved into a separate view (or a separate instance of the software) zone is slaved into a separate view (or a separate instance of the
versus slaving the zone into the same view or instance that is also software) versus slaved into the same view or instance that is also
performing the recursion. 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.
Caching: When using separate views or instances, the recursive Caching: When using separate views or instances, the recursive
server will cache all of the queries for the slaved zone, just as server will cache all of the queries for the slaved zone, just as
it would using the traditional root hints method. Thus, as the it would using the traditional "root hints" method. Thus, as the
zone in the other view or instance is refreshed or updated, zone in the other view or instance is refreshed or updated,
changed information will not appear in the recursive server until changed information will not appear in the recursive server until
the TTL of the old record times out. Currently the TTL for DS and the TTL of the old record times out. Currently, the TTL for DS
delegation NS records is two days. When using the same view, all and delegation NS records is two days. When using the same view,
zone data in the recursive server will be updated as soon as it all zone data in the recursive server will be updated as soon as
receives its copy of the zone. it receives its copy of the zone.
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 {
192.228.79.201; # b.root-servers.net 192.228.79.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net 192.33.4.12; # c.root-servers.net
skipping to change at page 9, line 41 skipping to change at page 10, line 41
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.4 and NSD 4 B.2. Example Configuration: Unbound 1.4 and NSD 4
Unbound and NSD are separate software packages. Because of this, Unbound and NSD are separate software packages. Because of this,
there is no "fate sharing" between the two servers in the following there is no "fate-sharing" between the two servers in the following
configurations. That is, if the root server instance (NSD) dies, the configurations. That is, if the root server instance (NSD) dies, the
recursive resolver instance (Unbound) will probably keep running, but recursive resolver instance (Unbound) will probably keep running but
will not be able to resolve any queries for the root zone. will not be able to resolve any queries for the root zone.
Therefore, the administrator of this configuration might want to Therefore, the administrator of this configuration might want to
carefully monitor the NSD instance and restart it immediately if it carefully monitor the NSD instance and restart it immediately if it
dies. dies.
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 AA bit not set.
# Configuration for Unbound # Configuration for Unbound
server: server:
skipping to change at page 11, line 7 skipping to change at page 12, line 7
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".
4. In the "Zone Name" dialog box, enter ".". 4. In the "Zone Name" dialog box, enter ".".
5. In the "Master DNS Servers" dialog box, enter "b.root- 5. In the "Master DNS Servers" dialog box, enter
servers.net". The system validates that it can do a zone "b.root-servers.net". The system validates that it can do a zone
transfer from that server. (After this configuration is transfer from that server. (After this configuration is
completed, DNS Manager will attempt to transfer from all of the completed, the DNS Manager will attempt to transfer from all of
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 hierarch, 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
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 many people about that idea over time. For example, Bill
Manning described a similar solution but to a very different problem
(intermittent connectivity, instead of constant but slow
connectivity) in his doctoral dissertation in 2013 [Manning2013].
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. 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 localhost, and
not a recommendation to do so.
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
Email: Warren@kumari.net Email: Warren@kumari.net
Paul Hoffman Paul Hoffman
ICANN ICANN
 End of changes. 37 change blocks. 
121 lines changed or deleted 111 lines changed or added

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