< draft-ietf-dnsop-7706bis-06.txt   draft-ietf-dnsop-7706bis-07.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: May 20, 2020 November 17, 2019 Expires: July 15, 2020 January 12, 2020
Running a Root Server Local to a Resolver Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-06 draft-ietf-dnsop-7706bis-07
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 May 20, 2020. This Internet-Draft will expire on July 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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. Updates 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.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 . . . . . . . . . . . . 8 B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9
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
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 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 because negative answers are sometimes cached for a much root zone.
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
skipping to change at page 4, line 10 skipping to change at page 4, line 10
practice. The advantages listed above do not come free: if this new practice. The advantages listed above do not come free: if this new
system does not work correctly, users can get bad data, or the entire system does not work correctly, users can get bad data, or the entire
recursive resolution system might fail in ways that are hard to recursive resolution system might fail in ways that are hard to
diagnose. diagnose.
This design uses authoritative service running on the same machine as This design uses authoritative service running on the same machine as
the recursive resolver. Common open source recursive resolver the recursive resolver. Common open source recursive resolver
software does not need to add new functionality to act as an software does not need to add new functionality to act as an
authoritative server for some zones, but other recursive resolver authoritative server for some zones, but other recursive resolver
software might need to be able to talk to an authoritative server software might need to be able to talk to an authoritative server
running on the same host. running on the same host. Some resolver software supports being both
an authoritative server and a resolver but separated by logical
"views", allowing a local root to be implemented within a single
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].
1.1. Updates from RFC 7706 1.1. Updates 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
skipping to change at page 6, line 18 skipping to change at page 6, line 18
be a little behind those of the global root servers because those be a little behind those of the global root servers because those
servers are updated when triggered by NOTIFY messages. servers are updated when triggered by NOTIFY messages.
There is a risk that a system using a local authoritative server for There is a risk that a system using a local authoritative server for
the root zone cannot refresh the contents of the root zone before the the root zone cannot refresh the contents of the root zone before the
expire time in the SOA. A system using a local authoritative server expire time in the SOA. A system using a local authoritative server
for the root zone MUST NOT serve stale data for the root zone. To for the root zone MUST NOT serve stale data for the root zone. To
mitigate the risk that stale data is served, the local root server mitigate the risk that stale data is served, the local root server
MUST immediately switch to using non-local root servers. MUST immediately switch to using non-local root servers.
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
if the contents of the root zone cannot be refreshed before the the contents of the root zone cannot be refreshed before the expire
expire time in the SOA, the resolver MUST immediately switch to using time in the SOA, the resolver MUST immediately switch to using non-
non-local root servers. 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.
skipping to change at page 6, line 51 skipping to change at page 6, line 51
4. 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 local
root zone server to be run on the same host, answering queries only copy of the root zone information to be available only from resolvers
from resolvers on that host, in order to prevent the server from on that host. This has the security property of limiting damage to
serving authoritative answers to any system other than the recursive clients of any local resolver that might try to rely on an altered
resolver. This has the security property of limiting damage to any copy of the root.
other system that might try to rely on an altered copy of the root.
5. References 5. IANA Considerations
5.1. Normative References This document has no actions for IANA.
6. References
6.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
5.2. Informative References 6.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
skipping to change at page 11, line 29 skipping to change at page 11, line 29
master: 2001:500:12::d0d # g.root-servers.net master: 2001:500:12::d0d # g.root-servers.net
master: 2001:7fd::1 # k.root-servers.net master: 2001:7fd::1 # k.root-servers.net
master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org
master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org
fallback-enabled: yes fallback-enabled: yes
for-downstream: no for-downstream: no
for-upstream: yes for-upstream: yes
B.3. Example Configuration: BIND 9.14 B.3. Example Configuration: BIND 9.14
BIND 9.14 (which, at the time of publication of this document is a BIND 9.14 can set up a local mirror of the root zone with a small
future release) can set up a local mirror of the root zone with a configuration option:
small configuration option:
zone "." { zone "." {
type mirror; type mirror;
}; };
The simple "type mirror" configuration for the root zone works for The simple "type mirror" configuration for the root zone works for
the root zone because a default list of primary servers for the IANA the root zone because a default list of primary servers for the IANA
root zone is built into BIND 9.14. In order to set up mirroring of root zone is built into BIND 9.14. In order to set up mirroring of
any other zone, an explicit list of primary servers needs to be any other zone, an explicit list of primary servers needs to be
provided. provided.
See the documentation for BIND 9.14 (when it is released) for more See the documentation for BIND 9.14 for more detail about how to use
detail about how to use this simplified configuration this simplified configuration.
B.4. Example Configuration: Unbound 1.9 B.4. Example Configuration: Unbound 1.9
Recent versions of Unbound have a "auth-zone" feature that allows Recent versions of Unbound have a "auth-zone" feature that allows
local mirroring of the root zone. Configuration looks like: local mirroring of the root zone. Configuration looks like:
auth-zone: auth-zone:
name: "." name: "."
master: "b.root-servers.net" master: "b.root-servers.net"
master: "c.root-servers.net" master: "c.root-servers.net"
 End of changes. 15 change blocks. 
29 lines changed or deleted 34 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/