draft-ietf-dnsop-7706bis-00.txt   draft-ietf-dnsop-7706bis-01.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 10, 2019 August 9, 2018 Expires: April 25, 2019 October 22, 2018
Decreasing Access Time to Root Servers by Running One On The Same Server Decreasing Access Time to Root Servers by Running One On The Same Server
draft-ietf-dnsop-7706bis-00 draft-ietf-dnsop-7706bis-01
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 February 10, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 39 skipping to change at page 2, line 39
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 . . . . . . . . . 7
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.9 . . . . . . . . . . . . . 9
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10
B.3. Example Configuration: Microsoft Windows Server 2012 . . 11 B.3. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10
B.4. Example Configuration: Microsoft Windows Server 2012 . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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
skipping to change at page 3, line 50 skipping to change at page 3, line 51
controversial. There is not consensus on whether this is a "best controversial. There is not consensus on whether this is a "best
practice". In fact, many people feel that it is an excessively risky practice". In fact, many people feel that it is an excessively risky
practice because it introduces a new operational piece to local DNS practice because it introduces a new operational piece to local DNS
operations where there was not one before. The advantages listed operations where there was not one before. The advantages listed
above do not come free: if this new system does not work correctly, above do not come free: if this new system does not work correctly,
users can get bad data, or the entire recursive resolution system users can get bad data, or the entire recursive resolution system
might fail in ways that are hard to diagnose. might fail in ways that are hard to diagnose.
This design requires the addition of authoritative name server This design requires the addition of authoritative name server
software running on the same machine as the recursive resolver. software running on the same machine as the recursive resolver.
Thus, recursive resolver software such as BIND will not need to add Thus, recursive resolver software such as BIND or modern versions of
much new functionality, but recursive resolver software such as Unbound do not need to add new functionality, but other recursive
Unbound will need to be able to talk to an authoritative server (such resolver software might need to be able to talk to an authoritative
as NSD) running on the same host. However, more recursive resolver server running on the same host. More recursive resolver software
software might add the capabilities described in this document in th are expected add the capabilities described in this document in th
future. future.
A different approach to solving the problems discussed in this A different approach to solving the problems discussed in this
document is described in [RFC8198]. document is described in [RFC8198].
1.1. Updates from RFC 7706 1.1. Updates from RFC 7706
RFC 7706 explicitly required that the root server instance be run on RFC 7706 explicitly required that the 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
skipping to change at page 4, line 35 skipping to change at page 4, line 36
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.
[ 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 [ Give a clearer comparison of software that allows slaving the root
zone in the software (such as BIND) versus resolver software that zone in the software (such as BIND or modern Unbound) versus resolver
requires a local slaved root zone (Unbound). ] 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 Knot Resolver and PowerDNS [ Add examples of other resolvers such as Knot Resolver and PowerDNS
Recusor, and maybe Windows Server. ] Recusor, and maybe Windows Server. ]
[ Add discussion of BIND slaving the root zone in the same view [ Add discussion of BIND slaving the root zone in the same view
instead of using different views. ] 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.
skipping to change at page 10, line 38 skipping to change at page 10, line 38
view recursive { view recursive {
dnssec-validation auto; dnssec-validation auto;
allow-recursion { any; }; allow-recursion { any; };
recursion yes; recursion yes;
zone "." { zone "." {
type static-stub; type static-stub;
server-addresses { 127.12.12.12; }; server-addresses { 127.12.12.12; };
}; };
}; };
B.2. Example Configuration: Unbound 1.4 and NSD 4 B.2. Example Configuration: Unbound 1.8
[ Add a description of Unbound 1.8's "auth-zone" configuration ]
B.3. Example Configuration: Unbound 1.4 and NSD 4
[ Do we still want this section? If so, maybe use Know without
cache-prefilling. ]]
Unbound and NSD are separate software packages. Because of this, Unbound and NSD are separate software packages. Because of this,
there is no "fate-sharing" between the two servers in the following there is no "fate-sharing" between the two servers in the following
configurations. That is, if the root server instance (NSD) dies, the configurations. That is, if the root server instance (NSD) dies, the
recursive resolver instance (Unbound) will probably keep running but recursive resolver instance (Unbound) will probably keep running but
will not be able to resolve any queries for the root zone. will not be able to resolve any queries for the root zone.
Therefore, the administrator of this configuration might want to Therefore, the administrator of this configuration might want to
carefully monitor the NSD instance and restart it immediately if it carefully monitor the NSD instance and restart it immediately if it
dies. dies.
skipping to change at page 11, line 31 skipping to change at page 11, line 36
request-xfr: 192.112.36.4 NOKEY # g.root-servers.net request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
request-xfr: 193.0.14.129 NOKEY # k.root-servers.net request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
request-xfr: 2001:500:84::b NOKEY # b.root-servers.net request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
B.3. Example Configuration: Microsoft Windows Server 2012 B.4. 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:
 End of changes. 8 change blocks. 
14 lines changed or deleted 25 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/