draft-fujiwara-dnsop-resolver-update-00.txt		draft-fujiwara-dnsop-resolver-update.txt
	Network Working Group K. Fujiwara		Network Working Group K. Fujiwara
	Internet-Draft JPRS		Internet-Draft JPRS
	Updates: 1034, 2181 (if approved) November 01, 2016		Intended status: Informational 19 March 2025
	Intended status: Standards Track		Expires: 20 September 2025
	Expires: May 5, 2017
	Updating Resolver Algorithm		Another Resolver Algorithm
	draft-fujiwara-dnsop-resolver-update-00		draft-fujiwara-dnsop-resolver-update-01
	Abstract		Abstract
	Parent side NS RRSet and glue records are all information to access		NS RRSet mismatch between parent side and child side makes name
	servers for child zone. However, they may be overwritten by child		resolution unstable. DNS specification defines parent side NS RRSet
	zone data (zone apex NS RRSet and other A/AAAA RRSets). The		and glue records are all information to access servers for child
	overwrite makes name resolution unstable and induces vulnerabilities.		zone. However, they may be overwritten by child zone data (zone apex
			NS RRSet and authoritative A/AAAA RRSets). The overwrite makes name
			resolution unstable and induces some vulnerabilities. RFC 2181
	RFC 2181 section 5.4.1 specifies trustworthiness of DNS data. And it		section 5.4.1 specifies trustworthiness order of DNS data. And it is
	is deemed that that all cached data (authoritative data, non-		deemed that that all cached data (authoritative data, non-
	authoritative data, referrals and glue records) are merged into one.		authoritative data, referrals and glue records) are merged into one.
	Resolvers may answer non-authoritative data, referrals and glue		Resolvers might answer non-authoritative data, referrals and glue
	records that should not be returned. This document proposes updating		records that should not be returned. This document proposes another
	resolver algorithm that separates the cache to "authoritative data		resolver algorithm that separates cached data into "authoritative
	cache" and "delegation cache". The former is used to answer stub		data" and "delegation data". The former is used to answer stub
	resolvers, and the latter is used to iterate zones.		resolvers, and the latter is used to iterate zones.
	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 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 May 5, 2017.		This Internet-Draft will expire on 20 September 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2025 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/
	(http://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology{#terminology} . . . . . . . . . . . . . . . . . . 3
	3. Traditional resolver algorithm . . . . . . . . . . . . . . . 3		3. Traditional resolver algorithm . . . . . . . . . . . . . . . 3
	3.1. Importance of parent side NS RRSet . . . . . . . . . . . 3		3.1. Importance of parent side NS RRSet . . . . . . . . . . . 3
	3.2. Recommendation of resolver's answer . . . . . . . . . . . 4		3.2. Recommendation of resolver's answer . . . . . . . . . . . 4
	3.3. Traditional resolver algorithm . . . . . . . . . . . . . 5		3.3. Traditional resolver algorithm . . . . . . . . . . . . . 5
	4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5		4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
	5. Updating of Resolver Algorithm . . . . . . . . . . . . . . . 6		5. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Recommendations to resolvers . . . . . . . . . . . . . . 6		5.1. Recommendations to resolvers . . . . . . . . . . . . . . 6
	5.2. Update to resolver algorithm . . . . . . . . . . . . . . 6		5.2. Another resolver algorithm . . . . . . . . . . . . . . . 7
	5.3. Characteristics of the update . . . . . . . . . . . . . . 7		5.3. Characteristics of the algorithm . . . . . . . . . . . . 8
	5.4. Issues of the update . . . . . . . . . . . . . . . . . . 8		5.4. Issues of the algorithm . . . . . . . . . . . . . . . . . 8
	6. Implementation Ideas . . . . . . . . . . . . . . . . . . . . 8		5.5. Implementations . . . . . . . . . . . . . . . . . . . . . 8
			6. Comparisons with traditional resolver algorithms . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	10. Change History . . . . . . . . . . . . . . . . . . . . . . . 8		10. Change History . . . . . . . . . . . . . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		11.1. Normative References . . . . . . . . . . . . . . . . . . 9
	11.2. Informative References . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Resolver algorithm is defined in [RFC1034] and updated by [RFC2181].		Resolver algorithm is defined in [RFC1034] and updated by [RFC2181].
	The resolver algorithm seems to assume single cache that holds all		The resolver algorithm seems to assume single cache that holds all
	RRSets from received responses. [RFC2181] Section 5.4.1 Ranking data		RRSets from received responses. [RFC2181] Section 5.4.1 Ranking data
	specifies the trustworthiness order of RRSets. When a resolver		specifies the trustworthiness order of RRSets. When a resolver
	receives higher trustworthy data, the cached data is replaced by the		receives higher trustworthy data, the cached data is replaced by the
	received data.		received data.
	Parent side NS RRSet is very important because it creates new zone		Parent side NS RRSet is very important because it creates new zone
	and specifies how to access name servers for the created zone		and specifies how to access name servers for the created zone
	described in Section 3.1. However, parent side NS RRSets and glue		described in Section 3.1. However, parent side NS RRSets and glue
	records have least trustworthiness. The parent side NS RRSets and		records have least trustworthiness. The parent side NS RRSets and
	glue records are replaced by authoritative data if resolvers receive		glue records are replaced by authoritative data if resolvers receive
	authoritative data described in Section 3.3.		authoritative data described in Section 3.3.
	The overwrite makes name resolution unstable and some vulnerabilities		The replacement makes name resolution unstable and induces
	described in Section 4. And it may break requirements of resolvers'		vulnerabilities described in Section 4. And it may break
	answers described in Section 3.2.		requirements of resolvers' answers described in Section 3.2.
	This document proposes updated resolver algorithm that separate		This document proposes another resolver algorithm that separate
	authoritative data cache that is answered to stub resolvers and		authoritative data that is answered to stub resolvers and delegation
	delegation cache that is used to iterate zones. Details are		data that is used to iterate zones. Details are described in
	described in Section 5		Section 5
	2. Terminology		2. Terminology{#terminology}
	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 RFC 2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	Many of the specialized terms used in this specification are defined		Many of the specialized terms used in this specification are defined
	in DNS Terminology [RFC7719].		in DNS Terminology [RFC9499].
	3. Traditional resolver algorithm		3. Traditional resolver algorithm
	[RFC1034] defines "zone cut", "delegation", "referral", "glue		[RFC1034] defines "zone cut", "delegation", "referral", "glue
	records", "authoritative", and "resolver algorithm".		records", "authoritative", and "resolver algorithm".
	[RFC2181] clarified the resolver algorithm defined in [RFC1034].		[RFC2181] clarified the resolver algorithm defined in [RFC1034].
	3.1. Importance of parent side NS RRSet		3.1. Importance of parent side NS RRSet
	[RFC1034], [RFC2181] and [RFC7719] defines zone "cut", "delegation",		[RFC1034], [RFC2181] and [RFC8499] defines zone "cut", "delegation",
	"referral", and parent side NS RRSet functions as follows.		"referral", and parent side NS RRSet functions as follows.
	"'cuts' in the name space can be made between any two adjacent nodes.		"'cuts' in the name space can be made between any two adjacent nodes.
	After all cuts are made, each group of connected name space is a		After all cuts are made, each group of connected name space is a
	separate zone. The zone is said to be authoritative for all names in		separate zone. The zone is said to be authoritative for all names in
	the connected region." (Quoted from RFC 1034, Section 4.2)		the connected region." (Quoted from RFC 1034, Section 4.2)
	"The RRs that describe cuts around the bottom of the zone are NS RRs		"The RRs that describe cuts around the bottom of the zone are NS RRs
	that name the servers for the subzones. Since the cuts are between		that name the servers for the subzones. Since the cuts are between
	nodes, these RRs are NOT part of the authoritative data of the zone,		nodes, these RRs are NOT part of the authoritative data of the zone,
	and should be exactly the same as the corresponding RRs in the top		and should be exactly the same as the corresponding RRs in the top
	node of the subzone." (Quoted from RFC 1034, section 4.2.1)		node of the subzone." (Quoted from RFC 1034, section 4.2.1)
	"That is, parent zones have all the information needed to access		"That is, parent zones have all the information needed to access
	servers for their children zones." (Quoted from RFC 1034, section		servers for their children zones." (Quoted from RFC 1034, section
	4.2.1)		4.2.1)
	"Resolvers must be able to access at least one name server and use		"Resolvers must be able to access at least one name server and use
	that name server's information to answer a query directly, or pursue		that name server's information to answer a query directly, or pursue
	the query using referrals to other name servers." (Quoted from RFC		the query using referrals to other name servers." (Quoted from RFC
	1034, Section 2.4)		1034, Section 2.4)
	"Delegation is the process by which a separate zone is created in the		"Delegation is the process by which a separate zone is created in the
	name space beneath the apex of a given domain. Delegation happens		name space beneath the apex of a given domain. Delegation happens
	when an NS RRset is added in the parent zone for the child origin."		when an NS RRset is added in the parent zone for the child origin."
	Skipping		Skipping
	"The existence of a zone cut is indicated in the parent zone by the		"The existence of a zone cut is indicated in the parent zone by the
	existence of NS records specifying the origin of the child zone."		existence of NS records specifying the origin of the child zone."
	(Quoted from RFC 2181, Section 6)		(Quoted from RFC 2181, Section 6)
	As described above, parent side NS RRSet makes a new zone. Parent		As described above, parent side NS RRSet makes a new zone. Parent
	side NS RRSet (referral) and glue records are all the information to		side NS RRSet (referral) and glue records are all the information to
	access servers for the child zone.		access servers for the child zone.
	That is, resolvers SHOULD NOT use child side NS RRSet to iterate		That is, resolvers should not use child side NS RRSet to iterate
	zones.		zones.
	3.2. Recommendation of resolver's answer		3.2. Recommendation of resolver's answer
	RFC 1034 describes resolver's answer as follows.		RFC 1034 describes resolver's answer as follows.
	"The ideal answer is one from a server authoritative for the query		"The ideal answer is one from a server authoritative for the query
	which either gives the required data or a name error. The data is		which either gives the required data or a name error. The data is
	passed back to the user and entered in the cache for future use if		passed back to the user and entered in the cache for future use if
	its TTL is greater than zero." (Quoted from RFC 1034, Section 5.3.3)		its TTL is greater than zero." (Quoted from RFC 1034, Section 5.3.3)
	"The simplest mode for the client is recursive, since in this mode		"The simplest mode for the client is recursive, since in this mode
	the name server acts in the role of a resolver and returns either an		the name server acts in the role of a resolver and returns either an
	error or the answer, but never referrals." (Quoted from RFC 1034,		error or the answer, but never referrals." (Quoted from RFC 1034,
	Section 4.3.1)		Section 4.3.1)
	Recently, most of full-service resolver implementations answer only		Recently, most of full-service resolver implementations answer only
	authoritative data to stub resolvers.		authoritative data to stub resolvers.
	As described above, recommendation of resolver's answer is "answer		As described above, recommendation of resolver's answer is "answer
	only authoritative data." It does not break existing standards.		only authoritative data." It does not break existing standards.
	3.3. Traditional resolver algorithm		3.3. Traditional resolver algorithm
	Resolver algorithm is defined in [RFC1034] Section 5.3.3. Resolvers		Resolver algorithm is defined in [RFC1034] Section 5.3.3. Resolvers
	cache all RRSets during the iterations in their cache. When		cache all RRSets during the iterations in their cache. When
	resolvers receive new data, they will update their cache. The update		resolvers receive new data, they will update their cache. The update
	is explained using an example resolution of "www.example.com/A" in		is explained using an example resolution of "www.example.com/A" in
	"example.com" zone as follows.		"example.com" zone as follows.
	Skipping		Skipping
	(referral) is overwritten by "example.com" NS data attached in the		(referral) is overwritten by "example.com" NS data attached in the
	authoritative answer from child zone.		authoritative answer from child zone.
	The overwrite is specified by [RFC2181] Section 5.4.1 Ranking data.		The overwrite is specified by [RFC2181] Section 5.4.1 Ranking data.
	"Referrals" is the ranking 7: "Data from the authority section of a		"Referrals" is the ranking 7: "Data from the authority section of a
	non-authoritative answer". And "example.com" NS RRSet attached in		non-authoritative answer". And "example.com" NS RRSet attached in
	the authoritative answer is the ranking 4: "Data from the authority		the authoritative answer is the ranking 4: "Data from the authority
	section of an authoritative answer".		section of an authoritative answer".
	4. Problem Statement		4. Problem Statement
	[RFC1034] section 4.2.1 states that "the parent side NS RRSet should		[RFC1034] section 4.2.1 states that "the parent side NS RRSet should
	be exactly the same as the corresponding RRs in the top node of the		be exactly the same as the corresponding RRs in the top node of the
	subzone".		subzone".
	However, people sets different NS RRSets with mistakes, or		However, people sets different NS RRSets with mistakes, or
	intentionally. Name server configuration changes will make the		intentionally. Name server configuration changes will make the
	differences because the changes take time.		differences because the changes take time.
	If the zone data of name server(s) specified by referrals and		If the zone data of name server(s) specified by referrals and
	specified by zone apex NS RRSet are different, name resolution		specified by zone apex NS RRSet are different, name resolution
	becomes unstable. The cache overwrite of NS RRSet may break		becomes unstable. The cache overwrite of NS RRSet may break
	"Referrals and glue records are information to access servers for		"Referrals and glue records are information to access servers for
	child zones" specified by [RFC1034] section 4.2.1.		child zones" specified by [RFC1034] section 4.2.1.
	The overwrite by zone apex NS RRSet induced security vulnerabilities.		The overwrite by zone apex NS RRSet induced security vulnerabilities.
	In 2012, "Ghost Domain Names: Revoked Yet Still Resolvable"		In 2012, "Ghost Domain Names: Revoked Yet Still Resolvable"
	[DUAN2012GHOST] was reported. The attack uses updates of NS RRSet		[DUAN2012GHOST] was reported. The attack uses updates of NS RRSet
	attached in authoritative answer. Assume a resolver caches and uses		attached in authoritative answer. Assume a resolver caches and uses
	zone apex NS RRSet, and the parent side NS RRSet is updated or		zone apex NS RRSet, and the parent side NS RRSet is removed. The
	removed. The resolver send queries to name servers specified by zone		resolver send queries to name servers specified by zone apex NS RRSet
	apex NS RRSet and update NS RRSet by the NS RRSet attached in the		and update NS RRSet by the NS RRSet attached in the authority section
	authority section of the answer. Parent side NS RRSet specifies the		of the answer. Parent side NS RRSet specifies the existence of
	existence of delegation, however, resolvers may not check the		delegation, however, resolvers may not check the existence of the
	existence of the parent side NS RRSet and the domain name will remain		parent side NS RRSet and the domain name will remain in the resolvers
	in the resolvers.		if the parent NS RRSet has already been removed. DNS software
	DNS software vendors fixed the problem to restrict the TTL of NS		vendors fixed the problem to restrict the TTL of NS RRSet not to
	RRSet not to exceed the cached TTL value of old NS RRSet when		exceed the cached TTL value of old NS RRSet when replacing it.
	replacing it.
	5. Updating of Resolver Algorithm		5. Proposed solution
	5.1. Recommendations to resolvers		5.1. Recommendations to resolvers
	Resolvers MUST answer one of the following results: required data,		Resolvers answer one of the following results:
			* required data from a server that is authoritative for the query
			* name error from a server that is authoritative for the query
	name error, or empty (NODATA) from a server that is authoritative for		* empty (NODATA) from a server that is authoritative for the query
	the query, other name resolution errors (SERVFAIL, REFUSED), or no		* other name resolution errors (SERVFAIL, REFUSED),
	answer.		* no answer
	Resolvers iterate queries using referrals with corresponding glue		Resolvers iterate queries using referrals with corresponding glue
	records to other name servers. If referrals contain out-of-bailiwick		records to other name servers. If referrals contain out-of-bailiwick
	name server names, resolvers need to resolve address records of out-		name server names, resolvers need to resolve address records of out-
	of-bailiwick name servers.		of-bailiwick name servers.
	Resolvers MUST NOT use glue records and referrals except iterating		Resolvers must not use glue records and referrals except iterating
	delegations. Resolvers MUST NOT use zone apex NS RRSets to iterate.		delegations.
	5.2. Update to resolver algorithm		5.2. Another resolver algorithm
	This document update RFC 1034 Section 5.3.3. Algorithm as follows.		This document proposes another resolver algorithm that does not use
			zone apex NS RRSets to iterate as a change to RFC 1034 Section 5.3.3
			Algorithm as follows.
	Separate the cache into "authoritative data cache" and "delegation		Separate cache data into "authoritative data" and "delegation data".
			Each domain name entry may have both authoritative data and
			delegation data.
	cache". Pre-load root hint information (root NS RRSet and root		Pre-load root hint information (root NS RRSet and root server
	server addresses) into the delegation cache.		addresses) as delegation data.
	"Step 4.a." is changed as "if the response answers the question or		"Step 4.a." is changed as "if the response answers the question or
	contains a name error, cache the data into authoritative cache as		contains a name error, cache the data as authoritative data as well
	well as returning it back to the client".		as returning it back to the client".
	"Step 4.b." is changed as if the response contains a better		"Step 4.b." is changed as "if the response contains a better
	delegation to other servers, cache the delegation information into		delegation to other servers, cache the delegation information as
	delegation cache, and go to step 2".		delegation data, and go to step 2".
	The cache in "Step 1" is the authoritative data cache.
	The cache used in "step 2" is the delegation cache. "Set up their		The cache used in "Step 2" is the delegation data. "Set up their
	addresses using local data" is replaced as "Set up their addresses		addresses using local data" is replaced as "Set up their addresses
	using the delegation cache".		using the delegation data and resolution results of out-of-bailiwick
			name server names".
	As a result, RFC 2181 Section 5.4.1 Ranking data becomes useless		As a result, RFC 2181 Section 5.4.1 Ranking data becomes useless
	because the overwrite will not happen. Pre-loaded zone files (or		because the overwrite will not happen with this algorithm. Pre-
	zones retrieved from zone transfer) are treated as answers from		loaded zone files (or zones retrieved from zone transfer) are treated
	authoritative servers. They are treated as static authoritative		as answers from authoritative servers. They are treated as static
	data, referrals, and glue records. Referrals and glue records in		authoritative data, referrals, and glue records. Referrals and glue
	pre-loaded zone files MUST NOT be answered to stub resolvers. They		records in pre-loaded zone files must not be answered to stub
	MUST be used to iterate name servers only.		resolvers. They are used to iterate name servers only.
	Root zone is special because it is not delegated. Root hint and		Root zone is special because it is not delegated. Root hint and
	priming are exceptions because priming replaces pre-configured root		priming are exceptions because priming replaces pre-configured root
	hint by root zone apex NS RRSet (authoritative data).		hint by root zone apex NS RRSet (authoritative data).
	5.3. Characteristics of the update		5.3. Characteristics of the algorithm
	This update does not change resolver algorithm described in RFC 1034		This algorithm does not change resolver algorithm described in RFC
	section 5.3.3, except updates of referrals. It separates		1034 section 5.3.3, except updates of referrals. It separates
	authoritative data (possible to answer) and referrals (used to		authoritative data (possible to answer) and referrals (used to
	iterate DNS tree). It does not require no special ordering (e.g.		iterate DNS tree). It does not require no special ordering (e.g.
	trustworthiness and ranking data). It offers more stability of name		trustworthiness and ranking data). It offers more stability of name
	resolution because the results of traditional name resolution will		resolution because the results of traditional name resolution will
	flap if NS RRSets between the parent and the child are different.		flap if NS RRSets between the parent and the child are different.
	This algorithm is similar to traditional algorithm when the cache is		This algorithm is the same as traditional algorithm when the cache is
	empty.		empty.
	The update does not effect to DNSSEC [RFC4033] [RFC4034] [RFC4035]		The update does not effect to DNSSEC [RFC4033] [RFC4034] [RFC4035]
	because DNSSEC validates authoritative data and does not validate		because DNSSEC validates authoritative data and does not validate
	referrals.		referrals.
	The update does not effect to DNS Query Name Minimisation [RFC7816]		The update does not effect to DNS Query Name Minimisation [RFC9156]
	because answers from authoritative servers don't change. Delegation		because answers from authoritative servers don't change. Delegation
	cache and authoritative data cache separation will need small		cache and authoritative data cache separation will need small
	implementation changes.		implementation changes.
	5.4. Issues of the update		5.4. Issues of the algorithm
	This update makes impossible to control of TTL value of NS RRSet by		This algorithm makes impossible to control of TTL value of NS RRSet
	the child zone owner. However, overwrite of the referral does not		by the child zone owner. However, overwrite of the referral does not
	occur always and TTL control may increase queries to authoritative		occur always and TTL control may increase queries to authoritative
	servers.		servers.
	6. Implementation Ideas		5.5. Implementations
	Some implementers already implemented similar algorithm to their		Some implementers already implemented similar algorithm to their
	products.		products.
			6. Comparisons with traditional resolver algorithms
			To be described
	7. IANA Considerations		7. IANA Considerations
	{#:ianacons}
	This document has no IANA actions.		This document has no IANA actions.
	8. Security Considerations		8. Security Considerations
	9. Acknowledgments		9. Acknowledgments
			The author would like to thank discussions of dnsop WG.
	10. Change History		10. Change History
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<http://www.rfc-editor.org/info/rfc1034>.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
			[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
			Name Minimisation to Improve Privacy", RFC 9156,
			DOI 10.17487/RFC9156, November 2021,
			<https://www.rfc-editor.org/rfc/rfc9156>.
			11.2. Informative References
			[DUAN2012GHOST]
			Jiang, J., Liang, J., Li, K., Li, J., Duan, H., and J. Wu,
			"Ghost domain names:Revoked yet still resolvable", 2012,
			<The 19th Annual Network & Distributed System Security
			Symposium (NDSS 2012)>.
			[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
			STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
			<https://www.rfc-editor.org/rfc/rfc1034>.
	[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS		[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,		Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
	<http://www.rfc-editor.org/info/rfc2181>.		<https://www.rfc-editor.org/rfc/rfc2181>.
	[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,
	<http://www.rfc-editor.org/info/rfc4033>.		<https://www.rfc-editor.org/rfc/rfc4033>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,		RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<http://www.rfc-editor.org/info/rfc4034>.		<https://www.rfc-editor.org/rfc/rfc4034>.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<http://www.rfc-editor.org/info/rfc4035>.		<https://www.rfc-editor.org/rfc/rfc4035>.
	[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", RFC 7719, DOI 10.17487/RFC7719, December		Terminology", RFC 8499, DOI 10.17487/RFC8499, January
	2015, <http://www.rfc-editor.org/info/rfc7719>.		2019, <https://www.rfc-editor.org/rfc/rfc8499>.
	11.2. Informative References		[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
			RFC 9499, DOI 10.17487/RFC9499, March 2024,
	[DUAN2012GHOST]
	D, H., Jiang, J., Liang, J., Li, K., Li, J., and J. Wu,
	"Ghost domain names:Revoked yet still resolvable", 2012,
	<The 19th Annual Network & Distributed System Security
	Symposium (NDSS 2012)>.
	[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
	Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
	<http://www.rfc-editor.org/info/rfc7816>.		<https://www.rfc-editor.org/rfc/rfc9499>.
	Author's Address		Author's Address
	Kazunori Fujiwara		Kazunori Fujiwara
	Japan Registry Services Co., Ltd.		Japan Registry Services Co., Ltd.
	Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
	Chiyoda-ku, Tokyo 101-0065
	Japan
	Phone: +81 3 5215 8451
	Email: fujiwara@jprs.co.jp		Email: fujiwara@jprs.co.jp