< draft-ietf-dnsop-7706bis-03.txt		draft-ietf-dnsop-7706bis-04.txt >
	Network Working Group W. Kumari		Network Working Group W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Updates: 7706 (if approved) P. Hoffman		Updates: 7706 (if approved) P. Hoffman
	Intended status: Informational ICANN		Intended status: Informational ICANN
	Expires: September 9, 2019 March 8, 2019		Expires: January 6, 2020 July 5, 2019
	Running a Root Server Local to a Resolver		Running a Root Server Local to a Resolver
	draft-ietf-dnsop-7706bis-03		draft-ietf-dnsop-7706bis-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 the same server, such as on a loopback		of the full root zone on the same server, such as on a loopback
	address. This document shows how to start and maintain such a copy		address. This document shows how to start and maintain such a copy
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 September 9, 2019.		This Internet-Draft will expire on January 6, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4		1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4
	1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5		1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5
	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. Using the Root Zone Server on the Same Host . . . . . . . . . 6		4. Using the Root Zone Server on the Same Host . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . . 8		6.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8		Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
			A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 9
	Appendix B. Example Configurations of Common Implementations . . 9		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 . . . . . . . . . . . . 12
	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 . . . . . . . . . . 13
	B.6. Example Configuration: Microsoft Windows Server 2012 . . 12		B.6. Example Configuration: Microsoft Windows Server 2012 . . 13
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	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 has a top-level domain (TLD) that is not in		each queried name that has a top-level domain (TLD) that is not in
	the recursive resolver's cache, the resolver must send a query to a		the recursive resolver's cache, the resolver must send a query to a
	root server to get the information for that TLD, or to find out that		root server to get the information for that TLD, or to find out that
	the TLD does not exist. Research shows that the vast majority of		the TLD does not exist. Research shows that the vast majority of
	queries going to the root are for names that do not exist in the root		queries going to the root are for names that do not exist in the root
	skipping to change at page 8, line 20 ¶		skipping to change at page 8, line 25 ¶
	[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) over TCP from DNS
	servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.		servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. One can
			also get the root zone from ICANN as a text file over HTTP (not
			HTTPS) at <http://http.l.root-servers.org/root.txt>.
	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 9, line 5 ¶		skipping to change at page 9, line 10 ¶
	listed above. Using AXFR over TCP to addresses that are likely to be		listed above. Using AXFR over TCP to addresses that are likely to be
	anycast (as the ones above are) may conceivably have transfer		anycast (as the ones above are) may conceivably have transfer
	problems due to anycast, but current practice shows that to be		problems due to anycast, but current practice shows that to be
	unlikely.		unlikely.
	To repeat the requirement from earlier in this document: if the		To repeat the requirement from earlier in this document: 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.
			A.1. Root Zone Services
			At the time that this document is published, there is one root zone
			service that is active, and one that has been announced as in the
			planning stages. This section describes all known active services.
			LocalRoot (<https://localroot.isi.edu/>) is an experimental service
			that embodies many of the ideas in this document. It distributes the
			root zone by AXFR, and also offers DNS NOTIFY messages when the
			LocalRoot system sees that the root zone has changed.
	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. The examples have been updated		requirements given in this document. The examples have been updated
	since the publication of RFC 7706.		since the publication of RFC 7706.
	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.
End of changes. 9 change blocks.
	13 lines changed or deleted		27 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/