< draft-ietf-dnsop-root-loopback-00.txt		draft-ietf-dnsop-root-loopback-01.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: June 3, 2015 VPN Consortium		Expires: July 15, 2015 VPN Consortium
	November 30, 2014		January 11, 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-00		draft-ietf-dnsop-root-loopback-01
	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. Some DNS recursive resolver
	decrease the round trip time by running a copy of the full root zone		operators want to prevent snooping of requests sent to DNS root
	on a loopback address (such as 127.0.0.1). Typically, the vast		servers by third parties. Such resolvers can greatly decrease the
	majority of queries going to the root are for names that do not exist		round trip time and prevent observation of requests by running a copy
	in the root zone, and the negative answers are cached for a much		of the full root zone on a loopback address (such as 127.0.0.1).
	shorter period of time. This document shows how to start and		This document shows how to start and maintain such a copy of the root
	maintain such a copy of the root zone in a manner that is secure for		zone that does not pose a threat to other users of the DNS, at the
	the operator of the recursive resolver and does not pose a threat to		cost of adding some operational fragility for the operator.
	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 June 3, 2015.		This Internet-Draft will expire on July 15, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . 3
	2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3		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 . . . . . 4		4. Using the Root Zone Server on the Loopback Address . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . 5		8.1. Normative References . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . 5		8.2. Informative References . . . . . . . . . . . . . . . . . 6
	Appendix A. Current Sources of the Root Zone . . . . . . . . . . 5		Appendix A. Current Sources of the Root Zone . . . . . . . . . . 6
	Appendix B. Example Configurations of Common Implementations . . 6		Appendix B. Example Configurations of Common Implementations . . 7
	B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 6		B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 7
	B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 7		B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 8
	B.3. Example Configuration: Microsoft Windows Server 2012 . . 8		B.3. Example Configuration: Microsoft Windows Server 2012 . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	DNS recursive resolvers have to answer all queries from their		DNS recursive resolvers have to provide answers to all queries from
	customers, even those which are for domain names that do not exist.		their customers, even those which are for domain names that do not
	For each queried name that has a top level domain (TLD) that is not		exist. For each queried name that has a top level domain (TLD) that
	in the recursive resolver's cache, the resolver must send a query to		is not in the recursive resolver's cache, the resolver must send a
	a root server to get the information for that TLD, or to find out		query to a root server to get the information for that TLD, or to
	that the TLD does not exist. If there is a slow path between the		find out that the TLD does not exist. Typically, the vast majority
	recursive resolver and the closest root server, getting slow		of queries going to the root are for names that do not exist in the
	responses to these queries has a negative effect on the resolver's		root zone, and the negative answers are cached for a much shorter
			period of time. A slow path between the recursive resolver and the
			closest root server has a negative effect on the resolver's
	customers.		customers.
			Recursive resolvers currently send queries for all TLDs that are not
			in their caches to root servers, even though most of those queries
			get answers that are referrals to other servers. Malicious third
			parties might be able to observe that traffic on the network between
			the recursive resolver and one or more of the DNS roots.
	This document describes a method for the operator of a recursive		This document describes a method for the operator of a recursive
	resolver to greatly speed these queries. The basic idea is to create		resolver to greatly speed these queries and to hide them from
	an up-to-date root zone server on a loopback address on the same host		outsiders. The basic idea is to create an up-to-date root zone
	as the recursive server, and that server is used when the recursive		server on a loopback address on the same host as the recursive
	resolver uses for looking up root information. The recursive		server, and use that server when the recursive resolver looks up root
	resolver validates all responses from the root server on the loopback		information. The recursive resolver validates all responses from the
	address, just as it would all responses from a remote root server.		root server on the loopback address, just as it would all responses
			from a remote root server.
	The primary goal of this design is to provide faster negative		The primary goals of this design is to provide faster negative
	responses to stub resolver queries that contain junk queries. This		responses to stub resolver queries that contain junk queries, and to
	design will probably have little effect on getting faster positive		prevent queries and responses from being visible on the network.
	responses to stub resolver for good queries on TLDs, because the data		This design will probably have little effect on getting faster
	for those zones is usually long-lived and already in the cache of the		positive responses to stub resolver for good queries on TLDs, because
	recursive resolver; thus, getting faster positive responses is a non-		the data for those zones is usually long-lived and already in the
	goal of this design.		cache of the recursive resolver; thus, getting faster positive
			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. This prevents 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.		resolver. [[ Other people have said that they might propose a
			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
			not considered a "best practice". In fact, many people feel that it
			is an excessively risky practice because it introduces a new
			operational piece to local DNS operations where there was not one
			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
			recursive resolution system might fail in ways that are hard to
			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.
	1.1. Requirements Notation		1.1. Requirements Notation
	skipping to change at page 3, line 50 ¶		skipping to change at page 4, line 24 ¶
	(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		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		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		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		unsigned data (the glue records) in the copy of the root zone, but
	such changes are likely to cause problems for the recursive server		such changes could cause problems for the recursive server that
	that accesses the local root zone.		accesses the local root zone, and therefore any changes to the glue
			records SHOULD NOT be made.
	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.)
	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]. 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.
			In the event that refreshing the contents of the root zone fails, the
			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
			zone refreshing is broken during that time, the recursive resolver
			will have bad data for the entire TLD zone.
			An administrator using the procedure in this document SHOULD have an
			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
			process that periodically checks the SOA of the root zone from the
			local root zone and makes sure that they are changing. At the time
			that this document is published, the SOA for the root zone is the
			digital representation of the current date with a two-digit counter
			appended, and the SOA is changed every day even if the contents of
			the root zone are unchanged. For example, the SOA of the root zone
			on January 2, 2015 was 2015010201. A process can use this fact to
			create a check for the contents of the local root zone (using a
			program not specified in this document).
	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 root server must be validated using DNSSEC.		responses from the root server must be validated using 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. See Appendix B for more		to fail if the local root zone server fails. See Appendix B for more
	discussion of this for specific software.		discussion of this for specific software.
	To test the proper operation of the recursive resolver with the local		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		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		to the recursive server. Make sure the response that comes back has
	not have the AD bit in the message header set.		the AA bit in the message header set to 0.
	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
	skipping to change at page 5, line 17 ¶		skipping to change at page 6, line 11 ¶
	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.		Doug Barton, and Greg Lindsay. The authors also received many off-
			line comments about making the document clear that this was just a
			description of a way to operate a root zone on localhost, and 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.
	skipping to change at page 5, line 48 ¶		skipping to change at page 6, line 45 ¶
	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 (AXFR) from the		Currently, the root can also be retrieved by zone transfer (AXFR)
	following root server operators:		from the 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
	skipping to change at page 6, line 27 ¶		skipping to change at page 7, line 25 ¶
	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.
End of changes. 23 change blocks.
	59 lines changed or deleted		107 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/