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/ |