draft-ietf-dnsop-7706bis-00.txt		draft-ietf-dnsop-7706bis-01.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: February 10, 2019 August 9, 2018		Expires: April 25, 2019 October 22, 2018
	Decreasing Access Time to Root Servers by Running One On The Same Server		Decreasing Access Time to Root Servers by Running One On The Same Server
	draft-ietf-dnsop-7706bis-00		draft-ietf-dnsop-7706bis-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. 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 February 10, 2019.		This Internet-Draft will expire on April 25, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 39 ¶		skipping to change at page 2, line 39 ¶
	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 . . . . . . . . . 7		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
	Appendix B. Example Configurations of Common Implementations . . 9		Appendix B. Example Configurations of Common Implementations . . 9
	B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9		B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9
	B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10		B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10
	B.3. Example Configuration: Microsoft Windows Server 2012 . . 11		B.3. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10
			B.4. Example Configuration: Microsoft Windows Server 2012 . . 11
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	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
	skipping to change at page 3, line 50 ¶		skipping to change at page 3, line 51 ¶
	controversial. There is not consensus on whether this is a "best		controversial. There is not consensus on whether this is a "best
	practice". In fact, many people feel that it is an excessively risky		practice". In fact, many people feel that it is an excessively risky
	practice because it introduces a new operational piece to local DNS		practice because it introduces a new operational piece to local DNS
	operations where there was not one before. The advantages listed		operations where there was not one before. The advantages listed
	above do not come free: if this new system does not work correctly,		above do not come free: if this new system does not work correctly,
	users can get bad data, or the entire recursive resolution system		users can get bad data, or the entire recursive resolution system
	might fail in ways that are hard to diagnose.		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 or modern versions of
	much new functionality, but recursive resolver software such as		Unbound do not need to add new functionality, but other recursive
	Unbound will need to be able to talk to an authoritative server (such		resolver software might need to be able to talk to an authoritative
	as NSD) running on the same host. However, more recursive resolver		server running on the same host. More recursive resolver software
	software might add the capabilities described in this document in th		are expected add the capabilities described in this document in th
	future.		future.
	A different approach to solving the problems discussed in this		A different approach to solving the problems discussed in this
	document is described in [RFC8198].		document is described in [RFC8198].
	1.1. Updates from RFC 7706		1.1. Updates from RFC 7706
	RFC 7706 explicitly required that the root server instance be run on		RFC 7706 explicitly required that the 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
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 36 ¶
	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.
	[ This section will list all the changes from RFC 7706. For this		[ This section will list all the changes from RFC 7706. For this
	draft, it is also the list of changes that we will make in future		draft, it is also the list of changes that we will make in future
	versions of the daft. ]		versions of the daft. ]
	[ Give a clearer comparison of software that allows slaving the root		[ Give a clearer comparison of software that allows slaving the root
	zone in the software (such as BIND) versus resolver software that		zone in the software (such as BIND or modern Unbound) versus resolver
	requires a local slaved root zone (Unbound). ]		software that requires a local slaved root zone (older Unbound). ]
			[ Add a description of Knot's cache-prefilling as way to get the data
			without having a local authoritative. ]
	[ Add examples of other resolvers such as Knot Resolver and PowerDNS		[ Add examples of other resolvers such as Knot Resolver and PowerDNS
	Recusor, and maybe Windows Server. ]		Recusor, and maybe Windows Server. ]
	[ Add discussion of BIND slaving the root zone in the same view		[ Add discussion of BIND slaving the root zone in the same view
	instead of using different views. ]		instead of using different views. ]
	[ Make the use cases explicit. Be clearer that a real use case is		[ Make the use cases explicit. Be clearer that a real use case is
	folks who are worried that root server unavailabilty due to DDoS		folks who are worried that root server unavailabilty due to DDoS
	against them is a reason some people would use the mechanisms here.		against them is a reason some people would use the mechanisms here.
	skipping to change at page 10, line 38 ¶		skipping to change at page 10, line 38 ¶
	view recursive {		view recursive {
	dnssec-validation auto;		dnssec-validation auto;
	allow-recursion { any; };		allow-recursion { any; };
	recursion yes;		recursion yes;
	zone "." {		zone "." {
	type static-stub;		type static-stub;
	server-addresses { 127.12.12.12; };		server-addresses { 127.12.12.12; };
	};		};
	};		};
	B.2. Example Configuration: Unbound 1.4 and NSD 4		B.2. Example Configuration: Unbound 1.8
			[ Add a description of Unbound 1.8's "auth-zone" configuration ]
			B.3. Example Configuration: Unbound 1.4 and NSD 4
			[ Do we still want this section? If so, maybe use Know without
			cache-prefilling. ]]
	Unbound and NSD are separate software packages. Because of this,		Unbound and NSD are separate software packages. Because of this,
	there is no "fate-sharing" between the two servers in the following		there is no "fate-sharing" between the two servers in the following
	configurations. That is, if the root server instance (NSD) dies, the		configurations. That is, if the root server instance (NSD) dies, the
	recursive resolver instance (Unbound) will probably keep running but		recursive resolver instance (Unbound) will probably keep running but
	will not be able to resolve any queries for the root zone.		will not be able to resolve any queries for the root zone.
	Therefore, the administrator of this configuration might want to		Therefore, the administrator of this configuration might want to
	carefully monitor the NSD instance and restart it immediately if it		carefully monitor the NSD instance and restart it immediately if it
	dies.		dies.
	skipping to change at page 11, line 31 ¶		skipping to change at page 11, line 36 ¶
	request-xfr: 192.112.36.4 NOKEY # g.root-servers.net		request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
	request-xfr: 193.0.14.129 NOKEY # k.root-servers.net		request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
	request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org		request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
	request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org		request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
	request-xfr: 2001:500:84::b NOKEY # b.root-servers.net		request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
	request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net		request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
	request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net		request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
	request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org		request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
	request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org		request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
	B.3. Example Configuration: Microsoft Windows Server 2012		B.4. 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.
	The steps to configure DNS Manager to implement the requirements in		The steps to configure DNS Manager to implement the requirements in
	this document are:		this document are:
End of changes. 8 change blocks.
	14 lines changed or deleted		25 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/