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/