< draft-ietf-dnsop-7706bis-10.txt   draft-ietf-dnsop-7706bis-11.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Obsoletes: 7706 (if approved) P. Hoffman Obsoletes: 7706 (if approved) P. Hoffman
Intended status: Informational ICANN Intended status: Informational ICANN
Expires: September 6, 2020 March 5, 2020 Expires: September 13, 2020 March 12, 2020
Running a Root Server Local to a Resolver Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-10 draft-ietf-dnsop-7706bis-11
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. Such resolvers can greatly decrease the round-trip time and servers. Such resolvers can greatly decrease the round-trip time and
prevent observation of requests by serving a copy of the full root prevent observation of requests by serving a copy of the full root
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 September 6, 2020. This Internet-Draft will expire on September 13, 2020.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4 1.1. Changes from RFC 7706 . . . . . . . . . . . . . . . . . . 4
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 9 A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 2, line 47 skipping to change at page 2, line 47
B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11 B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11
B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 12 B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 12
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
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 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 the TLD does not exist. Research shows that the vast majority that the TLD does not exist. Research shows that the vast majority
of queries going to the root are for names that do not exist in the of queries going to the root are for names that do not exist in the
root zone. root 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, and to prevent for queries to the root zone during network attacks that affect the
queries and responses from being visible on the network. This design root servers, and to prevent queries and responses from being visible
will probably have little effect on getting faster responses to stub on the network. This design will probably have little effect on
resolver for good queries on TLDs, because the TTL for most TLDs is getting faster responses to stub resolver for good queries on TLDs,
usually long-lived (on the order of a day or two) and is thus usually because the TTL for most TLDs is usually long-lived (on the order of
already in the cache of the recursive resolver; the same is true for a day or two) and is thus usually already in the cache of the
the TTL for negative answers from the root servers. (Although the recursive resolver; the same is true for the TTL for negative answers
primary goal of the design is for serving the root zone, the method from the root servers. (Although the primary goal of the design is
can be used for any zone.) 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 the root zone from outsiders. The basic idea is to create an up- for the root zone from outsiders. The basic idea is to create an up-
to-date root zone service on the same host as the recursive server, to-date root zone service on the same host as the recursive server,
and use that service when the recursive resolver looks up root and 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.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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].
Readers are expected to be familiar with [RFC8499]. Readers are expected to be familiar with [RFC8499].
1.1. Updates from RFC 7706 1.1. Changes from RFC 7706
RFC 7706 explicitly required that a 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. 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.
skipping to change at page 9, line 23 skipping to change at page 9, line 23
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 RFC 7706.
The IPv4 and IPv6 addresses in this section were checked recently by The IPv4 and IPv6 addresses in this section were checked in March
testing for AXFR over TCP from each address for the known single- 2020 by testing for AXFR over TCP from each address for the known
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
 End of changes. 8 change blocks. 
18 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/