draft-ietf-dnsop-root-loopback-03.txt   draft-ietf-dnsop-root-loopback-04.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: February 12, 2016 ICANN Expires: March 17, 2016 ICANN
August 11, 2015 September 14, 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-03 draft-ietf-dnsop-root-loopback-04
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 February 12, 2016. This Internet-Draft will expire on March 17, 2016.
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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 7
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7
Appendix B. Example Configurations of Common Implementations . . 7 Appendix B. Example Configurations of Common Implementations . . 8
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 8 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 8
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 9 B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 9
B.3. Example Configuration: Microsoft Windows Server 2012 . . 10 B.3. Example Configuration: Microsoft Windows Server 2012 . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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:
o The system MUST be able to validate a zone with DNSSEC. o The system MUST be able to validate a zone with DNSSEC [RFC4033].
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).
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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. Anyone deploying the method
described in this document should be familiar with the operational
benefits and costs of deploying DNSSEC [RFC4033].
As stated in Section 1, 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 authoritative answers to any system other
than the recursive resolver. This has the security property of
limiting damage to any other system that might try to rely on the
copy of the root in case that copy becomes altered.
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 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].
skipping to change at page 6, line 42 skipping to change at page 7, line 5
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
8.2. Informative References 8.2. Informative References
[AggressiveNSEC] [AggressiveNSEC]
Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3",
draft-fujiwara-dnsop-nsec-aggressiveuse-00 (work in draft-fujiwara-dnsop-nsec-aggressiveuse-00 (work in
progress), 2015. 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>.
 End of changes. 8 change blocks. 
8 lines changed or deleted 22 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/