draft-ietf-dnsop-7706bis-07.txt		draft-ietf-dnsop-7706bis-08.txt
	Network Working Group W. Kumari		Network Working Group W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Updates: 7706 (if approved) P. Hoffman		Obsoletes: 7706 (if approved) P. Hoffman
	Intended status: Informational ICANN		Intended status: Informational ICANN
	Expires: July 15, 2020 January 12, 2020		Expires: September 2, 2020 March 1, 2020
	Running a Root Server Local to a Resolver		Running a Root Server Local to a Resolver
	draft-ietf-dnsop-7706bis-07		draft-ietf-dnsop-7706bis-08
	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 as during a network attack.		times to the closest DNS root server such as during a network attack.
	Some DNS recursive resolver operators want to prevent snooping by		Some DNS recursive resolver operators want to prevent snooping by
	third parties of requests sent to DNS root servers. Such resolvers		third parties of requests sent to DNS root servers. Such resolvers
	can greatly decrease the round-trip time and prevent observation of		can greatly decrease the round-trip time and prevent observation of
	requests by serving a copy of the full root zone on the same server,		requests by serving a copy of the full root zone on the same server,
	such as on a loopback address or in the resolver software. This		such as on a loopback address or in the resolver software. This
	document shows how to start and maintain such a copy of the root zone		document shows how to start and maintain such a copy of the root zone
	that does not cause problems for other users of the DNS, at the cost		that does not cause problems for other users of the DNS, at the cost
	of adding some operational fragility for the operator.		of adding some operational fragility for the operator.
			This document obsoletes RFC 7706.
	[ This document is being collaborated on in Github at:		[ This document is being collaborated on in Github at:
	https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent		https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent
	version of the document, open issues, and so on should all be		version of the document, open issues, and so on should all be
	available there. The authors gratefully accept pull requests. ]		available there. The authors gratefully accept pull requests. ]
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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, 2020.		This Internet-Draft will expire on September 2, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 31 ¶		skipping to change at page 2, line 31 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4		1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4
	1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4		1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
	2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Operation of the Root Zone on the Local Server . . . . . . . 5		3. Operation of the Root Zone on the Local Server . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . . 7		6.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7		Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
	A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 8		A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 9
	Appendix B. Example Configurations of Common Implementations . . 8		Appendix B. Example Configurations of Common Implementations . . 9
	B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9		B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9
	B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10		B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 11
	B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11		B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 11
	B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 11		B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 12
	B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12		B.5. Example Configuration: Knot Resolver . . . . . . . . . . 12
	B.6. Example Configuration: Microsoft Windows Server 2012 . . 12		B.6. Example Configuration: Microsoft Windows Server 2012 . . 12
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	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 for domain names that do not exist. For		their customers, even those for domain names that do not exist. For
	each queried name that is within a top-level domain (TLD) that is not		each queried name that is within a top-level domain (TLD) that is not
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	the TTL for negative answers from the root servers. (Although the		the TTL for negative answers from the root servers. (Although the
	primary goal of the design is for serving the root zone, the method		primary goal of the design is for serving the root zone, the method
	can be used for any zone.)		can be used for any zone.)
	This document describes a method for the operator of a recursive		This document describes a method for the operator of a recursive
	resolver to have a complete root zone locally, and to hide queries		resolver to have a complete root zone locally, and to hide queries
	for the root zone from outsiders. The basic idea is to create an up-		for the root zone from outsiders. The basic idea is to create an up-
	to-date root zone service on the same host as the recursive server,		to-date root zone service on the same host as the recursive server,
	and use that service when the recursive resolver looks up root		and use that service when the recursive resolver looks up root
	information. The recursive resolver validates all responses from the		information. The recursive resolver validates all responses from the
	root service on the same host, just as it would all responses from a		root service on the same host, just as it would all validate
	remote root server.		responses from a remote root server.
	This design explicitly only allows the new root zone service to be		This design explicitly only allows the new root zone service to be
	run on the same server as the recursive resolver, in order to prevent		run on the same server as the recursive resolver, in order to prevent
	the server from serving authoritative answers to any other system.		the server from serving authoritative answers to any other system.
	Specifically, the root service on the local system MUST be configured		Specifically, the root service on the local system MUST be configured
	to only answer queries from resolvers on the same host, and MUST NOT		to only answer queries from resolvers on the same host, and MUST NOT
	answer queries from any other resolver.		answer queries from any other resolver.
	At the time that RFC 7706 was published, it was considered		At the time that RFC 7706 [RFC7706] was published, it was considered
	controversial: there was not consensus on whether this was a "best		controversial: there was not consensus on whether this was a "best
	practice". In fact, many people felt that it is an excessively risky		practice". In fact, many people felt that it is an excessively risky
	practice because it introduced a new operational piece to local DNS		practice because it introduced a new operational piece to local DNS
	operations where there was not one before. Since then, the DNS		operations where there was not one before. Since then, the DNS
	operational community has largely shifted to believing that local		operational community has largely shifted to believing that local
	serving of the root zone for an individual resolver is a reasonable		serving of the root zone for an individual resolver is a reasonable
	practice. The advantages listed above do not come free: if this new		practice. 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.
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	authoritative server for some zones, but other recursive resolver		authoritative server for some zones, but other recursive resolver
	software might need to be able to talk to an authoritative server		software might need to be able to talk to an authoritative server
	running on the same host. Some resolver software supports being both		running on the same host. Some resolver software supports being both
	an authoritative server and a resolver but separated by logical		an authoritative server and a resolver but separated by logical
	"views", allowing a local root to be implemented within a single		"views", allowing a local root to be implemented within a single
	process; examples of this can be seen in Appendix B.		process; examples of this can be seen in Appendix B.
	A different approach to solving some of the problems discussed in		A different approach to solving some of the problems discussed in
	this document is described in [RFC8198].		this document is described in [RFC8198].
			Readers are expected to be familiar with [RFC8499].
	1.1. Updates from RFC 7706		1.1. Updates from RFC 7706
	RFC 7706 explicitly required that a root server instance be run on		RFC 7706 explicitly required that a root server instance be run on
	the loopback interface of the host running the validating resolver.		the loopback interface of the host running the validating resolver.
	However, RFC 7706 also had examples of how to set up common software		However, RFC 7706 also had examples of how to set up common software
	that did not use the loopback interface. This document loosens the		that did not use the loopback interface. This document loosens the
	restriction on using the loopback interface and in fact allows the		restriction on using the loopback interface and in fact allows the
	use of a local service, not necessarily an authoritative server.		use of a local service, not necessarily an authoritative server.
	However, the document keeps the requirement that only systems running		However, the document keeps the requirement that only systems running
	on that single host be able to query that authoritatve root server or		on that single host be able to query that authoritative root server
	service.		or service.
	This document changes the use cases for running a local root service		This document changes the use cases for running a local root service
	to be more consistent with the reasons operators said they had for		to be more consistent with the reasons operators said they had for
	using RFC 7706.		using RFC 7706.
	Removed the prohibition on distribution of recursive DNS servers		Removed the prohibition on distribution of recursive DNS servers
	including configurations for this design because some already do, and		including configurations for this design because some already do, and
	others have expressed an interest in doing so.		others have expressed an interest in doing so.
	Added the idea that a recursive resolver using this design might		Added the idea that a recursive resolver using this design might
	switch to using the normal (remote) root servers if the local root		switch to using the normal (remote) root servers if the local root
	server fails.		server fails.
	Refreshed the list of where one can get copies of the root zone.		Refreshed the list of where one can get copies of the root zone.
	Added examples of other resolvers and updated the existing examples.		Added examples of other resolvers and updated the existing examples.
	1.2. Requirements Notation		1.2. 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", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in BCP 14 [RFC2119]		"OPTIONAL" in this document are to be interpreted as described in BCP
	[RFC8174] when, and only when, they appear in all capitals, as shown		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	here.		capitals, as shown here.
	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 every signed record in a zone		o The system MUST be able to validate every signed record in a zone
	with DNSSEC [RFC4033].		with DNSSEC [RFC4033].
	o The system MUST have an up-to-date copy of the KSK used to sign		o The system MUST have an up-to-date copy of the Key Signing Key
	the DNS root.		(KSK) [RFC4033] used to sign the DNS root.
	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 service for the		o The system MUST be able to run an authoritative service for the
	root zone on the same host. The authoritative root service MUST		root zone on the same host. The authoritative root service MUST
	only respond to queries from the same host. One way to assure not		only respond to queries from the same host. One way to assure not
	responding to queries from other hosts is to run an authoritative		responding to queries from other hosts is to run an authoritative
	server for the root that responds only on one of the loopback		server for the root that responds only on one of the loopback
	addresses (that is, an address in the range 127/8 for IPv4 or ::1		addresses (that is, an address in the range 127/8 for IPv4 or ::1
	skipping to change at page 6, line 51 ¶		skipping to change at page 7, line 7 ¶
	4. Security Considerations		4. 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. Anyone deploying the method		responses from a remote root server. Anyone deploying the method
	described in this document should be familiar with the operational		described in this document should be familiar with the operational
	benefits and costs of deploying DNSSEC [RFC4033].		benefits and costs of deploying DNSSEC [RFC4033].
	As stated in Section 1, this design explicitly only allows the local		As stated in Section 1, this design explicitly allows the local copy
	copy of the root zone information to be available only from resolvers		of the root zone information to be available only from resolvers on
	on that host. This has the security property of limiting damage to		that host. This has the security property of limiting damage to
	clients of any local resolver that might try to rely on an altered		clients of any local resolver that might try to rely on an altered
	copy of the root.		copy of the root.
	5. IANA Considerations		5. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 35 ¶
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, DOI 10.17487/RFC4033, March 2005,		RFC 4033, DOI 10.17487/RFC4033, March 2005,
	<https://www.rfc-editor.org/info/rfc4033>.		<https://www.rfc-editor.org/info/rfc4033>.
			[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
			Servers by Running One on Loopback", RFC 7706,
			DOI 10.17487/RFC7706, November 2015,
			<https://www.rfc-editor.org/info/rfc7706>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
			Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
			January 2019, <https://www.rfc-editor.org/info/rfc8499>.
	6.2. Informative References		6.2. Informative References
	[Manning2013]		[Manning2013]
	Manning, W., "Client Based Naming", 2013,		Manning, 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>.
			[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
			(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
			<https://www.rfc-editor.org/info/rfc5936>.
	[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of		[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
	DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,		DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
	July 2017, <https://www.rfc-editor.org/info/rfc8198>.		July 2017, <https://www.rfc-editor.org/info/rfc8198>.
	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, one can get		all the DNSSEC records needed for validation. Currently, one can get
	the root zone from ICANN by zone transfer (AXFR) over TCP from DNS		the root zone from ICANN by zone transfer (AXFR) [RFC5936] over TCP
	servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. One can		from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
	also get the root zone from IANA as a text file over HTTPS at		One can also get the root zone from IANA as a text file over HTTPS at
	<https://www.internic.net/domain/root.zone>.		<https://www.internic.net/domain/root.zone>.
	Currently, the root can also be retrieved by AXFR over TCP from the		Currently, the root can also be retrieved by AXFR over TCP 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 d.root-servers.net		o d.root-servers.net
	skipping to change at page 12, line 22 ¶		skipping to change at page 12, line 27 ¶
	master: "k.root-servers.net"		master: "k.root-servers.net"
	fallback-enabled: yes		fallback-enabled: yes
	for-downstream: no		for-downstream: no
	for-upstream: yes		for-upstream: yes
	zonefile: "root.zone"		zonefile: "root.zone"
	B.5. Example Configuration: Knot Resolver		B.5. Example Configuration: Knot Resolver
	Knot Resolver uses its "prefill" module to load the root zone		Knot Resolver uses its "prefill" module to load the root zone
	information. This is described at <https://knot-		information. This is described at <https://knot-
	resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-		resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html>.
	7706>.
	B.6. Example Configuration: Microsoft Windows Server 2012		B.6. 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. 20 change blocks.
	29 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/