draft-ietf-dnsop-7706bis-11.txt		draft-ietf-dnsop-7706bis-12.txt
	Network Working Group W. Kumari		Network Working Group W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Obsoletes: 7706 (if approved) P. Hoffman		Obsoletes: 7706 (if approved) P. Hoffman
	Intended status: Informational ICANN		Intended status: Informational ICANN
	Expires: September 13, 2020 March 12, 2020		Expires: September 14, 2020 March 13, 2020
	Running a Root Server Local to a Resolver		Running a Root Server Local to a Resolver
	draft-ietf-dnsop-7706bis-11		draft-ietf-dnsop-7706bis-12
	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; those resolvers may have		times to the closest DNS root server; those resolvers may have
	difficulty getting responses from the root servers, such as during a		difficulty getting responses from the root servers, such as during a
	network attack. Some DNS recursive resolver operators want to		network attack. Some DNS recursive resolver operators want to
	prevent snooping by third parties of requests sent to DNS root		prevent snooping by third parties of requests sent to DNS root
	servers. Such resolvers can greatly decrease the round-trip time and		servers. In both cases, resolvers can greatly decrease the round-
	prevent observation of requests by serving a copy of the full root		trip time and prevent observation of requests by serving a copy of
	zone on the same server, such as on a loopback address or in the		the full root zone on the same server, such as on a loopback address
	resolver software. This document shows how to start and maintain		or in the resolver software. This document shows how to start and
	such a copy of the root zone that does not cause problems for other		maintain such a copy of the root zone that does not cause problems
	users of the DNS, at the cost of adding some operational fragility		for other users of the DNS, at the cost of adding some operational
	for the operator.		fragility for the operator.
	This document obsoletes RFC 7706.		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
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 13, 2020.		This Internet-Draft will expire on September 14, 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 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	the SOA record in the root zone, as described in [RFC1035]. This		the SOA record in the root zone, as described in [RFC1035]. This
	inherently means that the contents of the local root zone will likely		inherently means that the contents of the local root zone will likely
	be a little behind those of the global root servers because those		be a little behind those of the global root servers because those
	servers are updated when triggered by NOTIFY messages.		servers are updated when triggered by NOTIFY messages.
	There is a risk that a system using a local authoritative server for		There is a risk that a system using a local authoritative server for
	the root zone cannot refresh the contents of the root zone before the		the root zone cannot refresh the contents of the root zone before the
	expire time in the SOA. A system using a local authoritative server		expire time in the SOA. A system using a local authoritative server
	for the root zone MUST NOT serve stale data for the root zone. To		for the root zone MUST NOT serve stale data for the root zone. To
	mitigate the risk that stale data is served, the local root server		mitigate the risk that stale data is served, the local root server
	MUST immediately switch to using non-local root servers.		MUST immediately switch to using non-local root servers when it
			detects that it would be serving state data.
	In a resolver that is using an internal service for the root zone, if		In a resolver that is using an internal service for the root zone, if
	the contents of the root zone cannot be refreshed before the expire		the contents of the root zone cannot be refreshed before the expire
	time in the SOA, the resolver MUST immediately switch to using non-		time in the SOA, the resolver MUST immediately switch to using non-
	local root servers.		local root servers.
	In the event that refreshing the contents of the root zone fails, the		In the event that refreshing the contents of the root zone fails, the
	results can be disastrous. For example, sometimes all the NS records		results can be disastrous. For example, sometimes all the NS records
	for a TLD are changed in a short period of time (such as 2 days); if		for a TLD are changed in a short period of time (such as 2 days); if
	the refreshing of the local root zone is broken during that time, the		the refreshing of the local root zone is broken during that time, the
	skipping to change at page 7, line 7 ¶		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 allows the local copy		As stated in Section 1, this design explicitly requires the local
	of the root zone information to be available only from resolvers on		copy of the root zone information to be available only from resolvers
	that host. This has the security property of limiting damage to		on 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
End of changes. 6 change blocks.
	14 lines changed or deleted		15 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/