< draft-ietf-dnsop-7706bis-05.txt   draft-ietf-dnsop-7706bis-06.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: February 27, 2020 August 26, 2019 Expires: May 20, 2020 November 17, 2019
Running a Root Server Local to a Resolver Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-05 draft-ietf-dnsop-7706bis-06
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 such as during a network attack. times to the closest DNS root server such as during a network attack.
Some DNS recursive resolver operators want to prevent snooping by Some DNS recursive resolver operators want to prevent snooping by
third parties of requests sent to DNS root servers. Such resolvers third parties of requests sent to DNS root servers. Such resolvers
can greatly decrease the round-trip time and prevent observation of can greatly decrease the round-trip time and prevent observation of
requests by serving a copy of the full root zone on the same server, requests by serving a copy of the full root zone on the same server,
such as on a loopback address or in the resolver software. This such as on a loopback address or in the resolver software. This
skipping to change at page 1, line 45 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 February 27, 2020. This Internet-Draft will expire on May 20, 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 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. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7
A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 8 A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 8
Appendix B. Example Configurations of Common Implementations . . 8 Appendix B. Example Configurations of Common Implementations . . 8
B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9 B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 8
B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10
B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11 B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11
B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 11 B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 11
B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12 B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12
B.6. Example Configuration: Microsoft Windows Server 2012 . . 12 B.6. Example Configuration: Microsoft Windows Server 2012 . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
skipping to change at page 4, line 28 skipping to change at page 4, line 28
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. 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 authoritatve root server or on that single host be able to query that authoritatve root server or
service. 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
more consistent with the reasons operators said they had for using to be more consistent with the reasons operators said they had for
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, 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.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
[RFC8174] when, and only when, they appear in all capitals, as shown [RFC8174] when, and only when, they appear in all capitals, as shown
here. 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 o 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 key used to sign o The system MUST have an up-to-date copy of the KSK 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 service for the o 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 assure not
responding to queries from other hosts is to run an authoritative responding to queries from other hosts is to run an authoritative
server for the root that responds only on one of the loopback server for the root that responds only on one of the loopback
addresses (that is, an address in the range 127/8 for IPv4 or ::1 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 in IPv6). Another method is to have the resolver software also
as an authoritative server for the root zone, but only for act as an authoritative server for the root zone, but only for
answering queries from itself. 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.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
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.
In a system that is using a local authoritative server for the root There is a risk that a system using a local authoritative server for
zone. if the contents of the root zone cannot be refreshed before the root zone cannot refresh the contents of the root zone before the
the expire time in the SOA, the local root server MUST return a expire time in the SOA. A system using a local authoritative server
SERVFAIL error response for all queries sent to it until the zone can for the root zone MUST NOT serve stale data for the root zone. To
be successfully be set up again. Because this would cause the mitigate the risk that stale data is served, the local root server
recursive resolver to also fail, the resolver MUST immediatly switch MUST immediately switch to using non-local root servers.
to using other (non-local) root servers if the resolver receives a
SERVFAIL response from a local root server.
In a resolver that is using an internal service for the root zone. In a resolver that is using an internal service for the root zone.
if the contents of the root zone cannot be refreshed before the if the contents of the root zone cannot be refreshed before the
expire time in the SOA, the resolver MUST immediatly switch to using expire time in the SOA, the resolver MUST immediately switch to using
non-local root servers. 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
skipping to change at page 13, 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, and Mukund Sivaraman. Obser, nusenu, Wouter Wijngaards, Mukund Sivaraman, Bob Harold, and
Leo Vegoda.
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. 10 change blocks. 
19 lines changed or deleted 18 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/