< draft-wkumari-dnsop-root-loopback-01.txt   draft-wkumari-dnsop-root-loopback-02.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational P. Hoffman Intended status: Informational P. Hoffman
Expires: May 15, 2015 VPN Consortium Expires: May 30, 2015 VPN Consortium
November 11, 2014 November 26, 2014
Decreasing Access Time to Root Servers by Running One on Loopback Decreasing Access Time to Root Servers by Running One on Loopback
draft-wkumari-dnsop-root-loopback-01 draft-wkumari-dnsop-root-loopback-02
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 resolvers can greatly times to the closest DNS root server. Such resolvers can greatly
decrease the round trip time by running a copy of the full root zone decrease the round trip time by running a copy of the full root zone
on a loopback address (such as 127.0.0.1). This document shows how on a loopback address (such as 127.0.0.1). Typically, the vast
to start and maintain such a copy of the root zone in a manner that majority of queries going to the root are for names that do not exist
is secure for the operator of the recursive resolver and does not in the root zone, and the negative answers are cached for a much
pose a threat to other users of the DNS. shorter period of time. This document shows how to start and
maintain such a copy of the root zone in a manner that is secure for
the operator of the recursive resolver and does not pose a threat to
other users of the DNS.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 15, 2015. This Internet-Draft will expire on May 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 13 skipping to change at page 2, line 16
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. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operation of the Root Zone on the Loopback Address . . . . . 3 3. Operation of the Root Zone on the Loopback Address . . . . . 4
4. Using the Root Zone Server on the Loopback Address . . . . . 4 4. Using the Root Zone Server on the Loopback Address . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 5 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 5
Appendix B. Example Configurations of Common Implementations . . 5 Appendix B. Example Configurations of Common Implementations . . 6
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 5 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 6
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 6 B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 B.3. Example Configuration: Microsoft Windows Server 2012 . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
DNS recursive resolvers have to answer all queries from their DNS recursive resolvers have to answer all queries from their
customers, even those which are for domain names that do not exist. customers, even those which are for domain names that do not exist.
For each queried name that has a top level domain (TLD) that is not For 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 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. If there is a slow path between the that the TLD does not exist. If there is a slow path between the
recursive resolver and the closest root server, getting slow recursive resolver and the closest root server, getting slow
skipping to change at page 3, line 25 skipping to change at page 3, line 29
as NSD) running on the same host. as NSD) running on the same host.
1.1. Requirements Notation 1.1. 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
In the discussion below, the term "legacy operation" means the way
that a recursive resolver acts when it is not using the mechanism
describe in this document, namely as a normal validating recursive
resolver with no other special features.
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 a zone with DNSSEC. o The system MUST be able to validate a zone with DNSSEC.
o The system MUST have an up-to-date copy of the DNS root key. o The system MUST have an up-to-date copy of the DNS root key.
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 server on one of o The system MUST be able to run an authoritative server on one of
the IPv4 loopback addresses (that is, an address in the range the IPv4 loopback addresses (that is, an address in the range
127/8). 127/8).
A corollary of the above list is that authoritative data in the root
zone used on the local authoritative server MUST be identical to the
same data in the root zone for the DNS. It is possible to change the
unsigned data (the glue records) in the copy of the root zone, but
such changes are likely to cause problems for the recursive server
that accesses the local root zone.
3. Operation of the Root Zone on the Loopback Address 3. Operation of the Root Zone on the Loopback Address
The operation of an authoritative server for the root in the system The operation of an authoritative server for the root in the system
described here can be done separately from the operation of the described here can be done separately from the operation of the
recursive resolver. recursive resolver.
The steps to set up the root zone are: The steps to set up the root zone are:
1. Retrieve a copy of the root zone. (See Appendix A for some 1. Retrieve a copy of the root zone. (See Appendix A for some
current locations of sources.) current locations of sources.)
skipping to change at page 4, line 21 skipping to change at page 4, line 32
the SOA record in root zone, as described in [RFC1035]. If the the SOA record in root zone, as described in [RFC1035]. 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.
4. Using the Root Zone Server on the Loopback Address 4. Using the Root Zone Server on the Loopback Address
A recursive resolver that wants to use a root zone server operating A recursive resolver that wants to use a root zone server operating
as described in Section 3 simply specifies the local address as the as described in Section 3 simply specifies the local address as the
place to look when it is looking for information from the root. All place to look when it is looking for information from the root. All
responses from the rootserver on localhost must be validated using responses from the root server must be validated using DNSSEC.
DNSSEC.
Note that using this configuration will cause the recursive resolver Note that using this configuration will cause the recursive resolver
to fail if the local root zone server fails. to fail if the local root zone server fails. See Appendix B for more
discussion of this for specific software.
To test the proper operation of the recursive resolver with the local
root server, use a DNS client to send a query for the SOA of the root
to the recursive server. Make sure the response that comes back does
not have the AD bit in the message header set.
5. IANA Considerations 5. IANA Considerations
This document requires no action from the IANA. This document requires no action from the IANA.
6. Security Considerations 6. 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. responses from a remote root server.
7. Acknowledgements 7. Acknowledgements
The editors fully acknowledge that this is not a new concept, and The editors fully acknowledge that this is not a new concept, and
that we have chatted with many people about this. In fact, this that we have chatted with many people about this. In fact, this
concept may already have been implemented without the knowledge of concept may already have been implemented without the knowledge of
the authors. For example, Bill Manning described something similar the authors. For example, Bill Manning described something similar
in his doctoral dissertation in 2013. in his doctoral dissertation in 2013.
Evan Hunt contributed greatly by finding some flaws in the logic in Evan Hunt contributed greatly to the logic in the requirements.
the -00 draft, and by offering a BIND configuration that works with Other significant contributors include Wouter Wijngaards, Tony Hain
the requirements. Doug Barton, and Greg Lindsay.
8. Normative References 8. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Appendix A. Current Sources of the Root Zone Appendix A. Current Sources of the Root Zone
skipping to change at page 5, line 26 skipping to change at page 5, line 38
all the DNSSEC records needed for validation. Currently, there are all the DNSSEC records needed for validation. Currently, there are
three sources of the root zone supported by ICANN: three sources of the root zone supported by ICANN:
o From ICANN via FTP at ftp://rs.internic.net/domain/root.zone o From ICANN via FTP at ftp://rs.internic.net/domain/root.zone
o From ICANN via HTTP at http://www.internic.net/domain/root.zone o From ICANN via HTTP at http://www.internic.net/domain/root.zone
o From ICANN by AXFR from DNS servers at xfr.lax.dns.icann.org and o From ICANN by AXFR from DNS servers at xfr.lax.dns.icann.org and
xfr.cjr.dns.icann.org xfr.cjr.dns.icann.org
Currently, the root can be retrieved by zone transfer from the Currently, the root can be retrieved by zone transfer (AXFR) 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 f.root-servers.net o f.root-servers.net
o g.root-servers.net o g.root-servers.net
o k.root-servers.net o k.root-servers.net
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 IPv4 and IPv6 addresses in this section were checked recently by
testing for AXFR over TCP from each address for the known single-
letter names in the root-servers.net zone.
The examples here use a loopback address of 127.12.12.12, but typical
installations will use 127.0.0.1. The different address is used in
order to emphasize that the root server does not need to be on the
device at "localhost".
B.1. Example Configuration: BIND 9.9 B.1. Example Configuration: BIND 9.9
BIND acts both as a recursive resolver and an authoritative server.
Because of this, there is "fate sharing" between the two servers in
the following configuration. That is, if the root server dies, it is
likely that all of BIND is dead.
Using this configuration, queries for information in the root zone
are returned with the AA bit not set.
When slaving a zone, BIND will treat zone data differently if it is
slaved into a separate view (or a separate instance of the software)
versus slaving the zone into the same view or instance that is also
performing the recursion.
Validation: When using separate views or separate instances, the DS
records in the slaved zone will be validated as the zone data is
accessed by the recursive server. When using the same view, this
validation does not occur for the slaved zone.
Caching: When using separate views or instances, the recursive
server will cache all of the queries for the slaved zone, just as
it would using the traditional root hints method. Thus, as the
zone in the other view or instance is refreshed or updated,
changed information will not appear in the recursive server until
the TTL of the old record times out. Currently the TTL for DS and
delegation NS records is two days. When using the same view, all
zone data in the recursive server will be updated as soon as 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 192.228.79.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net 192.33.4.12; # c.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
2001:500:84::b; # b.root-servers.net
2001:500:2f::f; # f.root-servers.net
2001:7fd::1; # k.root-servers.net
}; };
}; };
}; };
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.4 and NSD 4
# Configuration for Unbound
Unbound and NSD are separate software packages. Because of this,
there is no "fate sharing" between the two servers in the following
configurations. That is, if the root server instance (NSD) dies, the
recursive resolver instance (Unbound) will probably keep running, but
will not be able to resolve any queries for the root zone.
Therefore, the administrator of this configuration might want to
carefully monitor the NSD instance and restart it immediately if it
dies.
Using this configuration, queries for information in the root zone
are returned with the AA bit not set.
# Configuration for Unbound
server: server:
do-not-query-localhost: no do-not-query-localhost: no
stub-zone: stub-zone:
name: "." name: "."
stub-prime: no stub-prime: no
stub-addr: 127.12.12.12 stub-addr: 127.12.12.12
# Configuration for NSD # Configuration for NSD
server: server:
ip-address: 127.12.12.12 ip-address: 127.12.12.12
zone: zone:
name: "." name: "."
request-xfr: 192.228.79.201 NOKEY # b.root-servers.net request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
request-xfr: 192.33.4.12 NOKEY # c.root-servers.net request-xfr: 192.33.4.12 NOKEY # c.root-servers.net
request-xfr: 192.5.5.241 NOKEY # f.root-servers.net request-xfr: 192.5.5.241 NOKEY # f.root-servers.net
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: 2001:500:84::b NOKEY # b.root-servers.net
request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
B.3. Example Configuration: Microsoft Windows Server 2012
Windows Server 2012 contains a DNS server in the "DNS Manager"
component. When activated, that component acts as a recursive
server. DNS Manager can also act as an authoritative server.
Using this configuration, queries for information in the root zone
are returned with the AA bit set.
The steps to configure DNS Manager to implement the requirements in
this document are:
1. Launch the DNS Manager GUI. This can be done from the command
line ("dnsmgmt.msc") or from the Service Manager (the "DNS"
command in the "Tools" menu).
2. In the hierarchy under the server on which the service is
running, right-click on the "Forward Lookup Zones", and select
"New Zone". This brings up a succession of dialog boxes.
3. In the "Zone Type" dialog box, select "Secondary zone".
4. In the "Zone Name" dialog box, enter ".".
5. In the "Master DNS Servers" dialog box, enter "b.root-
servers.net". The system validates that it can do a zone
transfer from that server. (After this configuration is
completed, DNS Manager will attempt to transfer from all of the
root zone servers.)
6. In the "Completing the New Zone Wizard" dialog box, click
"Finish".
7. Verify that the DNS Manager is acting as a recursive resolver.
Right-click on the server name in the hierarch, choosing the
"Advanced" tab in the dialog box. See that "Disable recursion
(also disables forwarders)" is not selected, and that "Enable
DNSSEC validation for remote responses" is selected.
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
Email: Warren@kumari.net Email: Warren@kumari.net
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
 End of changes. 21 change blocks. 
33 lines changed or deleted 137 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/