draft-ietf-dnsop-7706bis-02.txt   draft-ietf-dnsop-7706bis-03.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: July 29, 2019 January 25, 2019 Expires: September 9, 2019 March 8, 2019
Running a Root Server Local to a Resolver Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-02 draft-ietf-dnsop-7706bis-03
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. Some DNS recursive resolver
operators want to prevent snooping of requests sent to DNS root operators want to prevent snooping of requests sent to DNS root
servers by third parties. Such resolvers can greatly decrease the servers by third parties. Such resolvers can greatly decrease the
round-trip time and prevent observation of requests by running a copy round-trip time and prevent observation of requests by running a copy
of the full root zone on the same server, such as on a loopback of the full root zone on the same server, such as on a loopback
address. This document shows how to start and maintain such a copy address. This document shows how to start and maintain such a copy
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 29, 2019. This Internet-Draft will expire on September 9, 2019.
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 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5
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. Using the Root Zone Server on the Same Host . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security 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
Appendix B. Example Configurations of Common Implementations . . 9 Appendix B. Example Configurations of Common Implementations . . 9
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9 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: Unbound . . . . . . . . . . . . . 11 B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11
B.4. Example Configuration: Knot Resolver . . . . . . . . . . 11 B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 11
B.5. Example Configuration: Microsoft Windows Server 2012 . . 11 B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 B.6. Example Configuration: Microsoft Windows Server 2012 . . 12
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 has a top-level domain (TLD) that is not in each queried name that has a top-level domain (TLD) that is not in
the recursive resolver's cache, the resolver must send a query to a 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 that 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 of the TLD does not exist. Research shows that the vast majority of
skipping to change at page 3, line 22 skipping to change at page 3, line 23
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. the TTL for negative answers from the root servers. (Although the
primary goal of the design is 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 these resolver to have a complete root zone locally, and to hide these
queries from outsiders. The basic idea is to create an up-to-date queries from outsiders. The basic idea is to create an up-to-date
root zone server on the same host as the recursive server, and use root zone server on the same host as the recursive server, and use
that server when the recursive resolver looks up root information. that server when the recursive resolver looks up root information.
The recursive resolver validates all responses from the root server The recursive resolver validates all responses from the root server
on the same host, just as it would all responses from a remote root on the same host, just as it would all responses from a remote root
server. server.
skipping to change at page 4, line 33 skipping to change at page 4, line 35
instance. instance.
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.
Added examples of other resolvers and updated the existing examples.
[ This section will list all the changes from RFC 7706. For this [ 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 draft, it is also the list of changes that we will make in future
versions of the daft. ] versions of the daft. ]
[ Give a clearer comparison of software that allows slaving the root
zone in the software (such as BIND or modern Unbound) versus resolver
software that requires a local slaved root zone (older Unbound). ]
[ Add a description of Knot's cache-prefilling as way to get the data
without having a local authoritative. ]
[ Add examples of other resolvers such as PowerDNS Recusor. ]
[ Add discussion of BIND slaving the root zone in the same view
instead of using different views. ]
[ Make the use cases explicit. Be clearer that a real use case is [ Make the use cases explicit. Be clearer that a real use case is
folks who are worried that root server unavailabilty due to DDoS folks who are worried that root server unavailabilty due to DDoS
against them is a reason some people would use the mechanisms here. against them is a reason some people would use the mechanisms here.
] ]
[ Describe how slaving the root zone from root zone servers does not [ Describe how slaving the root zone from root zone servers does not
fully remove the reliance on the root servers being available. ] fully remove the reliance on the root servers being available. ]
[ Refresh list of where one can get copies of the root zone. ]
[ Other new topics might go here. ] [ 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 [RFC2119].
2. Requirements 2. Requirements
skipping to change at page 9, line 11 skipping to change at page 9, line 9
To repeat the requirement from earlier in this document: if the To repeat the requirement from earlier in this document: if the
contents of the zone cannot be refreshed before the expire time, the contents of the zone cannot be refreshed before the expire time, the
server MUST return a SERVFAIL error response for all queries until server MUST return a SERVFAIL error response for all queries until
the zone can be successfully be set up again. the zone can be successfully be set up again.
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. requirements given in this document. The examples have been updated
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 recently by
testing for AXFR over TCP from each address for the known single- testing for AXFR over TCP from each address for the known single-
letter names in the root-servers.net zone. letter names in the root-servers.net zone.
B.1. Example Configuration: BIND 9.9 B.1. Example Configuration: BIND 9.12
BIND acts both as a recursive resolver and an authoritative server. BIND 9.12 acts both as a recursive resolver and an authoritative
Because of this, there is "fate-sharing" between the two servers in server. Because of this, there is "fate-sharing" between the two
the following configuration. That is, if the root server dies, it is servers in the following configuration. That is, if the root server
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
method for creating a local mirror of the root or other zones; see
Appendix B.3.
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 not set. are returned with the AA bit not set.
When slaving a zone, BIND will treat zone data differently if the When slaving a zone, BIND 9.12 will treat zone data differently if
zone is slaved into a separate view (or a separate instance of the the zone is slaved into a separate view (or a separate instance of
software) versus slaved into the same view or instance that is also the software) versus slaved into the same view or instance that is
performing the recursion. also performing the recursion.
Validation: When using separate views or separate instances, the DS Validation: When using separate views or separate instances, the DS
records in the slaved zone will be validated as the zone data is records in the slaved zone will be validated as the zone data is
accessed by the recursive server. When using the same view, this accessed by the recursive server. When using the same view, this
validation does not occur for the slaved zone. validation does not occur for the slaved zone.
Caching: When using separate views or instances, the recursive Caching: When using separate views or instances, the recursive
server will cache all of the queries for the slaved zone, just as server will cache all of the queries for the slaved zone, just as
it would using the traditional "root hints" method. Thus, as the it would using the traditional "root hints" method. Thus, as the
zone in the other view or instance is refreshed or updated, zone in the other view or instance is refreshed or updated,
skipping to change at page 10, line 12 skipping to change at page 10, line 12
all zone data in the recursive server will be updated as soon as all zone data in the recursive server will be updated as soon as
it receives its copy of the zone. it receives its copy of the zone.
view root { view root {
match-destinations { 127.12.12.12; }; match-destinations { 127.12.12.12; };
zone "." { zone "." {
type slave; type slave;
file "rootzone.db"; file "rootzone.db";
notify no; notify no;
masters { masters {
192.228.79.201; # b.root-servers.net 199.9.14.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net 192.33.4.12; # c.root-servers.net
199.7.91.13; # d.root-servers.net 199.7.91.13; # d.root-servers.net
192.5.5.241; # f.root-servers.net 192.5.5.241; # f.root-servers.net
192.112.36.4; # g.root-servers.net 192.112.36.4; # g.root-servers.net
193.0.14.129; # k.root-servers.net 193.0.14.129; # k.root-servers.net
192.0.47.132; # xfr.cjr.dns.icann.org 192.0.47.132; # xfr.cjr.dns.icann.org
192.0.32.132; # xfr.lax.dns.icann.org 192.0.32.132; # xfr.lax.dns.icann.org
2001:500:84::b; # b.root-servers.net 2001:500:200::b; # b.root-servers.net
2001:500:2::c; # c.root-servers.net 2001:500:2::c; # c.root-servers.net
2001:500:2d::d; # d.root-servers.net 2001:500:2d::d; # d.root-servers.net
2001:500:2f::f; # f.root-servers.net 2001:500:2f::f; # f.root-servers.net
2001:500:12::d0d; # g.root-servers.net 2001:500:12::d0d; # g.root-servers.net
2001:7fd::1; # k.root-servers.net 2001:7fd::1; # k.root-servers.net
2620:0:2830:202::132; # xfr.cjr.dns.icann.org 2620:0:2830:202::132; # xfr.cjr.dns.icann.org
2620:0:2d0:202::132; # xfr.lax.dns.icann.org 2620:0:2d0:202::132; # xfr.lax.dns.icann.org
}; };
}; };
}; };
skipping to change at page 11, line 7 skipping to change at page 11, line 7
}; };
}; };
B.2. Example Configuration: Unbound 1.8 B.2. Example Configuration: Unbound 1.8
Similar to BIND, Unbound starting with version 1.8 can act both as a Similar to BIND, Unbound starting with version 1.8 can act both as a
recursive resolver and an authoritative server. recursive resolver and an authoritative server.
auth-zone: auth-zone:
name: "." name: "."
master: 192.228.79.201 # b.root-servers.net master: 199.9.14.201 # b.root-servers.net
master: 192.33.4.12 # c.root-servers.net master: 192.33.4.12 # c.root-servers.net
master: 199.7.91.13 # d.root-servers.net master: 199.7.91.13 # d.root-servers.net
master: 192.5.5.241 # f.root-servers.net master: 192.5.5.241 # f.root-servers.net
master: 192.112.36.4 # g.root-servers.net master: 192.112.36.4 # g.root-servers.net
master: 193.0.14.129 # k.root-servers.net master: 193.0.14.129 # k.root-servers.net
master: 192.0.47.132 # xfr.cjr.dns.icann.org master: 192.0.47.132 # xfr.cjr.dns.icann.org
master: 192.0.32.132 # xfr.lax.dns.icann.org master: 192.0.32.132 # xfr.lax.dns.icann.org
master: 2001:500:84::b # b.root-servers.net master: 2001:500:200::b # b.root-servers.net
master: 2001:500:2::c # c.root-servers.net master: 2001:500:2::c # c.root-servers.net
master: 2001:500:2d::d # d.root-servers.net master: 2001:500:2d::d # d.root-servers.net
master: 2001:500:2f::f # f.root-servers.net master: 2001:500:2f::f # f.root-servers.net
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: Unbound B.3. Example Configuration: BIND 9.14
[ Add an example of modern Unbound, or point to the Unbound BIND 9.14 (which, at the time of publication of this document is a
documentation where it exists ] future release) can set up a local mirror of the root zone with a
small configuration option:
B.4. Example Configuration: Knot Resolver zone "." {
type mirror;
};
The simple "type mirror" configuration for the root zone works for
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
any other zone, an explicit list of primary servers needs to be
provided.
See the documentation for BIND 9.14 (when it is released) for more
detail about how to use this simplified configuration
B.4. Example Configuration: Unbound 1.9
Recent versions of Unbound have a "auth-zone" feature that allows
local mirroring of the root zone. Configuration looks like:
auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "root.zone"
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/stable/modules.html#root-on-loopback-rfc-
7706>. 7706>.
B.5. 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.
The steps to configure DNS Manager to implement the requirements in The steps to configure DNS Manager to implement the requirements in
this document are: this document are:
skipping to change at page 12, line 48 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, [[ others go here ]]. Obser, nusenu, Wouter Wijngaards, [[ others go here ]].
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. 23 change blocks. 
44 lines changed or deleted 74 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/