draft-ietf-dnsop-7706bis-07.txt   draft-ietf-dnsop-7706bis-08.txt 
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Updates: 7706 (if approved) P. Hoffman Obsoletes: 7706 (if approved) P. Hoffman
Intended status: Informational ICANN Intended status: Informational ICANN
Expires: July 15, 2020 January 12, 2020 Expires: September 2, 2020 March 1, 2020
Running a Root Server Local to a Resolver Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-07 draft-ietf-dnsop-7706bis-08
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
document shows how to start and maintain such a copy of the root zone document shows how to start and maintain such a copy of the root zone
that does not cause problems for other users of the DNS, at the cost that does not cause problems for other users of the DNS, at the cost
of adding some operational fragility for the operator. of adding some operational fragility for the operator.
This document obsoletes RFC 7706.
[ 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.
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 July 15, 2020. This Internet-Draft will expire on September 2, 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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. 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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 10 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 11
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 . . . . . . . . . . . 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 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
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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 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 all responses from a root service on the same host, just as it would all validate
remote root server. responses from a remote root server.
This design explicitly only allows the new root zone service to be This design explicitly only allows the new root zone service to be
run on the same server as the recursive resolver, in order to prevent run on the same server as the recursive resolver, in order to prevent
the server from serving authoritative answers to any other system. the server from serving authoritative answers to any other system.
Specifically, the root service on the local system MUST be configured Specifically, the root service on the local system MUST be configured
to only answer queries from resolvers on the same host, and MUST NOT to only answer queries from resolvers on the same host, and MUST 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 [RFC7706] 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.
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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. 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].
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
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 authoritative root server
service. or 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
to be more consistent with the reasons operators said they had for to be more consistent with the reasons operators said they had for
using 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.
Added examples of other resolvers and updated the existing examples. Added examples of other resolvers and updated the existing examples.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14 [RFC2119] "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC8174] when, and only when, they appear in all capitals, as shown 14 [RFC2119] [RFC8174] when, and only when, they appear in all
here. 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 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 KSK used to sign o The system MUST have an up-to-date copy of the Key Signing Key
the DNS root. (KSK) [RFC4033] used to sign 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
skipping to change at page 6, line 51 skipping to change at page 7, line 7
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 local As stated in Section 1, this design explicitly allows the local copy
copy of the root zone information to be available only from resolvers of the root zone information to be available only from resolvers on
on that host. This has the security property of limiting damage to that host. This has the security property of limiting damage to
clients of any local resolver that might try to rely on an altered clients of any local resolver that might try to rely on an altered
copy of the root. copy of the root.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. References 6. References
6.1. Normative References 6.1. Normative References
skipping to change at page 7, line 30 skipping to change at page 7, line 35
[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>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015,
<https://www.rfc-editor.org/info/rfc7706>.
[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>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
6.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>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[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) [RFC5936] over TCP
servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. One can from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
also get the root zone from IANA as a text file over HTTPS at One can also get the root zone from IANA as a text file over HTTPS at
<https://www.internic.net/domain/root.zone>. <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 12, line 22 skipping to change at page 12, line 27
master: "k.root-servers.net" master: "k.root-servers.net"
fallback-enabled: yes fallback-enabled: yes
for-downstream: no for-downstream: no
for-upstream: yes for-upstream: yes
zonefile: "root.zone" zonefile: "root.zone"
B.5. Example Configuration: Knot Resolver B.5. Example Configuration: Knot Resolver
Knot Resolver uses its "prefill" module to load the root zone Knot Resolver uses its "prefill" module to load the root zone
information. This is described at <https://knot- information. This is described at <https://knot-
resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc- resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html>.
7706>.
B.6. Example Configuration: Microsoft Windows Server 2012 B.6. Example Configuration: Microsoft Windows Server 2012
Windows Server 2012 contains a DNS server in the "DNS Manager" Windows Server 2012 contains a DNS server in the "DNS Manager"
component. When activated, that component acts as a recursive component. When activated, that component acts as a recursive
server. DNS Manager can also act as an authoritative server. server. DNS Manager can also act as an authoritative server.
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 set. are returned with the AA bit set.
 End of changes. 20 change blocks. 
29 lines changed or deleted 45 lines changed or added

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