draft-ietf-dnsop-root-loopback-01.txt   draft-ietf-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: July 15, 2015 VPN Consortium Expires: December 27, 2015 VPN Consortium
January 11, 2015 June 25, 2015
Decreasing Access Time to Root Servers by Running One on Loopback Decreasing Access Time to Root Servers by Running One on Loopback
draft-ietf-dnsop-root-loopback-01 draft-ietf-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. 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 a loopback address (such as 127.0.0.1). of the full root zone on a loopback address (such as 127.0.0.1).
This document shows how to start and maintain such a copy of the root This document shows how to start and maintain such a copy of the root
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 July 15, 2015. This Internet-Draft will expire on December 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
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. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation of the Root Zone on the Loopback Address . . . . . 4 3. Operation of the Root Zone on the Loopback Address . . . . . 4
4. Using the Root Zone Server on the Loopback Address . . . . . 5 4. Using the Root Zone Server on the Loopback Address . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 6 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7
Appendix B. Example Configurations of Common Implementations . . 7 Appendix B. Example Configurations of Common Implementations . . 7
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 7 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 8
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 8 B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 9
B.3. Example Configuration: Microsoft Windows Server 2012 . . 9 B.3. Example Configuration: Microsoft Windows Server 2012 . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 which are for domain names that do not their customers, even those which are for domain names that do not
exist. For each queried name that has a top level domain (TLD) that exist. 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 is not 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 query to a root server to get the information for that TLD, or to
find out that the TLD does not exist. Typically, the vast majority find out that the TLD does not exist. Typically, 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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
prevent queries and responses from being visible on the network. prevent queries and responses from being visible on the network.
This design will probably have little effect on getting faster This design will probably have little effect on getting faster
positive responses to stub resolver for good queries on TLDs, because positive responses to stub resolver for good queries on TLDs, because
the data for those zones is usually long-lived and already in the the data for those zones is usually long-lived and already in the
cache of the recursive resolver; thus, getting faster positive cache of the recursive resolver; thus, getting faster positive
responses is a non-goal of this design. responses is a non-goal of this design.
This design explicitly only allows the new root zone server to be run This design explicitly only allows the new root zone server to be run
on a loopback address, in order to prevent the server from serving on a loopback address, in order to prevent the server from serving
authoritative answers to any system other than the recursive authoritative answers to any system other than the recursive
resolver. [[ Other people have said that they might propose a resolver.
similar design that does not use the loopback, but instead uses a new
root zone server that only responds to queries from a very limited
number of addresses. ]]
It is important to note that this design is being described here is It is important to note that this design is being described here is
not considered a "best practice". In fact, many people feel that it not considered a "best practice". In fact, many people feel that it
is an excessively risky practice because it introduces a new is an excessively risky practice because it introduces a new
operational piece to local DNS operations where there was not one operational piece to local DNS operations where there was not one
before. The advantages listed above do not come free: if this new before. 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 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 will not need to add
much new functionality, but recursive resolver software such as much new functionality, but recursive resolver software such as
Unbound will need to be able to talk to an authoritative server (such Unbound will need to be able to talk to an authoritative server (such
as NSD) running on the same host. as NSD) running on the same host.
Because of the significant operational risks described in this
document, distributions of recursive DNS servers MUST NOT include
configuration for the design described here. It is acceptable to
point to this document, but not to indicate that this configuration
is something that should be considered without reading the entire
document.
A different approach to solving the problems discussed in this
document is described in [AggressiveNSEC].
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 order to implement the mechanism described in this document: In order to implement the mechanism described in this document:
skipping to change at page 4, line 45 skipping to change at page 4, line 51
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.)
2. Start the authoritative server with the root zone on a loopback 2. Start the authoritative server with the root zone on a loopback
address that is not in use. This would typically be 127.0.0.1, address that is not in use. This would typically be 127.0.0.1,
but if that address is in use, any address in 127/8 is but if that address is in use, any address in 127/8 is
acceptable. acceptable.
The contents of the root zone MUST be refreshed using the timers from The contents of the root zone MUST be refreshed using the timers from
the SOA record in root zone, as described in [RFC1035]. If the the SOA record in root zone, as described in [RFC1035]. This
contents of the zone cannot be refreshed before the expire time, the inherently means that the conents of the local root zone will likely
server MUST return a SERVFAIL error response for all queries until be a little behind those of the global root servers because those
the zone can be successfully be set up again. servers are updated triggered by NOTIFY messages. If the contents of
the zone cannot be refreshed before the expire time, the server MUST
return a SERVFAIL error response for all queries until the zone can
be successfully be set up again.
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; if the local root for a TLD are changed in a short period of time; if the local root
zone refreshing is broken during that time, the recursive resolver zone refreshing is broken during that time, the recursive resolver
will have bad data for the entire TLD zone. 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. One way to do this is to have a separate are being refreshed. One way to do this is to have a separate
skipping to change at page 6, line 11 skipping to change at page 6, line 24
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 a similar solution the authors. For example, Bill Manning described a similar solution
but to a very different problem (intermittent connectivity, instead but to a very different problem (intermittent connectivity, instead
of constant but slow connectivity) in his doctoral dissertation in of constant but slow connectivity) in his doctoral dissertation in
2013 [Manning2013]. 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, and Greg Lindsay. The authors also received many off- Doug Barton, Greg Lindsay, and Akira Kato. The authors also received
line comments about making the document clear that this was just a many off-line comments about making the document clear that this was
description of a way to operate a root zone on localhost, and not a just a description of a way to operate a root zone on localhost, and
recommendation to do so. not a recommendation to do so.
8. References 8. References
8.1. Normative References 8.1. 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.
8.2. Informative References 8.2. Informative References
[AggressiveNSEC]
Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3",
draft-fujiwara-dnsop-nsec-aggressiveuse-00 (work in
progress), 2015.
[Manning2013] [Manning2013]
Maning, W., "Client Based Naming", 2013, Maning, 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>.
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, 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 zone transfer (AXFR) over TCP from DNS servers at
xfr.cjr.dns.icann.org xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org
Currently, the root can also be retrieved by zone transfer (AXFR) Currently, the root can also be retrieved by AXFR over TCP from the
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
It is crucial to note that none of the above services are guaranteed
to be available. It is possible that ICANN or some of the root
server operators will turn off the AXFR capability on the servers
listed above. Using AXFR over TCP to addresses that are likely to be
anycast (as the the ones above are) may conceivably have transfer
problems due to anycast, but current practice shows that to be
unlikely.
To repeat the requirement from earlier in this document: if the
contents of the zone cannot be refreshed before the expire time, the
server MUST return a SERVFAIL error response for all queries until
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 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.
The examples here use a loopback address of 127.12.12.12, but typical 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 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 order to emphasize that the root server does not need to be on the
device at "localhost". device at "localhost".
[[ We were told that PowerDNS will soon be able to be configured to
meet the requirements in this document. We'll add that configuration
when/if someone contributes it. ]]
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. BIND acts both as a recursive resolver and an authoritative server.
Because of this, there is "fate sharing" between the two servers in Because of this, there is "fate sharing" between the two servers in
the following configuration. That is, if the root server dies, it is the following configuration. That is, if the root server dies, it is
likely that all of BIND is dead. likely that all of BIND is dead.
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.
skipping to change at page 8, line 23 skipping to change at page 9, line 17
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
192.0.47.132; # xfr.cjr.dns.icann.org
192.0.32.132; # xfr.lax.dns.icann.org
2001:500:84::b; # b.root-servers.net 2001:500:84::b; # b.root-servers.net
2001:500:2f::f; # f.root-servers.net 2001:500:2f::f; # f.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:2d0:202::132; # xfr.lax.dns.icann.org
}; };
}; };
}; };
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;
skipping to change at page 9, line 26 skipping to change at page 10, line 23
# 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: 192.0.47.132 NOKEY # xfr.cjr.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:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
B.3. Example Configuration: Microsoft Windows Server 2012 B.3. 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. 21 change blocks. 
32 lines changed or deleted 65 lines changed or added

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