< draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt		draft-fujiwara-dnsop-nsec-aggressiveuse-02.txt >
	Network Working Group K. Fujiwara		Network Working Group K. Fujiwara
	Internet-Draft JPRS		Internet-Draft JPRS
	Intended status: Informational A. Kato		Intended status: Informational A. Kato
	Expires: January 7, 2016 Keio/WIDE		Expires: April 21, 2016 Keio/WIDE
	July 06, 2015		October 19, 2015
	Aggressive use of NSEC/NSEC3		Aggressive use of NSEC/NSEC3
	draft-fujiwara-dnsop-nsec-aggressiveuse-01		draft-fujiwara-dnsop-nsec-aggressiveuse-02
	Abstract		Abstract
	While DNS highly depends on cache, its cache usage of non-existence		While DNS highly depends on cache, its cache usage of non-existence
	information was limited to exact matching. This draft proposes the		information was limited to exact matching. This draft proposes the
	aggressive use of a NSEC/NSEC3 resource record, which is able to		aggressive use of a NSEC/NSEC3 resource record, which is able to
	express non-existence of range of names authoritatively. With this		express non-existence of range of names authoritatively. With this
	proposal, shorter latency to many of negative responses is expected		proposal, shorter latency to many of negative responses is expected
	as well as some level of mitigation of random sub-domain attacks		as well as some level of mitigation of random sub-domain attacks
	(referred to as "Water Torture" attacks). It is also expected that		(referred to as "Water Torture" attacks). It is also expected that
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 http://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 January 7, 2016.		This Internet-Draft will expire on April 21, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 14 ¶		skipping to change at page 2, line 14 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	4. Proposed Solution: Aggressive Negative Caching . . . . . . . 3		4. Proposed Solution: Aggressive Negative Caching . . . . . . . 4
	5. Possible side effect . . . . . . . . . . . . . . . . . . . . 5		5. Possible side effect . . . . . . . . . . . . . . . . . . . . 5
	6. Another option . . . . . . . . . . . . . . . . . . . . . . . 5		6. The CD Bit . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Aggressive negative caching flag . . . . . . . . . . . . . . 6		6.1. Detecting random subdomain attacks . . . . . . . . . . . 6
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. Additional proposals . . . . . . . . . . . . . . . . . . . . 6
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 6		7.1. Another option . . . . . . . . . . . . . . . . . . . . . 6
	10. Implementation Considerations . . . . . . . . . . . . . . . . 6		7.2. Aggressive negative caching flag idea . . . . . . . . . . 6
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
			9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
			10. Implementation Considerations . . . . . . . . . . . . . . . . 7
			11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	12. Change History . . . . . . . . . . . . . . . . . . . . . . . 7		12. Change History . . . . . . . . . . . . . . . . . . . . . . . 7
	12.1. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 7		12.1. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 8
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		12.2. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 8
	13.1. Normative References . . . . . . . . . . . . . . . . . . 7		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	13.2. Informative References . . . . . . . . . . . . . . . . . 8		13.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Appendix A. Aggressive negative caching from RFC 5074 . . . . . 8		13.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix B. Detailed implementation idea . . . . . . . . . . . . 8		Appendix A. Aggressive negative caching from RFC 5074 . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Appendix B. Detailed implementation idea . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	While negative (non-existence) information of DNS caching mechanism		While negative (non-existence) information of DNS caching mechanism
	has been known as DNS negative cache [RFC2308], it requires exact		has been known as DNS negative cache [RFC2308], it requires exact
	matching in most cases. Assume that "example.com" zone doesn't have		matching in most cases. Assume that "example.com" zone doesn't have
	names such as "a.example.com" and "b.example.com". When a full-		names such as "a.example.com" and "b.example.com". When a full-
	service resolver receives a query "a.example.com" , it performs a DNS		service resolver receives a query "a.example.com" , it performs a DNS
	resolution process, and eventually gets NXDOMAIN and stores it into		resolution process, and eventually gets NXDOMAIN and stores it into
	its negative cache. When the full-service resolver receives another		its negative cache. When the full-service resolver receives another
	query "b.example.com", it doesn't match with "a.example.com". So it		query "b.example.com", it doesn't match with "a.example.com". So it
	will send a query to one of the authoritative servers of		will send a query to one of the authoritative servers of
	"example.com". This was because the NXDOMAIN response just says		"example.com". This was because the NXDOMAIN response just says
	there is no such name "a.example.com" and it doesn't tell anything		there is no such name "a.example.com" and it doesn't tell anything
	for "b.example.com".		for "b.example.com".
			Section 5 of [RFC2308] seems to show that negative answers should be
			cached only for the exact query name, and not (necessarily) for
			anything below it.
	Recently, DNSSEC [RFC4035] [RFC5155] has been practically deployed.		Recently, DNSSEC [RFC4035] [RFC5155] has been practically deployed.
	Two types of resource record (NSEC and NSEC3) are used for authentic		Two types of resource record (NSEC and NSEC3) are used for authentic
	non-existence. For a zone signed with NSEC, it may be possible to		non-existence. For a zone signed with NSEC, it may be possible to
	use the information carried in NSEC resource records to indicate that		use the information carried in NSEC resource records to indicate that
	the range of names where no valid name exists. Such use is		the range of names where no valid name exists. Such use is
	discouraged by Section 4.5 of RFC 4035, however.		discouraged by Section 4.5 of RFC 4035, however.
	This document proposes to make a minor change to RFC 4035 and the		This document proposes to make a minor change to RFC 4035 and the
	full-service resolver can use NSEC/NSEC3 resource records		full-service resolver can use NSEC/NSEC3 resource records
	aggressively.		aggressively.
	Aggressive Negative Caching was first proposed in Section 6 of DNSSEC		Aggressive Negative Caching was first proposed in Section 6 of DNSSEC
	Lookaside Validation (DLV) [RFC5074] in order to find covering NSEC		Lookaside Validation (DLV) [RFC5074] in order to find covering NSEC
	records efficiently. Unbound [UNBOUND] has aggressive negative		records efficiently. Unbound [UNBOUND] has aggressive negative
	caching code in its DLV validator. Unbound TODO file contains "NSEC/		caching code in its DLV validator. Unbound TODO file contains "NSEC/
	NSEC3 aggressive negative caching".		NSEC3 aggressive negative caching".
			Section 3 of [I-D.vixie-dnsext-resimprove] ("Stopping Downward Cache
			Search on NXDOMAIN") proposed another approach to use NXDOMAIN
			information effectively.
	2. Terminology		2. 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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	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 [I-D.ietf-dnsop-dns-terminology].		in DNS Terminology [I-D.ietf-dnsop-dns-terminology].
	3. Problem Statement		3. Problem Statement
	Random sub-domain attacks (referred to as "Water Torture" attacks)		Random sub-domain attacks (referred to as "Water Torture" attacks or
	send many non-existent queries to full-service resolvers. Their		NXDomain attacks) send many non-existent queries to full-service
	query names consist of random prefixes and a target domain name. The		resolvers. Their query names consist of random prefixes and a target
	negative cache does not work well and target full-service resolvers		domain name. The negative cache does not work well and target full-
	result in sending queries to authoritative DNS servers of the target		service resolvers result in sending queries to authoritative DNS
	domain name.		servers of the target domain name.
	When number of queries is large, the full-service resolvers drop		When number of queries is large, the full-service resolvers drop
	queries from both legitimate users and attackers as their outstanding		queries from both legitimate users and attackers as their outstanding
	queues are filled up.		queues are filled up.
	For example, BIND 9.10.2 [BIND9] full-service resolvers answer		For example, BIND 9.10.2 [BIND9] full-service resolvers answer
	SERVFAIL and Unbound 1.5.2 full-service resolvers drop most of		SERVFAIL and Unbound 1.5.2 full-service resolvers drop most of
	queries under 10,000 queries per second attack.		queries under 10,000 queries per second attack.
	The countermeasures implemented at this moment are rate limiting and		The countermeasures implemented at this moment are rate limiting and
	skipping to change at page 5, line 37 ¶		skipping to change at page 6, line 5 ¶
	People may generate many typos in TLD, and they will result in		People may generate many typos in TLD, and they will result in
	unnecessary DNS queries. Some implementations leak non-existent TLD		unnecessary DNS queries. Some implementations leak non-existent TLD
	queries whose second level domain are different each other. Well		queries whose second level domain are different each other. Well
	observed TLDs are ".local" and ".belkin". With this proposal, it is		observed TLDs are ".local" and ".belkin". With this proposal, it is
	possible to return NXDOMAIN immediately to such queries without		possible to return NXDOMAIN immediately to such queries without
	further DNS recursive resolution process. It may reduces round trip		further DNS recursive resolution process. It may reduces round trip
	time, as well as reduces the DNS queries to corresponding		time, as well as reduces the DNS queries to corresponding
	authoritative servers, including Root DNS servers.		authoritative servers, including Root DNS servers.
	6. Another option		6. The CD Bit
			The CD bit disables signature validation. It is one of the basic
			functions of DNSSEC protocol and it SHOULD NOT be changed. However,
			attackers may set the CD bit to their attack queries and the
			aggressive negative caching will be of no use.
			Ignoring the CD bit function may break the DNSSEC protocol.
			This draft proposes that the CD bit may be ignored to support
			aggressive negative caching when the full-service resolver is under
			attacks with CD bit set.
			6.1. Detecting random subdomain attacks
			Full-service resolvers should detect conditions under random
			subdomain attacks. When they are under attacks, their outstanding
			queries increase. If there are some destination addresses whose
			outstanding queries are many, they may contain attack target domain
			names. Existing countermeasures may implement attack detection.
			7. Additional proposals
			There are additional proposals to the aggressive negative caching.
			7.1. Another option
	The proposed technique is applicable to zones where there is a NSEC		The proposed technique is applicable to zones where there is a NSEC
	record to each owner name in the zone even without DNSSEC signed.		record to each owner name in the zone even without DNSSEC signed.
	And it is also applicable to full-service resolvers without DNSSEC		And it is also applicable to full-service resolvers without DNSSEC
	validation. Full-service resolvers can set DNSSEC OK bit in query		validation. Full-service resolvers can set DNSSEC OK bit in query
	packets and they will cache NSEC/NSEC3 resource records. They can		packets and they will cache NSEC/NSEC3 resource records. They can
	apply aggressive use of NSEC/NSEC3 resource records without DNSSEC		apply aggressive use of NSEC/NSEC3 resource records without DNSSEC
	validation.		validation.
	It is highly recommended to sign the zone, of course, and it is		It is highly recommended to sign the zone, of course, and it is
	recommended to apply DNSSEC validation of NSEC record prior to cache		recommended to apply DNSSEC validation of NSEC record prior to cache
	it in the negative cache.		it in the negative cache.
	7. Aggressive negative caching flag		7.2. Aggressive negative caching flag idea
	Authoritative DNS servers that dynamically generate NSEC records		Authoritative DNS servers that dynamically generate NSEC records
	normally generate minimally covering NSEC Records [RFC4470].		normally generate minimally covering NSEC Records [RFC4470].
	Aggressive negative caching does not work with minimally covering		Aggressive negative caching does not work with minimally covering
	NSEC records. DNS operators don't want zone walking and zone		NSEC records. DNS operators don't want zone walking and zone
	information leaks. They prefer NSEC resource records with narrow		information leaks. They prefer NSEC resource records with narrow
	ranges. When a query have the aggressive negative caching flag (AN		ranges. When there is a flag that show a full-service resolver
	flag), they can generate NSEC resource records with wider range under		support the aggressive negative caching and a query have the
	random subdomain attacks.		aggressive negative caching flag, authoritative DNS servers can
			generate NSEC resource records with wider range under random
			subdomain attacks.
	A full-service resolver which supports aggressive negative caching		However, changing range of minimally covering NSEC Records may be
	SHOULD set the AN flag when sending queries to authoritative DNS		implemented by detecting attacks. Authoritative DNS servers can
	servers.		answer any range of minimally covering NSEC Records.
	8. IANA Considerations		8. IANA Considerations
	This document reserves one of these bits as the AN flag (Aggressive		This document has no IANA actions.
	Negative Caching flag) in EDNS Header Flags defined in EDNS0
	[RFC6891].
	9. Security Considerations		9. Security Considerations
	Newly registered resource records may not be used immediately.		Newly registered resource records may not be used immediately.
	However, choosing suitable TTL value will mitigate the problem and it		However, choosing suitable TTL value will mitigate the problem and it
	is not a security problem.		is not a security problem.
	It is also suggested to limit the maximum TTL value of NSEC resource		It is also suggested to limit the maximum TTL value of NSEC resource
	records in the negative cache to, for example, 10800 seconds (3hrs),		records in the negative cache to, for example, 10800 seconds (3hrs),
	to mitigate the issue. Implementations which comply with this		to mitigate the issue. Implementations which comply with this
	skipping to change at page 6, line 51 ¶		skipping to change at page 7, line 41 ¶
	10. Implementation Considerations		10. Implementation Considerations
	Unbound has aggressive negative caching code in its DLV validator.		Unbound has aggressive negative caching code in its DLV validator.
	The author implemented NSEC aggressive caching using Unbound and its		The author implemented NSEC aggressive caching using Unbound and its
	DLV validator code.		DLV validator code.
	11. Acknowledgments		11. Acknowledgments
	The authors gratefully acknowledge DLV [RFC5074] author Samuel Weiler		The authors gratefully acknowledge DLV [RFC5074] author Samuel Weiler
	and Unbound developers. Olafur Gudmundsson and Pieter Lexis proposed		and Unbound developers. Olafur Gudmundsson and Pieter Lexis proposed
	aggressive negative caching flag idea.		aggressive negative caching flag idea. Valuable comments were
			provided by Bob Harold, Tatuya JINMEI, Shumon Huque, Mark Andrews,
			and Casey Deccio.
	12. Change History		12. Change History
	This section is used for tracking the update of this document. Will		This section is used for tracking the update of this document. Will
	be removed after finalize.		be removed after finalize.
	12.1. Version 01		12.1. Version 01
	o Added reference to DLV [RFC5074] and imported some sentences.		o Added reference to DLV [RFC5074] and imported some sentences.
	o Added Aggressive Negative Caching Flag idea.		o Added Aggressive Negative Caching Flag idea.
	o Added detailed algorithms.		o Added detailed algorithms.
			12.2. Version 02
			o Added reference to [I-D.vixie-dnsext-resimprove]
			o Added considerations for the CD bit
			o Updated detailed algorithms.
			o Moved Aggressive Negative Caching Flag idea into Another Option.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-dnsop-dns-terminology]		[I-D.ietf-dnsop-dns-terminology]
	Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", draft-ietf-dnsop-dns-terminology-03 (work in		Terminology", draft-ietf-dnsop-dns-terminology-05 (work in
	progress), June 2015.		progress), September 2015.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
			RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS		[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
	NCACHE)", RFC 2308, March 1998.		NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
			<http://www.rfc-editor.org/info/rfc2308>.
	[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, March 2005.		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
			<http://www.rfc-editor.org/info/rfc4035>.
	[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records		[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
	and DNSSEC On-line Signing", RFC 4470, April 2006.		and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/
			RFC4470, April 2006,
			<http://www.rfc-editor.org/info/rfc4470>.
	[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,		[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
	November 2007.		DOI 10.17487/RFC5074, November 2007,
			<http://www.rfc-editor.org/info/rfc5074>.
	[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS		[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
	Security (DNSSEC) Hashed Authenticated Denial of		Security (DNSSEC) Hashed Authenticated Denial of
	Existence", RFC 5155, March 2008.		Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
			<http://www.rfc-editor.org/info/rfc5155>.
	[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms		[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.		for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/
			RFC6891, April 2013,
			<http://www.rfc-editor.org/info/rfc6891>.
	13.2. Informative References		13.2. Informative References
	[BIND9] Internet Systems Consortium, Inc., "Name Server Software",		[BIND9] Internet Systems Consortium, Inc., "Name Server Software",
	2000, <https://www.isc.org/downloads/bind/>.		2000, <https://www.isc.org/downloads/bind/>.
			[I-D.vixie-dnsext-resimprove]
			Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
			Resolvers for Resiliency, Robustness, and Responsiveness",
			draft-vixie-dnsext-resimprove-00 (work in progress), June
			2010.
	[UNBOUND] NLnet Labs, "Unbound DNS validating resolver", 2006,		[UNBOUND] NLnet Labs, "Unbound DNS validating resolver", 2006,
	<http://www.unbound.net/>.		<http://www.unbound.net/>.
	Appendix A. Aggressive negative caching from RFC 5074		Appendix A. Aggressive negative caching from RFC 5074
	Imported from RFC 5074.		Imported from Section 6 of [RFC5074].
	Previously, cached negative responses were indexed by QNAME, QCLASS,		Previously, cached negative responses were indexed by QNAME, QCLASS,
	QTYPE, and the setting of the CD bit (see RFC 4035, Section 4.7), and		QTYPE, and the setting of the CD bit (see RFC 4035, Section 4.7), and
	only queries matching the index key would be answered from the cache.		only queries matching the index key would be answered from the cache.
	With aggressive negative caching, the validator, in addition to		With aggressive negative caching, the validator, in addition to
	checking to see if the answer is in its cache before sending a query,		checking to see if the answer is in its cache before sending a query,
	checks to see whether any cached and validated NSEC record denies the		checks to see whether any cached and validated NSEC record denies the
	existence of the sought record(s).		existence of the sought record(s).
	Using aggressive negative caching, a validator will not make queries		Using aggressive negative caching, a validator will not make queries
	for any name covered by a cached and validated NSEC record.		for any name covered by a cached and validated NSEC record.
	Furthermore, a validator answering queries from clients will		Furthermore, a validator answering queries from clients will
	synthesize a negative answer whenever it has an applicable validated		synthesize a negative answer whenever it has an applicable validated
	NSEC in its cache unless the CD bit was set on the incoming query.		NSEC in its cache unless the CD bit was set on the incoming query.
			Imported from Section 6.1 of [RFC5074].
	Implementing aggressive negative caching suggests that a validator		Implementing aggressive negative caching suggests that a validator
	will need to build an ordered data structure of NSEC records in order		will need to build an ordered data structure of NSEC records in order
	to efficiently find covering NSEC records. Only NSEC records from		to efficiently find covering NSEC records. Only NSEC records from
	DLV domains need to be included in this data structure.		DLV domains need to be included in this data structure.
	Appendix B. Detailed implementation idea		Appendix B. Detailed implementation idea
			Section 6.1 of [RFC5074] is expanded as follows.
	Implementing aggressive negative caching suggests that a validator		Implementing aggressive negative caching suggests that a validator
	need to build an ordered data structure of NSEC/NSEC3 records for		will need to build an ordered data structure of NSEC and NSEC3
	each signer domain name in order to efficiently find covering NSEC/		records for each signer domain name of NSEC / NSEC3 records in order
	NSEC3 records.		to efficiently find covering NSEC / NSEC3 records. Call the table as
			NSEC_TABLE.
			The aggressive negative caching may be inserted at the cache lookup
			part of the full-service resolvers.
	If errors happen in aggressive negative caching algorithm, resolvers		If errors happen in aggressive negative caching algorithm, resolvers
	MUST fall back to resolve the query as usual. "Resolve the query as		MUST fall back to resolve the query as usual. "Resolve the query as
	usual" means that the full-resolver resolve the query in Recursive-		usual" means that the full-resolver resolve the query in Recursive-
	mode.		mode as if the full-service resolver does not implement aggressive
			negative caching.
	To implement aggressive negative caching, resolver algorithm near		To implement aggressive negative caching, resolver algorithm near
	cache lookup will be changed as follows:		cache lookup will be changed as follows:
	If the query name entry exists in the cache {		QNAME = the query name;
	resolve the query as usual.		if (QNAME name entry exists in the cache) {
			resolve the query as usual;
	// if RRSet (query name and query type) exists in the cache,		// if RRSet (query name and query type) exists in the cache,
	// the resolver responds the RRSet from the cache		// the resolver responds the RRSet from the cache
	// Otherwise, the resolver needs to iterate the query.		// Otherwise, the resolver needs to iterate the query.
	}		}
	// Find closest enclosing NS RRset in the cache.		// Find closest enclosing NS RRset in the cache.
	// The owner of this NS RRset will be a suffix of the QNAME		// The owner of this NS RRset will be a suffix of the QNAME
	// - the longest suffix of any NS RRset in the cache.		// - the longest suffix of any NS RRset in the cache.
	SIGNER = closest enclosing NS RRSet of the QNAME in the cache.		SIGNER = closest enclosing NS RRSet of QNAME in the cache;
	If SIGNER zone does not have a special NSEC/NSEC3 data structure {		// Check the SOA RR of the SIGNER
	Resolve the query as usual.		if (SOA RR of SIGNER does not exist in the cache
			or SIGNER zone is not signed or not validated) {
			Resolve the query as usual;
	}		}
	if SIGNER zone is not signed or not validated {		if (SIGNER zone does not have NSEC_TABLE) {
	Resolve the query as usual		Resolve the query as usual;
	}		}
	If SIGNER zone is signed with NSEC {		if (SIGNER zone is signed with NSEC) {
	// NSEC mode		// NSEC mode
	If covering NSEC RR of the query name at SIGNER zone		if (covering NSEC RR of QNAME at SIGNER zone
	doesn't exist in the cache {		doesn't exist in the cache) {
	Resolve the query as usual.		Resolve the query as usual.
	}		}
	TEST = Find the longest existing domain name of the query name		TEST = Find the closest encloser domain name of QNAME and
	from the covering NSEC RR		the covering NSEC RR of QNAME
	if "*.TEST" exists in the cache {		if (*.TEST name entry exists in the cache) {
	the resolver can generate positive response		the resolver can generate positive response
	or resolve the query as usual.		// synthesize the wildcard *.TEST
	}		}
	if covering NSEC RR of "*.TEST" at SIGNER zone exists		if covering NSEC RR of "*.TEST" at SIGNER zone exists
	in the cache {		in the cache {
	the resolver can generate negative response.		the resolver can generate negative response;
	}		}
			// Lack of information
	// Lack of information, need to resolve the query as usual
	} else		} else
	if SIGNER zone is signed with NSEC3 and does not use Opt-Out {		if (SIGNER zone is signed with NSEC3 and does not use Opt-Out) {
	// NSEC3 mode		// NSEC3 mode
	QNAME = the query name		TEST = SIGNER;
	TEST = SIGNER		while (TEST != QNAME) {
	do {		// if any error happens in this loop, break this loop
	UPPER = TEST		UPPER = TEST;
	add a label from the QNAME to the start of TEST		add a label from the QNAME to the start of TEST;
	If the covering NSEC3 of TEST exist in the cache {		// TEST = label.UPPER
	// non-terminal name TEST does not exist		if (TEST name entry exist in the cache) {
	if *.UPPER or NSEC3 of *.UPPPER exist in the cache {		continue; // need to check rest of QNAME
	the resolver can generate negative response.		}
	} else {		if (covering NSEC3 of TEST exist in the cache) {
	if the covering NSEC3 of *.UPPER exist in the cache {		// (non-)terminal name TEST does not exist
	the resolver can generate positive response.		if (*.UPPER name entry exist in the cache) {
			// TEST does not exist and *.UPPER exist
			the resolver can generate positive response;
			} else
			if (covering NSEC3 of *.UPPER exist in the cache) {
			// TEST does not exist and *.UPPER does not exist
			the resolver can generate negative response;
	}		}
	// lack of information		break; // Lack of information
	break
	} else		} else
	if the NSEC3 of TEST does not exist {		if (NSEC3 of TEST does not exist in the cache) {
	// lack of information		break; // Lack of information
	break
	}		}
	// TEST label exist, then need to check the rest of the QNAME		// TEST label exist, then need to check rest of QNAME
	} while(TEST != QNAME)		}
	// lack of information		// Lack of information, need to resolve the query as usual
	}		}
	Resolve the query as usual		Resolve the query as usual
	Authors' Addresses		Authors' Addresses
	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 First Bldg. East 13F, 3-8-1 Nishi-Kanda
	Chiyoda-ku, Tokyo 101-0065		Chiyoda-ku, Tokyo 101-0065
	Japan		Japan
End of changes. 47 change blocks.
	91 lines changed or deleted		170 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/