< draft-ietf-dnsop-7706bis-04.txt   draft-ietf-dnsop-7706bis-05.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Updates: 7706 (if approved) P. Hoffman Updates: 7706 (if approved) P. Hoffman
Intended status: Informational ICANN Intended status: Informational ICANN
Expires: January 6, 2020 July 5, 2019 Expires: February 27, 2020 August 26, 2019
Running a Root Server Local to a Resolver Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-04 draft-ietf-dnsop-7706bis-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 such as during a network attack.
operators want to prevent snooping of requests sent to DNS root Some DNS recursive resolver operators want to prevent snooping by
servers by third parties. Such resolvers can greatly decrease the third parties of requests sent to DNS root servers. Such resolvers
round-trip time and prevent observation of requests by running a copy can greatly decrease the round-trip time and prevent observation of
of the full root zone on the same server, such as on a loopback requests by serving a copy of the full root zone on the same server,
address. This document shows how to start and maintain such a copy such as on a loopback address or in the resolver software. This
of the root zone that does not pose a threat to other users of the document shows how to start and maintain such a copy of the root zone
DNS, at the cost of adding some operational fragility for the that does not cause problems for other users of the DNS, at the cost
operator. of adding some operational fragility for the operator.
This draft will update RFC 7706. See Section 1.1 for a list of
topics that will be added in the update.
[ Ed note: Text inside square brackets ([]) is additional background
information, answers to freqently asked questions, general musings,
etc. They will be removed before publication.]
[ This document is being collaborated on in Github at: [ This document is being collaborated on in Github at:
https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent
version of the document, open issues, and so on should all be version of the document, open issues, and so on should all be
available there. The authors gratefully accept pull requests. ] 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 7 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2020. This Internet-Draft will expire on February 27, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4 1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operation of the Root Zone on the Local Server . . . . . . . 5 3. Operation of the Root Zone on the Local Server . . . . . . . 5
4. Using the Root Zone Server on the Same Host . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8 A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 8
A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 9 Appendix B. Example Configurations of Common Implementations . . 8
Appendix B. Example Configurations of Common Implementations . . 9
B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9 B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9
B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 11 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10
B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 12 B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11
B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 12 B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 11
B.5. Example Configuration: Knot Resolver . . . . . . . . . . 13 B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12
B.6. Example Configuration: Microsoft Windows Server 2012 . . 13 B.6. Example Configuration: Microsoft Windows Server 2012 . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 for domain names that do not exist. For their customers, even those for domain names that do not exist. For
each queried name that has a top-level domain (TLD) that is not in each queried name that is within a top-level domain (TLD) that is not
the recursive resolver's cache, the resolver must send a query to a in the recursive resolver's cache, the resolver must send a query to
root server to get the information for that TLD, or to find out that a root server to get the information for that TLD, or to find out
the TLD does not exist. Research shows that the vast majority of that the TLD does not exist. Research shows that the vast majority
queries going to the root are for names that do not exist in the root of queries going to the root are for names that do not exist in the
zone because negative answers are sometimes cached for a much shorter root zone because negative answers are sometimes cached for a much
period of time. shorter period of time.
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, and to prevent for queries to the root zone during network attacks, and to prevent
queries and responses from being visible on the network. This design queries and responses from being visible on the network. This design
will probably have little effect on getting faster responses to stub will probably have little effect on getting faster responses to stub
resolver for good queries on TLDs, because the TTL for most TLDs is resolver for good queries on TLDs, because the TTL for most TLDs is
usually long-lived (on the order of a day or two) and is thus usually usually long-lived (on the order of a day or two) and is thus usually
already in the cache of the recursive resolver; the same is true for already in the cache of the recursive resolver; the same is true for
the TTL for negative answers from the root servers. (Although the the TTL for negative answers from the root servers. (Although the
primary goal of the design is for serving the root zone, the method primary goal of the design is for serving the root zone, the method
can be used for any zone.) 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 these resolver to have a complete root zone locally, and to hide queries
queries from outsiders. The basic idea is to create an up-to-date for the root zone from outsiders. The basic idea is to create an up-
root zone server on the same host as the recursive server, and use to-date root zone service on the same host as the recursive server,
that server when the recursive resolver looks up root information. and use that service when the recursive resolver looks up root
The recursive resolver validates all responses from the root server information. The recursive resolver validates all responses from the
on the same host, just as it would all responses from a remote root root service on the same host, just as it would all responses from a
server. remote root server.
This design explicitly only allows the new root zone server to be run This design explicitly only allows the new root zone service to be
on the same server as the recursive resolver, in order to prevent the run on the same server as the recursive resolver, in order to prevent
server from serving authoritative answers to any other system. the server from serving authoritative answers to any other system.
Specifically, the root server on the local system MUST be configured Specifically, the root service on the local system MUST be configured
to only answer queries from the resolvers on the same host, and MUST to only answer queries from resolvers on the same host, and MUST NOT
NOT answer queries from any other resolver. answer queries from any other resolver.
At the time that RFC 7706 was published, it was considered At the time that RFC 7706 was published, it was considered
controversial: there was not consensus on whether this was a "best controversial: there was not consensus on whether this was a "best
practice". In fact, many people felt that it is an excessively risky practice". In fact, many people felt that it is an excessively risky
practice because it introduced a new operational piece to local DNS practice because it introduced a new operational piece to local DNS
operations where there was not one before. Since then, the DNS operations where there was not one before. Since then, the DNS
operational community has largely shifted to believing that local operational community has largely shifted to believing that local
serving of the root zone for an individual resolver is a reasonable serving of the root zone for an individual resolver is a reasonable
practice. The advantages listed above do not come free: if this new practice. The advantages listed above do not come free: if this new
system does not work correctly, users can get bad data, or the entire system does not work correctly, users can get bad data, or the entire
recursive resolution system might fail in ways that are hard to recursive resolution system might fail in ways that are hard to
diagnose. diagnose.
This design uses authoritative name server software running on the This design uses authoritative service running on the same machine as
same machine as the recursive resolver. Thus, recursive resolver the recursive resolver. Common open source recursive resolver
software such as BIND or modern versions of common open source software does not need to add new functionality to act as an
recursive resolver software do not need to add new functionality, but authoritative server for some zones, but other recursive resolver
other recursive resolver software might need to be able to talk to an software might need to be able to talk to an authoritative server
authoritative server running on the same host. running on the same host.
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].
1.1. Updates from RFC 7706 1.1. Updates from RFC 7706
RFC 7706 explicitly required that the root server instance be run on RFC 7706 explicitly required that a root server instance be run on
the loopback interface of the host running the validating resolver. the loopback interface of the host running the validating resolver.
However, RFC 7706 also had examples of how to set up common software However, RFC 7706 also had examples of how to set up common software
that did not use the loopback interface. Thus, this document loosens that did not use the loopback interface. This document loosens the
the restriction on the interface but keeps the requirement that only restriction on using the loopback interface and in fact allows the
systems running on that single host be able to query that root server use of a local service, not necessarily an authoritative server.
instance. However, the document keeps the requirement that only systems running
on that single host be able to query that authoritatve root server or
service.
This document changes the use cases for running a local root service
more consistent with the reasons operators said they had for 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, and
others have expressed an interest in doing so. 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.
[ This section will list all the changes from RFC 7706. For this
draft, it is also the list of changes that we will make in future
versions of the daft. ]
[ Make the use cases explicit. Be clearer that a real use case is
folks who are worried that root server unavailabilty due to DDoS
against them is a reason some people would use the mechanisms here.
]
[ Describe how slaving the root zone from root zone servers does not
fully remove the reliance on the root servers being available. ]
[ Other new topics might go here. ]
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all 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 a zone with DNSSEC [RFC4033]. o The system MUST be able to validate every signed record in a zone
with DNSSEC [RFC4033].
o The system MUST have an up-to-date copy of the key used to sign o The system MUST have an up-to-date copy of the key used to sign
the DNS root. the DNS root.
o The system MUST be able to retrieve a copy of the entire root zone o 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 server for the o The system MUST be able to run an authoritative service for the
root zone on the same host. The root server instance MUST only root zone on the same host. The authoritative root service MUST
respond to queries from the same host. One way to assure not only respond to queries from the same host. One way to assure not
responding to queries from other hosts is to make the address of responding to queries from other hosts is to run an authoritative
the authoritative server one of the loopback addresses (that is, server for the root that responds only on one of the loopback
an address in the range 127/8 for IPv4 or ::1 in IPv6). addresses (that is, an address in the range 127/8 for IPv4 or ::1
in IPv6). Another method to have the resolver software also act
as an 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 8 skipping to change at page 5, line 48
The operation of an authoritative server for the root in the system The operation of an authoritative server for the root in the system
described here can be done separately from the operation of the described here can be done separately from the operation of the
recursive resolver, or it might be part of the configuration of the recursive resolver, or it might be part of the configuration of the
recursive resolver system. recursive resolver system.
The steps to set up the root zone are: The steps to set up the root zone are:
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 an address 2. Start the authoritative service for the root zone in a manner
on the host that is not in use. For IPv4, this could be that prevents any system other than a recursive resolver on the
127.0.0.1, but if that address is in use, any address in 127/8 is same host from accessing it.
acceptable. For IPv6, this would be ::1. It can also be a
publicly-visible address on the host, but only if the
authoritative server software allows restricting the addresses
that can access the authoritative server, and the software is
configured to only allow access from addresses on this single
host.
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.
If the contents of the root zone cannot be refreshed before the In a system that is using a local authoritative server for the root
expire time in the SOA, the local root server MUST return a SERVFAIL zone. if the contents of the root zone cannot be refreshed before
error response for all queries sent to it until the zone can be the expire time in the SOA, the local root server MUST return a
successfully be set up again. Because this would cause a recursive SERVFAIL error response for all queries sent to it until the zone can
resolver on the same host that is relying on this root server to also be successfully be set up again. Because this would cause the
fail, a resolver might be configured to immediatly switch to using recursive resolver to also fail, the resolver MUST immediatly switch
other (non-local) root servers if the resolver receives a SERVFAIL to using other (non-local) root servers if the resolver receives a
response from a local root server. SERVFAIL response from a local root server.
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 immediatly switch to using
non-local root servers.
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 (such as 2 days); if 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 the refreshing of the local root zone is broken during that time, the
recursive resolver 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; this might be part of the resolver software. are being refreshed; this might be part of the resolver software.
One way to do this is to have a separate process that periodically One way to do this is to have a separate process that periodically
checks the SOA of the root zone from the local root zone and makes checks the SOA of the local root zone and makes sure that it is
sure that it is changing. At the time that this document is changing. At the time that this document is published, the SOA for
published, the SOA for the root zone is the digital representation of the root zone is the digital representation of the current date with
the current date with a two-digit counter appended, and the SOA is a two-digit counter appended, and the SOA is changed every day even
changed every day even if the contents of the root zone are if the contents of the root zone are unchanged. For example, the SOA
unchanged. For example, the SOA of the root zone on January 2, 2018 of the root zone on January 2, 2019 was 2019010201. A process can
was 2018010201. A process can use this fact to create a check for use this fact to create a check for the contents of the local root
the contents of the local root zone (using a program not specified in zone (using a program not specified in this document).
this document).
4. Using the Root Zone Server on the Same Host
A recursive resolver that wants to use a root zone server operating
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
responses from the root server MUST be validated using DNSSEC.
Note that using this simplistic configuration will cause the
recursive resolver to fail if the local root zone server fails. A
more robust configuration would cause the resolver to start using the
normal remote root servers when the local root server fails (such as
if it does not respond or gives SERVFAIL responses).
See Appendix B for more discussion of this for specific software.
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
to the recursive server. Make sure the response that comes back has
the AA bit in the message header set to 0.
5. Security Considerations 4. 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 the same host, answering queries only root zone server to be run on the same host, answering queries only
from resolvers on that host, in order to prevent the server from from resolvers on that host, in order to prevent the server from
serving authoritative answers to any system other than the recursive serving authoritative answers to any system other than the recursive
resolver. This has the security property of limiting damage to any resolver. This has the security property of limiting damage to any
other system that might try to rely on an altered copy of the root. other system that might try to rely on an altered copy of the root.
6. References 5. References
6.1. Normative References 5.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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://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", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
6.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
5.2. Informative References
[Manning2013] [Manning2013]
Manning, 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>.
[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) 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. One can servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. One can
also get the root zone from ICANN as a text file over HTTP (not also get the root zone from IANA as a text file over HTTPS at
HTTPS) at <http://http.l.root-servers.org/root.txt>. <https://www.internic.net/domain/root.zone>.
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 o b.root-servers.net
o c.root-servers.net o c.root-servers.net
o d.root-servers.net o d.root-servers.net
skipping to change at page 9, line 5 skipping to change at page 8, line 28
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 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
contents of the zone cannot be refreshed before the expire time, the
server MUST return a SERVFAIL error response for all queries until
the zone can be successfully be set up again.
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.
skipping to change at page 14, line 32 skipping to change at page 13, line 32
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 RFC 7706 include: Florian
Obser, nusenu, Wouter Wijngaards, [[ others go here ]]. Obser, nusenu, Wouter Wijngaards, and Mukund Sivaraman.
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. 28 change blocks. 
147 lines changed or deleted 114 lines changed or added

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