< draft-gieben-nsec4-00.txt		draft-gieben-nsec4-01.txt >
	DNSEXT R. Gieben		DNSEXT R. Gieben
	Internet-Draft SIDN		Internet-Draft SIDN Labs
	Intended status: Experimental W. Mekking		Intended status: Experimental W. Mekking
	Expires: July 7, 2012 NLnet Labs		Expires: January 5, 2013 NLnet Labs
	January 4, 2012		July 04, 2012
	DNS Security (DNSSEC) Authenticated Denial of Existence		DNS Security (DNSSEC) Authenticated Denial of Existence
	draft-gieben-nsec4-00		draft-gieben-nsec4-01
	Abstract		Abstract
	The Domain Name System Security (DNSSEC) Extensions introduced the		The Domain Name System Security (DNSSEC) Extensions introduced the
	NSEC resource record for authenticated denial of existence, and the		NSEC resource record for authenticated denial of existence, and the
	NSEC3 resource record for hashed authenticated denial of existence.		NSEC3 resource record for hashed authenticated denial of existence.
	This document introduces an alternative resource record, NSEC4, which		This document introduces an alternative resource record, NSEC4, which
	similarly provides authenticated denial of existence. It permits		similarly provides authenticated denial of existence. It permits
	gradual expansion of delegation-centric zones, just like NSEC3 does.		gradual expansion of delegation-centric zones, just like NSEC3 does.
	With NSEC4 it is possible, but not required, to provide measures		With NSEC4 it is possible, but not required, to provide measures
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 July 7, 2012.		This Internet-Draft will expire on January 5, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 27 ¶		skipping to change at page 2, line 27 ¶
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Experimental Status . . . . . . . . . . . . . . . . . . . . . 6		2. Experimental Status . . . . . . . . . . . . . . . . . . . . . 6
	3. The NSEC4 Resource Record . . . . . . . . . . . . . . . . . . 7		3. The NSEC4 Resource Record . . . . . . . . . . . . . . . . . . 7
	3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8		3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8		3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8
	3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8		3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1.2.1. Opt-Out Flag . . . . . . . . . . . . . . . . . . . 8		3.1.2.1. Opt-Out Flag . . . . . . . . . . . . . . . . . . . 8
	3.1.2.2. Wildcard Flag . . . . . . . . . . . . . . . . . . 8		3.1.2.2. Wildcard Flag . . . . . . . . . . . . . . . . . . 8
	3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 8		3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 9
	3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 9		3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 9
	3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1.6. Next (Hashed) Owner Name . . . . . . . . . . . . . . . 9		3.1.6. Next (Hashed) Owner Name . . . . . . . . . . . . . . . 9
	3.1.7. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9		3.1.7. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9
	3.2. NSEC4 RDATA Wire Format . . . . . . . . . . . . . . . . . 9		3.2. NSEC4 RDATA Wire Format . . . . . . . . . . . . . . . . . 9
	3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10		3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
	3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 10		3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 10
	3.3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11		3.3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11
	4. The NSEC4PARAM Resource Record . . . . . . . . . . . . . . . . 11		4. The NSEC4PARAM Resource Record . . . . . . . . . . . . . . . . 11
	5. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Authoritative Server Considerations . . . . . . . . . . . . . 12		6. Empty non-terminals . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 12
	6.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 13
	6.2.1. Denial of Wildcard Synthesis Proof . . . . . . . . . . 13
	6.2.2. Closest Encloser Proof . . . . . . . . . . . . . . . . 14
	6.2.3. Denial of Source of Synthesis Proof . . . . . . . . . 14
	6.2.4. Name Error Responses . . . . . . . . . . . . . . . . . 14
	6.2.5. No Data Responses . . . . . . . . . . . . . . . . . . 15
	6.2.5.1. QTYPE is not DS . . . . . . . . . . . . . . . . . 15
	6.2.5.2. QTYPE is DS . . . . . . . . . . . . . . . . . . . 15
	6.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 15
	6.2.7. Wildcard No Data Responses . . . . . . . . . . . . . . 16
	6.2.8. Referrals to Unsigned Subzones . . . . . . . . . . . . 16
	6.2.9. Responding to Queries for NSEC4 Only Owner Names . . . 17
	6.2.10. Server Response to a Run-Time Collision . . . . . . . 17
	6.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 17
	6.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 17
	6.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 17
	7. Validator Considerations . . . . . . . . . . . . . . . . . . . 18		7. Authoritative Server Considerations . . . . . . . . . . . . . 12
	7.1. Responses with Unknown Hash Types . . . . . . . . . . . . 18		7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 12
	7.2. Verifying NSEC4 RRs . . . . . . . . . . . . . . . . . . . 18		7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 14
	7.3. Validating Name Error Responses . . . . . . . . . . . . . 18		7.2.1. Denial of Wildcard Synthesis Proof . . . . . . . . . . 14
	7.4. Validating No Data Responses . . . . . . . . . . . . . . . 19		7.2.2. Closest Encloser Proof . . . . . . . . . . . . . . . . 14
	7.5. Validating Wildcard Answer Responses . . . . . . . . . . . 19		7.2.3. Denial of Source of Synthesis Proof . . . . . . . . . 14
	7.6. Validating Wildcard No Data Responses . . . . . . . . . . 19		7.2.4. Name Error Responses . . . . . . . . . . . . . . . . . 15
	7.7. Validating Referrals to Unsigned Subzones . . . . . . . . 20		7.2.5. No Data Responses . . . . . . . . . . . . . . . . . . 15
	7.8. Validator Algorithm . . . . . . . . . . . . . . . . . . . 21		7.2.5.1. QTYPE is not DS . . . . . . . . . . . . . . . . . 15
			7.2.5.2. QTYPE is DS . . . . . . . . . . . . . . . . . . . 16
			7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 16
			7.2.7. Wildcard No Data Responses . . . . . . . . . . . . . . 16
			7.2.8. Referrals to Unsigned Subzones . . . . . . . . . . . . 17
			7.2.9. Responding to Queries for NSEC4 Only Owner Names . . . 17
			7.2.10. Server Response to a Run-Time Collision . . . . . . . 17
			7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 17
			7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 18
			7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 18
	8. Resolver Considerations . . . . . . . . . . . . . . . . . . . 21		8. Validator Considerations . . . . . . . . . . . . . . . . . . . 18
	8.1. NSEC4 Resource Record Caching . . . . . . . . . . . . . . 21		8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 18
	8.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 21		8.2. Verifying NSEC4 RRs . . . . . . . . . . . . . . . . . . . 18
			8.3. Validating Name Error Responses . . . . . . . . . . . . . 19
			8.4. Validating No Data Responses . . . . . . . . . . . . . . . 20
			8.5. Validating Wildcard Answer Responses . . . . . . . . . . . 20
			8.6. Validating Wildcard No Data Responses . . . . . . . . . . 20
			8.7. Validating Referrals to Unsigned Subzones . . . . . . . . 21
	9. Special Considerations . . . . . . . . . . . . . . . . . . . . 21		9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 22
	9.1. Domain Name Length Restrictions . . . . . . . . . . . . . 21		9.1. NSEC4 Resource Record Caching . . . . . . . . . . . . . . 22
	9.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 21		9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 22
	9.3. Iterations value . . . . . . . . . . . . . . . . . . . . . 22
	9.4. More Special Considerations . . . . . . . . . . . . . . . 22
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		10. Special Considerations . . . . . . . . . . . . . . . . . . . . 22
			10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 22
			10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 22
			10.3. Iterations value . . . . . . . . . . . . . . . . . . . . . 22
			10.4. More Special Considerations . . . . . . . . . . . . . . . 23
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 23		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24		12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	13. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
	13.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	14.1. Informative References . . . . . . . . . . . . . . . . . . 24		14.1. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	14.2. Normative References . . . . . . . . . . . . . . . . . . . 24		14.2. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	Appendix A. List of Hashed Owner Names . . . . . . . . . . . . . 25		15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
			15.1. Informative References . . . . . . . . . . . . . . . . . . 25
			15.2. Normative References . . . . . . . . . . . . . . . . . . . 25
	Appendix B. Example Zones . . . . . . . . . . . . . . . . . . . . 26		Appendix A. List of Hashed Owner Names . . . . . . . . . . . . . 26
	B.1. Hashed Denial of Existence . . . . . . . . . . . . . . . . 26
	B.2. Zero Hashing . . . . . . . . . . . . . . . . . . . . . . . 26
	B.3. SHA1 Hashing . . . . . . . . . . . . . . . . . . . . . . . 27
	Appendix C. Example Responses . . . . . . . . . . . . . . . . . . 28		Appendix B. Example Zones . . . . . . . . . . . . . . . . . . . . 27
	C.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 29		B.1. Hashed Denial of Existence . . . . . . . . . . . . . . . . 27
	C.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 30		B.2. Identity Function . . . . . . . . . . . . . . . . . . . . 27
	C.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 30		B.3. SHA1 Hashing . . . . . . . . . . . . . . . . . . . . . . . 28
	C.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 31
	C.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 32		Appendix C. Example Responses . . . . . . . . . . . . . . . . . . 29
			C.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
			C.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 31
			C.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 31
			C.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32
			C.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	1.1. Rationale		1.1. Rationale
	Hashed authenticated denial of existence proofs frequently hinge on		Hashed authenticated denial of existence proofs frequently hinge on
	the closest encloser proof (Section 7.2.1 and 8.3 of [RFC5155]).		the closest encloser proof (Section 7.2.1 and 8.3 of [RFC5155]).
	When validating a hashed denial of existence response, a validator		When validating a hashed denial of existence response, a validator
	must deny or assert the presence of a next closer name and a wildcard		must deny or assert the presence of a next closer name and a wildcard
	name. A validator can derive these names from the closest encloser.		name. A validator can derive these names from the closest encloser.
	This is why most of the denial of existence responses with NSEC3		This is why most of the denial of existence responses with NSEC3
	contain three records:		contain three records:
	1. A record which matches the closest encloser;		1. A record which matches the closest encloser, this tells the
			validator what the (unhashed) name of the closest encloser is;
	2. A record which covers or matches the next closer, to deny or		2. A record which covers or matches the next closer, to deny or
	assert the existence of the next closer name;		assert the existence of the next closer name. The validator
			needs to know the closest encloser to construct the next closer
			name;
	3. A record which covers or matches the wildcard, to deny or assert		3. A record which covers or matches the wildcard, to deny or assert
	wildcard synthesis.		wildcard synthesis. The validator needs to know the closest
			encloser to construct the source of synthesis.
	This document presents a new record, NSEC4, that is similar to NSEC3,		This document presents a new record, NSEC4, that is similar to NSEC3,
	but differs in the following ways:		but differs in the following ways:
	o It provides a new way to deny the existence of the wildcard, by		o It provides a new way to deny the existence of the wildcard, by
	introducing the Wildcard bit (described in Section 3.1.2.2);		introducing the Wildcard flag (described in Section 3.1.2.2).
			This bit makes the third record, from the list above, redundant;
	o It allows for unhashed records, by introducing Zero hashing		o It allows for unhashed records, by introducing an Identity
	(described in Section 3.1.1).		function (described in Section 3.1.1).
	With NSEC4 you will need a maximum of two records for any denial of		With NSEC4 you will need a maximum of two records for any denial of
	existence response, saving one record and accompanying signature(s)		existence response, saving one record and accompanying signature(s)
	compared to NSEC3.		compared to NSEC3.
	By defining Zero hashing, we also fold back NSEC into NSEC4 and add		By defining an Identity function, we also fold back NSEC into NSEC4
	Opt-out to unhashed names. With this change we collapse NSEC and		and add Opt-out to unhashed names. With this change we collapse NSEC
	NSEC3 into one new record to leave only one form of authenticated		and NSEC3 into one new record to leave only one form of authenticated
	denial of existence in the DNS.		denial of existence in the DNS.
	1.2. Requirements		1.2. Requirements
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.3. Terminology		1.3. Terminology
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 21 ¶
	[RFC2181], [RFC2308] and [RFC5155].		[RFC2181], [RFC2308] and [RFC5155].
	Furthermore, the same terminology is used throughout this document as		Furthermore, the same terminology is used throughout this document as
	is described in Section 1.3 from [RFC5155], with the following		is described in Section 1.3 from [RFC5155], with the following
	changes:		changes:
	Original owner name: the owner name corresponding to a hashed owner		Original owner name: the owner name corresponding to a hashed owner
	name if hashing is used. Or the owner name as-is if no hashing is		name if hashing is used. Or the owner name as-is if no hashing is
	used.		used.
	Opt-Out NSEC4 RR: a NSEC4 RR that has the Opt-Out flag set to 1.		Opt-Out NSEC4 RR: an NSEC4 RR that has the Opt-Out flag set to 1.
	Wildcard NSEC4 RR: a NSEC4 RR that has the Wildcard flag set to 1.		Wildcard NSEC4 RR: an NSEC4 RR that has the Wildcard flag set to 1.
	Opt-Out zone: a zone with at least one Opt-Out NSEC4 RR.		Opt-Out zone: a zone with at least one Opt-Out NSEC4 RR.
	Base32: the "Base 32 Encoding with Extended Hex Alphabet" as		Base32: the "Base 32 Encoding with Extended Hex Alphabet" as
	specified in [RFC4648]. Note that trailing padding characters		specified in [RFC4648]. Note that trailing padding characters
	("=") are not used in the NSEC4 specification.		("=") are not used in the NSEC4 specification.
	To cover: When a hash algorithm is defined, a NSEC4 RR is said to		To cover: an NSEC4 RR is said to "cover" a name if the (hashed) name
	"cover" a name if the hash of the name or next closer name falls		or (hashed) next closer name falls between the owner name of the
	between the owner name and the next hashed owner name of the		NSEC4 RR and the next (hashed) owner name of the NSEC4. In other
	NSEC4. When no hash algorithm (Zero hashing) is defined, a NSEC4		words, if it proves the nonexistence of the name, either directly
	RR is said to "cover" a name if the name or next closer name falls		or by proving the nonexistence of an ancestor of the name.
	between the owner name and the next owner name of the NSEC4. In
	other words, if it proves the nonexistence of the name, either
	directly or by proving the nonexistence of an ancestor of the
	name.
	To match: When a hash algorithm is defined, a NSEC4 RR is said to		To match: When a hash algorithm is defined, an NSEC4 RR is said to
	"match" a name if the owner name of the NSEC4 RR is the same as		"match" a name if the owner name of the NSEC4 RR is the same as
	the hashed owner name of that name. When no hash algorithm (Zero		the hashed owner name of that name. When no hash algorithm
	hashing) is defined, a NSEC4 RR is said to "match" a name if the		(Identity function) is defined, an NSEC4 RR is said to "match" a
	name and the owner name of the NSEC4 RR are equal.		name if the name and the owner name of the NSEC4 RR are equal.
	Zero hashing: Perform no hashing. Leave the name as-is.		Identity function: Perform no hashing. Leave the name as-is.
	2. Experimental Status		2. Experimental Status
	This document describes an EXPERIMENTAL extension to DNSSEC. It		This document describes an EXPERIMENTAL extension to DNSSEC. It
	interoperates with non-experimental DNSSEC using the technique		interoperates with non-experimental DNSSEC using the technique
	described in [RFC4955]. This experiment is identified with the		described in [RFC4955]. This experiment is identified with the
	following private algorithm (using algorithm PRIVATEDNS):		following private algorithm (using algorithm PRIVATEDNS):
	o Algorithm "5.nsec4.nlnetlabs.nl.", is an alias for algorithm 5,		o Algorithm "5.nsec4.nlnetlabs.nl.", is an alias for algorithm 5,
	RSASHA1.		RSASHA1.
	skipping to change at page 7, line 23 ¶		skipping to change at page 7, line 22 ¶
	Resolvers MUST NOT apply NSEC4 validation described in this document		Resolvers MUST NOT apply NSEC4 validation described in this document
	unless a response contains RRSIGs created with this private		unless a response contains RRSIGs created with this private
	algorithm.		algorithm.
	3. The NSEC4 Resource Record		3. The NSEC4 Resource Record
	The NSEC4 RR provides authenticated denial of existence for DNS		The NSEC4 RR provides authenticated denial of existence for DNS
	RRsets.		RRsets.
	The NSEC4 RR lists RR types present at the original owner name of the		The NSEC4 RR lists RR types present at the original owner name of the
	NSEC4 RR. It includes the next (hashed) owner name in the (hash)		NSEC4 RR. It includes the next (hashed) owner name in the canonical
	order of the zone. The complete set of NSEC4 RRs in a zone indicates		order of the zone. The complete set of NSEC4 RRs in a zone indicates
	which RRSets exist for the original owner name of the RR and form a		which RRSets exist for the original owner name of the RR and form a
	chain. This information is used to provide authenticated denial of		chain. This information is used to provide authenticated denial of
	existence for DNS data. To provide protection against zone		existence for DNS data. To provide protection against zone
	enumeration, the owner names used in the NSEC4 RR can be		enumeration, the owner names used in the NSEC4 RR can be
	cryptographic hashes of the original owner name prepended as a single		cryptographic hashes of the original owner name prepended as a single
	label to the name of the zone. If hashing is used, the NSEC4 RR		label to the name of the zone. The NSEC4 RR indicates which hash
	indicates which hash function is used to construct the hash, which		function (if any) is used to construct the hash, which salt is used,
	salt is used, and how many iterations of the hash function are		and how many iterations of the hash function are performed over the
	performed over the original owner name.		original owner name.
	The hashing technique is the same as with NSEC3 and is described in		The hashing technique is the same as with NSEC3 and is described in
	Section 5 of [RFC5155]. NSEC3 creates hashes for empty non-		Section 5 of [RFC5155]. NSEC3 creates hashes for empty non-
	terminals, NSEC4 does the same, even when Zero hashing is in use.		terminals, NSEC4 does the same, even when the Identity function is in
			use.
	(Hashed) owner names of unsigned delegations may be excluded from the		(Hashed) owner names of unsigned delegations may be excluded from the
	chain. A NSEC4 RR whose span covers an owner name or next closer		chain. An NSEC4 RR whose span covers an owner name or next closer
	name of an unsigned delegation is referred to as an Opt-Out NSEC4 RR		name of an unsigned delegation is referred to as an Opt-Out NSEC4 RR
	and is indicated by the presence of a flag.		and is indicated by the presence of a flag.
	If hashing is in use, the owner name for the NSEC4 RR is the base32		If hashing is in use, the owner name for the NSEC4 RR is the base32
	encoding of the hashed owner name prepended as a single label to the		encoding of the hashed owner name prepended as a single label to the
	name of the zone.		name of the zone.
	The type value for the NSEC4 RR is [TBD].		The type value for the NSEC4 RR is [TBD].
	The NSEC4 RR RDATA format is class independent and is described		The NSEC4 RR RDATA format is class independent and is described
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 22 ¶
	The NSEC4 RDATA has many similarities with the NSEC3 RDATA, but there		The NSEC4 RDATA has many similarities with the NSEC3 RDATA, but there
	are differences:		are differences:
	o There is an extra flag bit reserved to indicate whether wildcard		o There is an extra flag bit reserved to indicate whether wildcard
	synthesis is possible (e.g. does a wildcard domain name exist that		synthesis is possible (e.g. does a wildcard domain name exist that
	is immediately descending from the original owner name?);		is immediately descending from the original owner name?);
	o The hash length does not need to be stored, as all domain names		o The hash length does not need to be stored, as all domain names
	are stored as domain names, not raw hashes.		are stored as domain names, not raw hashes.
			[MM: Hash length is one byte. In general, NSEC3 is used in TLD
			zones. Those domain names are relatively short (on average 3
			characters (5 bytes wireformat), so in that case NSEC3 RRs become 4
			bytes longer.]
	3.1.1. Hash Algorithm		3.1.1. Hash Algorithm
	[RFC5155] defines the NSEC3 hash algorithm registry. The zero hash		[RFC5155] defines the NSEC3 hash algorithm registry. Hash algorithm
	(hash algorithm 0) is reserved. For NSEC4 we define the Zero hash to		0 is reserved. For NSEC4 we define hash algorithm 0 to be the
	mean that no hashing is used (Zero hashing).		Identity function, meaning that no hashing is used.
	3.1.2. Flags		3.1.2. Flags
	The Flags field is identical to the Flags field as defined in		The Flags field is identical to the Flags field as defined in
	[RFC5155]. This specification adds a new flag, the Wildcard Flag.		[RFC5155]. This specification adds a new flag, the Wildcard Flag.
	3.1.2.1. Opt-Out Flag		3.1.2.1. Opt-Out Flag
	Like the Opt-Out Flag defined in Section 3.1.2.1 of [RFC5155].		Like the Opt-Out Flag defined in Section 3.1.2.1 of [RFC5155].
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 22 ¶
	3.1.5. Salt		3.1.5. Salt
	Like the Salt field defined in Section 3.1.5 of [RFC5155].		Like the Salt field defined in Section 3.1.5 of [RFC5155].
	3.1.6. Next (Hashed) Owner Name		3.1.6. Next (Hashed) Owner Name
	The Next Owner Name field contains the next owner name that exists in		The Next Owner Name field contains the next owner name that exists in
	the definition of Section 2.2.3 of [RFC4592].		the definition of Section 2.2.3 of [RFC4592].
	If Zero hashing is used, the field contains the next owner name in		The field contains the next owner name in the canonical ordering of
	the canonical ordering of the zone, as explained in Section 6.1 of		the zone, as explained in Section 6.1 of [RFC4034].
	[RFC4034].
	A sender MUST NOT use DNS name compression on the Next Owner Name		A sender MUST NOT use DNS name compression on the Next Owner Name
	field when transmitting a NSEC4 RR.		field when transmitting an NSEC4 RR.
	Owner names of RRsets for which the given zone is not authoritative		Owner names of RRsets for which the given zone is not authoritative
	(such as glue records) MUST NOT be listed in the Next Owner Name,		(such as glue records) MUST NOT be listed in the Next Owner Name,
	unless at least one authoritative RRset exists at the same owner		unless at least one authoritative RRset exists at the same owner
	name.		name.
	3.1.7. Type Bit Maps		3.1.7. Type Bit Maps
	Like the Type Bit Maps field defined in Section 3.1.8 of [RFC5155].		Like the Type Bit Maps field defined in Section 3.1.8 of [RFC5155].
	skipping to change at page 9, line 49 ¶		skipping to change at page 10, line 4 ¶
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hash Alg. | Flags | Iterations |		| Hash Alg. | Flags | Iterations |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Salt Length | Salt /		| Salt Length | Salt /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Next (Hashed) Owner Name /		/ Next (Hashed) Owner Name /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Type Bit Maps /		/ Type Bit Maps /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Hash Algorithm is a single octet. If Hash Algorithm is zero
	Hash Algorithm is a single octet. If Hash Algorithm is zero (Zero		(Identity function), the Iterations field, the Salt Length field and
	hashing), the Iterations field, the Salt Length field and the Salt		the Salt field MUST be ignored.
	field MUST be ignored.
	Flags field is a single octet. The following one-bit flags are		Flags field is a single octet. The following one-bit flags are
	defined:		defined:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| |W|O|		| |W|O|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	o O - Opt-Out flag		o O - Opt-Out flag
	skipping to change at page 11, line 29 ¶		skipping to change at page 11, line 32 ¶
	mnemonics. When the mnemonic is not known, the TYPE		mnemonics. When the mnemonic is not known, the TYPE
	representation as described in Section 5 of [RFC3597] MUST be		representation as described in Section 5 of [RFC3597] MUST be
	used.		used.
	3.3.1. Examples		3.3.1. Examples
	NSEC record:		NSEC record:
	example. NSEC a.example NS SOA RRSIG DNSKEY NSEC		example. NSEC a.example NS SOA RRSIG DNSKEY NSEC
	They same data shown as a NSEC3 record:		The same data shown as an NSEC3 record:
	3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC3 1 0 0 - (		3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC3 1 0 0 - (
	6cd522290vma0nr8lqu1ivtcofj94rga		6cd522290vma0nr8lqu1ivtcofj94rga
	NS SOA RRSIG DNSKEY NSEC3PARAM )		NS SOA RRSIG DNSKEY NSEC3PARAM )
	As a NSEC4 record with Zero hashing:		As an NSEC4 record with Identity function:
	example. NSEC4 0 0 0 - a.example. NS SOA RRSIG DNSKEY NSEC4 NSEC4PARAM		example. NSEC4 0 0 0 - a.example. NS SOA RRSIG DNSKEY NSEC4 NSEC4PARAM
	And as a NSEC4 record with SHA1 hashing:		And as an NSEC4 record with SHA1 hashing:
	3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC4 1 0 0 - (		3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC4 1 0 0 - (
	6cd522290vma0nr8lqu1ivtcofj94rga.example.		6cd522290vma0nr8lqu1ivtcofj94rga.example.
	NS SOA RRSIG DNSKEY NSEC4PARAM )		NS SOA RRSIG DNSKEY NSEC4PARAM )
	4. The NSEC4PARAM Resource Record		4. The NSEC4PARAM Resource Record
	Exactly like NSEC3PARAM described in Section 5 of [RFC5155], except		Exactly like NSEC3PARAM described in Section 5 of [RFC5155], except
	the type code used [TBD] is that of NSEC4PARAM.		the type code used [TBD] is that of NSEC4PARAM.
	5. Opt-Out		5. Opt-Out
	This specification adds Opt-Out as described in Section 6 of		This specification adds Opt-Out as described in Section 6 of
	[RFC5155]. Because of Zero hashing, this allows for Opt-Out being		[RFC5155]. Because of the Identity function, this allows for Opt-Out
	used with unhashed names. A similar method is described in		being used with unhashed names. A similar method is described in
	[RFC4956], but with NSEC4 we can reuse the Opt-Out bit from the Flags		[RFC4956], but with NSEC4 we can reuse the Opt-Out bit from the Flags
	field.		field.
	6. Authoritative Server Considerations		6. Empty non-terminals
	6.1. Zone Signing		With NSEC3, every empty non-terminal will have a NSEC3 record. This
			is mentioned in [RFC5155], for instance in section 7.1, the second
			bullet point:
			Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
			the empty non-terminal is only derived from an insecure delegation
			covered by an Opt-Out NSEC3 RR.
			This is a crucial difference with respect to NSEC, where no such
			provision exists.
			With NSEC4 we unify NSEC and NSEC3 and consequently, each empty non-
			terminal will get an NSEC4 record (see Section 7.1, the 6th bullet).
			Furthermore, NSEC4 represents the next owner name as a domain name,
			like NSEC, while NSEC3 represents the next name as an unmodified
			binary hash value.
			Due to these changes, we can revert back to canonical ordering for
			NSEC4. This greatly simplifies the comparison code, because there is
			only one ordering mechanism.
			7. Authoritative Server Considerations
			7.1. Zone Signing
	Zones using NSEC4 must satisfy the same properties as described in		Zones using NSEC4 must satisfy the same properties as described in
	Section 7.1 of [RFC5155], with NSEC3 replaced by NSEC4.		Section 7.1 of [RFC5155], with NSEC3 replaced by NSEC4.
	In addition, for each original owner name that has a wildcard domain		In addition, for each original owner name that has a wildcard domain
	name immediately descending from the original owner name, the		name immediately descending from the original owner name, the
	corresponding NSEC4 RR MUST have the Wildcard bit set in the Flags		corresponding NSEC4 RR MUST have the Wildcard bit set in the Flags
	field.		field.
	The following steps describe one possible method of proper		The following steps describe one possible method of proper
	construction of NSEC4 RRs.		construction of NSEC4 RRs.
	1. Select the hash algorithm and the values for salt and		1. Select the hash algorithm and the values for salt and
	iterations;		iterations;
	2. For each unique original owner name in the zone add a NSEC4 RR;		2. For each unique original owner name in the zone add an NSEC4 RR;
	* If Opt-Out is being used, owner names of unsigned delegations		* If Opt-Out is being used, owner names of unsigned delegations
	MAY be excluded;		MAY be excluded;
	* The owner name of the NSEC4 RR is either the hash of the		* The owner name of the NSEC4 RR is either the hash of the
	original owner name, prepended as a single label to the zone		original owner name, prepended as a single label to the zone
	name, or is equal to the original owner name if Zero hashing		name, or is equal to the original owner name if Identity
	is used;		function is used;
	* The Next Owner Name field is left blank for the moment;		* The Next Owner Name field is left blank for the moment;
	* If Opt-Out is being used, set the Opt-Out bit to one.		* If Opt-Out is being used, set the Opt-Out bit to one.
	3. For collision detection purposes, if hashing is used, optionally		3. For collision detection purposes, if hashing is used, optionally
	keep track of the original owner name with the NSEC4 RR. Create		keep track of the original owner name with the NSEC4 RR. Create
	an additional NSEC4 RR corresponding to the original owner name		an additional NSEC4 RR corresponding to the original owner name
	with the asterisk label prepended. Mark this NSEC4 RR as		with the asterisk label prepended. Mark this NSEC4 RR as
	temporary;		temporary;
	4. If the original owner name is a wildcard domain name (Section		4. If the original owner name is a wildcard domain name (Section
	2.1.1. of [RFC4592]), mark the NSEC4 to be a NSEC4 RR that is		2.1.1. of [RFC4592]), mark the NSEC4 to be an NSEC4 RR that is
	matching a wildcard;		matching a wildcard;
	5. For each RRSet at the original owner name, set the corresponding		5. For each RRSet at the original owner name, set the corresponding
	bit in the Type Bit Maps field;		bit in the Type Bit Maps field;
	6. Additional NSEC4 RRs need to be added for every empty non-		6. Additional NSEC4 RRs need to be added for every empty non-
	terminal between the apex and the original owner name. If		terminal between the apex and the original owner name. If
	hashing is used, optionally keep track of the original owner		hashing is used, optionally keep track of the original owner
	names of these NSEC4 RRs and create temporary NSEC4 RRs for		names of these NSEC4 RRs and create temporary NSEC4 RRs for
	wildcard collisions in a similar fashion to step 3;		wildcard collisions in a similar fashion to step 3;
	7. Sort the set of NSEC4 RRs into hash order or canonical order,		7. Sort the set of NSEC4 RRs into canonical order.
	depending on the value of the hash algorithm;
	8. Combine NSEC4 RRs with identical owner names by replacing them		8. Combine NSEC4 RRs with identical owner names by replacing them
	with a single NSEC4 RR with the Type Bit Maps field consisting		with a single NSEC4 RR with the Type Bit Maps field consisting
	of the union of the types represented by the set of NSEC4 RRs.		of the union of the types represented by the set of NSEC4 RRs.
	If hashing is used and the original owner name was tracked, then		If hashing is used and the original owner name was tracked, then
	collisions may be detected when combining, as all of the		collisions may be detected when combining, as all of the
	matching NSEC4 RRs should have the same original owner name. If		matching NSEC4 RRs should have the same original owner name. If
	a hash collision is detected, then a new salt has to be chosen,		a hash collision is detected, then a new salt has to be chosen,
	and the signing process is restarted. Discard any possible		and the signing process is restarted. Discard any possible
	temporary NSEC4 RRs;		temporary NSEC4 RRs;
	9. In each NSEC4 RR, insert the next (hashed) owner name by using		9. In each NSEC4 RR, insert the next (hashed) owner name by using
	the domain name of the next NSEC4 RR in hashed (if hashing is		the domain name of the next NSEC4 RR in canonical order. The
	used) or canonical order (Zero hashing). The next (hashed)		next (hashed) owner name of the last NSEC4 RR in the zone
	owner name of the last NSEC4 RR in the zone contains the value		contains the value of the (hashed) owner name of the first NSEC4
	of the (hashed) owner name of the first NSEC4 RR in hashed or		RR in canonical order.
	canonical order. If the NSEC4 is marked to be matching a
	wildcard, find the NSEC4 that matches the closest encloser. Set
	the Wildcard bit in the Flags field of that NSEC4;
	10. Finally, add a NSEC4PARAM RR with the same Hash Algorithm,		If the NSEC4 is marked to be matching a wildcard, find the NSEC4
			that matches the closest encloser. Set the Wildcard bit in the
			Flags field of that NSEC4;
			10. Finally, add an NSEC4PARAM RR with the same Hash Algorithm,
	Iterations, and Salt fields to the zone apex.		Iterations, and Salt fields to the zone apex.
	6.2. Zone Serving		7.2. Zone Serving
	This specification modifies DNSSEC-enabled DNS responses generated by		This specification modifies DNSSEC-enabled DNS responses generated by
	authoritative servers. In particular, it replaces the use of NSEC or		authoritative servers. In particular, it replaces the use of NSEC or
	NSEC3 RRs in such responses with NSEC4 RRs.		NSEC3 RRs in such responses with NSEC4 RRs.
	6.2.1. Denial of Wildcard Synthesis Proof		7.2.1. Denial of Wildcard Synthesis Proof
	Instead of wasting a whole denial of existence RR to deny a wildcard,		Instead of wasting a whole denial of existence RR to deny a wildcard,
	we have introduced a bit in the Flags field of the NSEC4 RR that		we have introduced a bit in the Flags field of the NSEC4 RR that
	indicates whether wildcard synthesis was possible because there		indicates whether wildcard synthesis was possible because there
	exists a wildcard domain name immediately descending from the		exists a wildcard domain name immediately descending from the
	original owner name.		original owner name.
	The Denial of Wildcard Synthesis proof consists of one NSEC4 RR, that		The Denial of Wildcard Synthesis proof consists of one NSEC4 RR, that
	matches some domain name, and that has the Wildcard bit clear.		matches some domain name, and that has the Wildcard bit clear.
	Note that without much knowledge of the original owner name, this		Note that without much knowledge of the original owner name, this
	proof is not really useful. In particular, we don't know if this is		proof is not really useful. In particular, we don't know if this is
	the wildcard synthesis that we are looking for. This changes if we		the wildcard synthesis that we are looking for. This changes if we
	combine this proof with the closest encloser proof.		combine this proof with the closest encloser proof.
	6.2.2. Closest Encloser Proof		7.2.2. Closest Encloser Proof
	For some NSEC4 responses a proof of the closest encloser is required.		For some NSEC4 responses, namely Name Error Response (Section 7.2.4)
	This is a proof that some ancestor of the QNAME is the closest		and Referrals to Unsigned Subzones (Section 7.2.8), a proof of the
	encloser of QNAME. The proof is described in Section 7.2.1 of		closest encloser is required. This is a proof that some ancestor of
	[RFC5155], and is the same for NSEC4.		the QNAME is the closest encloser of QNAME. The proof is described
			in Section 7.2.1 of [RFC5155], and is the same for NSEC4.
	6.2.3. Denial of Source of Synthesis Proof		7.2.3. Denial of Source of Synthesis Proof
	The denial of wildcard synthesis proof combined with the closest		The denial of wildcard synthesis proof combined with the closest
	encloser proof results in a denial of source of synthesis proof. The		encloser proof results in a denial of source of synthesis proof. The
	source of synthesis is defined in [RFC4592] as the wildcard domain		source of synthesis is defined in [RFC4592] as the wildcard domain
	name immediately descending from the closest encloser.		name immediately descending from the closest encloser.
	The Denial of Source of Synthesis proof consists of (up to) two NSEC4		The Denial of Source of Synthesis proof consists of (up to) two NSEC4
	RRs, the same that constructed the closest encloser proof:		RRs, the same that constructed the closest encloser proof:
	o a NSEC4 RR that matches the closest encloser, and that has the		o an NSEC4 RR that matches the closest encloser, and that has the
	Wildcard bit clear in the Flags field;		Wildcard bit clear in the Flags field;
	o a NSEC4 RR that covers the next closer name to the closest		o an NSEC4 RR that covers the next closer name to the closest
	encloser.		encloser.
	The first NSEC4 RR essentially proves that the encloser exists, and		The first NSEC4 RR essentially proves that the encloser exists, and
	that no wildcard synthesis at the encloser is possible. The second		that no wildcard synthesis at the encloser is possible. The second
	NSEC4 RR proves that the encloser is the closest, thus the denial of		NSEC4 RR proves that the encloser is the closest, thus the denial of
	the wildcard synthesis is the denial of the source of synthesis.		the wildcard synthesis is the denial of the source of synthesis.
	6.2.4. Name Error Responses		7.2.4. Name Error Responses
	If the zone does not contain any RRsets matching QNAME either exactly		If the zone does not contain any RRsets matching QNAME either exactly
	or via wildcard name expansion, then the name server must include		or via wildcard name expansion, then the name server must include
	proof that:		proof that:
	o there is no exact match for QNAME;		o there is no exact match for QNAME;
	o the zone contains no RRsets that would match QNAME via wildcard		o the zone contains no RRsets that would match QNAME via wildcard
	name expansion.		name expansion.
	With NSEC, the server includes in the response a NSEC RR that covers		With NSEC, the server includes in the response an NSEC RR that covers
	QNAME, and a NSEC RR that covers the wildcard RR at the closest		QNAME, and an NSEC RR that covers the wildcard RR at the closest
	encloser.		encloser.
	With NSEC3, the server includes in the response a NSEC3 RR that		With NSEC3, the server includes in the response an NSEC3 RR that
	covers the next closer, a NSEC3 RR that covers the wildcard RR at the		covers the next closer, an NSEC3 RR that covers the wildcard RR at
	closest encloser, and a NSEC3 RR that matches the closest encloser.		the closest encloser, and an NSEC3 RR that matches the closest
			encloser.
	To prove the nonexistence of QNAME with NSEC4, the server MUST		To prove the nonexistence of QNAME with NSEC4, the server MUST
	include a denial of source of synthesis proof. This collection of		include a denial of source of synthesis proof. This collection of
	(up to) two NSEC4 RRs proves both that QNAME does not exist and that		(up to) two NSEC4 RRs proves both that QNAME does not exist and that
	a wildcard that could have matched QNAME also does not exist.		a wildcard that could have matched QNAME also does not exist.
	6.2.5. No Data Responses		7.2.5. No Data Responses
	6.2.5.1. QTYPE is not DS		7.2.5.1. QTYPE is not DS
	When a NODATA response needs to be returned, it is safe to say that		When a NODATA response needs to be returned, it is safe to say that
	QNAME exists. Similar to NSEC and NSEC3, server MUST include the		QNAME exists. Similar to NSEC and NSEC3, server MUST include the
	NSEC4 RR that matches QNAME. This NSEC4 RR MUST NOT have the bits		NSEC4 RR that matches QNAME. This NSEC4 RR MUST NOT have the bits
	corresponding to either the QTYPE or CNAME set in its Type Bit Maps		corresponding to either the QTYPE or CNAME set in its Type Bit Maps
	field.		field.
	6.2.5.2. QTYPE is DS		7.2.5.2. QTYPE is DS
	Because of Opt-Out, the response can be different when QTYPE is DS.		Because of Opt-Out, the response can be different when QTYPE is DS.
	If no NSEC4 RR matches QNAME, the server MUST return a closest		If no NSEC4 RR matches QNAME, the server MUST return a closest
	provable encloser proof for QNAME. The NSEC4 RR that covers the next		provable encloser proof for QNAME. The NSEC4 RR that covers the next
	closer name MUST have the Opt-Out bit set.		closer name MUST have the Opt-Out bit set.
	Note that we do not need to ensure the denial of source of synthesis		Note that we do not need to ensure the denial of source of synthesis
	proof, because a DS RRset next to a wildcard is meaningless (Section		proof, because a DS RRset next to a wildcard is meaningless (Section
	4.6, [RFC4592]).		4.6, [RFC4592]).
	6.2.6. Wildcard Answer Responses		7.2.6. Wildcard Answer Responses
	If the zone does not contain any RRsets matching QNAME, but there is		If the zone does not contain any RRsets matching QNAME, but there is
	wildcard name expansion possible then the name server must include		wildcard name expansion possible then the name server must include
	proof that the wildcard match was valid. This proof is accomplished		proof that the wildcard match was valid. This proof is accomplished
	by proving that QNAME does not exist and that the closest encloser of		by proving that QNAME does not exist and that the closest encloser of
	QNAME and the immediate ancestor of the wildcard are equal.		QNAME and the immediate ancestor of the wildcard are equal.
	Both with NSEC and NSEC3, the server includes in the response a NSEC		Both with NSEC and NSEC3, the server includes in the response an NSEC
	RR that covers the next closer. It is not necessary to return a RR		RR that covers the next closer. It is not necessary to return a RR
	that matches the closest encloser, as the existence of this closest		that matches the closest encloser, as the existence of this closest
	encloser is proven by the presence of the expanded wildcard in the		encloser is proven by the presence of the expanded wildcard in the
	response.		response.
	To prove that the wildcard name expansion was valid with NSEC4, the		To prove that the wildcard name expansion was valid with NSEC4, the
	server MUST include in the response a NSEC4 RR that covers the next		server MUST include in the response an NSEC4 RR that covers the next
	closer. For the same reasons as with NSEC and NSEC3, it is not		closer. For the same reasons as with NSEC and NSEC3, it is not
	necessary to return a RR that matches the closest encloser.		necessary to return a RR that matches the closest encloser.
	6.2.7. Wildcard No Data Responses		7.2.7. Wildcard No Data Responses
	With NSEC, the server includes in the response a NSEC RR that matches		With NSEC, the server includes in the response an NSEC RR that
	the wildcard, in addition to the NSEC RR that covers the next closer.		matches the wildcard, in addition to the NSEC RR that covers the next
	The NSEC RR does not have the bits corresponding to QTYPE or CNAME		closer. The NSEC RR does not have the bits corresponding to QTYPE or
	set in its Type Bit Maps field.		CNAME set in its Type Bit Maps field.
	Again, with NSEC3, the server includes in the response a NSEC3 RR		Again, with NSEC3, the server includes in the response an NSEC3 RR
	that matches the wildcard, in addition to the NSEC3 RR that covers		that matches the wildcard, in addition to the NSEC3 RR that covers
	the next closer. The NSEC3 RR does not have the bits corresponding		the next closer. The NSEC3 RR does not have the bits corresponding
	to QTYPE or CNAME set in its Type Bit Maps field. Besides that, a		to QTYPE or CNAME set in its Type Bit Maps field. Besides that, an
	NSEC3 RR that matches the closest encloser is included, because there		NSEC3 RR that matches the closest encloser is included, because there
	was no expanded wildcard in the response that can be used to		was no expanded wildcard in the response that can be used to
	determine the closest encloser.		determine the closest encloser.
	[RFC5155] already notes that the closest encloser to QNAME must be		[RFC5155] already notes that the closest encloser to QNAME must be
	the immediate ancestor of the wildcard RR, which is also defined in		the immediate ancestor of the wildcard RR, which is also defined in
	[RFC4592]. A closest encloser proof is not necessitated.		[RFC4592]. A closest encloser proof is not necessitated.
	To prove the wildcard no data response with NSEC4, the server MUST		To prove the wildcard no data response with NSEC4, the server MUST
	include in the response a NSEC4 RR that matches the wildcard, and a		include in the response an NSEC4 RR that matches the wildcard, and an
	NSEC4 RR that covers the next closer. The closest encloser can be		NSEC4 RR that covers the next closer. The closest encloser can be
	derived from the NSEC4 RR that matches the wildcard. From that, the		derived from the NSEC4 RR that matches the wildcard. From that, the
	next closer can be derived.		next closer can be derived.
	6.2.8. Referrals to Unsigned Subzones		7.2.8. Referrals to Unsigned Subzones
	If there is an NSEC4 RR that matches the delegation name, then that		If there is an NSEC4 RR that matches the delegation name, then that
	NSEC4 RR MUST be included in the response. The DS and CNAME bit in		NSEC4 RR MUST be included in the response. The DS and CNAME bit in
	the type bit maps of the NSEC4 RR must not be set (by definition).		the type bit maps of the NSEC4 RR must not be set (by definition).
	If the zone is Opt-Out, then there may not be an NSEC4 RR		If the zone is Opt-Out, then there may not be an NSEC4 RR
	corresponding to the delegation. In this case, the closest provable		corresponding to the delegation. In this case, the closest provable
	encloser proof MUST be included in the response. The included NSEC4		encloser proof MUST be included in the response. The included NSEC4
	RR that covers the next closer name for the delegation MUST have the		RR that covers the next closer name for the delegation MUST have the
	Opt-Out flag set to one.		Opt-Out flag set to one.
	Note that with Zero hashing, the NSEC4 RR that matches the closest		Note that with the Identity function, the NSEC4 RR that matches the
	provable encloser does not need to be included in the response, as it		closest provable encloser does not need to be included in the
	can be derived from the NSEC4 that covers the next closer name.		response, as it can be derived from the NSEC4 that covers the next
			closer name.
	6.2.9. Responding to Queries for NSEC4 Only Owner Names		7.2.9. Responding to Queries for NSEC4 Only Owner Names
	When NSEC4 hashing is in effect the paradox (NSEC4 records deny their		When NSEC4 hashing is in effect the paradox (NSEC4 records deny their
	own existence) described in Section 7.2.8 of [RFC5155] is back. When		own existence) described in Section 7.2.8 of [RFC5155] is back. When
	Zero hashing is used, there is no paradox. In light of this, queries		the Identity function is used, there is no paradox. In light of
	for the NSEC4 resource type are handled in the same way as normal		this, queries for the NSEC4 resource type are handled in the same way
	queries. Resolvers initiating these queries SHOULD disregard any		as normal queries. Resolvers initiating these queries SHOULD
	information learned from the returned NSEC4 records.		disregard any information learned from the returned NSEC4 records.
	6.2.10. Server Response to a Run-Time Collision		7.2.10. Server Response to a Run-Time Collision
	The same considerations as described in Section 7.2.9 of [RFC5155]		The same considerations as described in Section 7.2.9 of [RFC5155]
	for NSEC3 apply to NSEC4.		for NSEC3 apply to NSEC4.
	6.3. Secondary Servers		7.3. Secondary Servers
	The same considerations as described in Section 7.3 of [RFC5155] for		The same considerations as described in Section 7.3 of [RFC5155] for
	NSEC3 and NSEC3PARAM apply to NSEC4 and NSEC4PARAM.		NSEC3 and NSEC3PARAM apply to NSEC4 and NSEC4PARAM.
	6.4. Zones Using Unknown Hash Algorithms		7.4. Zones Using Unknown Hash Algorithms
	The same considerations as described in Section 7.4 of [RFC5155] for		The same considerations as described in Section 7.4 of [RFC5155] for
	NSEC3 apply to NSEC4.		NSEC3 apply to NSEC4.
	6.5. Dynamic Update		7.5. Dynamic Update
	A zone signed using NSEC4 may accept dynamic updates [RFC2136].		A zone signed using NSEC4 may accept dynamic updates [RFC2136].
	However, NSEC4 introduces some special considerations for dynamic		However, NSEC4 introduces some special considerations for dynamic
	updates.		updates.
	Adding and removing names in a zone MUST account for the creation or		Adding and removing names in a zone MUST account for the creation or
	removal of empty non-terminals, similar to [RFC5155], Section 7.5.		removal of empty non-terminals, similar to [RFC5155], Section 7.5.
	The presence of Opt-Out in a zone means that some additions or		The presence of Opt-Out in a zone means that some additions or
	removals of unsigned delegations of names will not require changes to		removals of unsigned delegations of names will not require changes to
	skipping to change at page 18, line 13 ¶		skipping to change at page 18, line 41 ¶
	setting or clearing of the Wildcard bit in the Flags field:		setting or clearing of the Wildcard bit in the Flags field:
	o When adding a wildcard name, the NSEC4 RR that matches the		o When adding a wildcard name, the NSEC4 RR that matches the
	immediate parent of the wildcard MUST set the Wildcard bit in the		immediate parent of the wildcard MUST set the Wildcard bit in the
	Flags field;		Flags field;
	o When deleting a wildcard name, the NSEC4 RR that matches the		o When deleting a wildcard name, the NSEC4 RR that matches the
	immediate parent of the wildcard MUST clear the Wildcard bit in		immediate parent of the wildcard MUST clear the Wildcard bit in
	the Flags field.		the Flags field.
	7. Validator Considerations		8. Validator Considerations
	7.1. Responses with Unknown Hash Types		8.1. Responses with Unknown Hash Types
	A validator MUST ignore NSEC4 RRs with unknown hash types. The		A validator MUST ignore NSEC4 RRs with unknown hash types. The
	practical result of this is that responses containing only such NSEC4		practical result of this is that responses containing only such NSEC4
	RRs will generally be considered bogus.		RRs will generally be considered bogus.
	7.2. Verifying NSEC4 RRs		8.2. Verifying NSEC4 RRs
	A validator MUST ignore the undefined bits (0-5) in the Flags field		A validator MUST ignore the undefined bits (0-5) in the Flags field
	of NSEC4 RRs.		of NSEC4 RRs.
	A validator MAY treat a response as bogus if the response contains		A validator MAY treat a response as bogus if the response contains
	NSEC4 RRs that contain different values for hash algorithm,		NSEC4 RRs that contain different values for hash algorithm,
	iterations, or salt from each other for that zone.		iterations, or salt from each other for that zone.
	7.3. Validating Name Error Responses		8.3. Validating Name Error Responses
	A validator MUST verify that there is a closest encloser for QNAME		A validator MUST verify that there is a closest encloser for QNAME
	present in the response. A validator MUST verify that the Wildcard		present in the response. A validator MUST verify that the Wildcard
	bit is clear in the Flags field of the NSEC4 RR that matches the		bit is clear in the Flags field of the NSEC4 RR that matches the
	closest encloser.		closest encloser.
			Note: In denial of existence responses, the Wildcard flag will
			never be set. Setting the bit indicated that wildcard synthesis
			is possible at the closest encloser. Obviously, that contradicts
			with the denial of existence of the query name. Nevertheless, a
			validator must verify that the Wildcard bit is clear. If a
			validator fails to check the bit, it is vulnerable to replay
			attacks. For example, if you do not check the Wildcard Flag in
			the example.com NSEC4 (but *.example.com does exist), an attacker
			can use the record to deny names that would otherwise match the
			wildcard name.
	In order to find the closest encloser, the validator MUST find the		In order to find the closest encloser, the validator MUST find the
	longest name, X, such that X is an ancestor of QNAME that is matched		longest name, X, such that X is an ancestor of QNAME that is matched
	by a NSEC4 RR present in the response.		by an NSEC4 RR present in the response.
	One possible algorithm for finding the closest encloser is as		One possible algorithm for finding the closest encloser is as
	follows:		follows:
	1. Set SNAME=QNAME;		1. Set SNAME=QNAME;
	2. If there is a NSEC4 RR in the response that matches SNAME, then		2. If there is an NSEC4 RR in the response that matches SNAME, then
	we have found the closest encloser;		we have found the closest encloser;
	3. Truncate SNAME by one label from the left, go to step 2.		3. Truncate SNAME by one label from the left, go to step 2.
	Once the closest encloser has been discovered, the validator MUST		Once the closest encloser has been discovered, the validator MUST
	check that the NSEC4 RR that has the closest encloser as the original		check that the NSEC4 RR that has the closest encloser as the original
	owner name is from the proper zone. The DNAME type bit MUST NOT be		owner name is from the proper zone. The DNAME type bit MUST NOT be
	set and the NS type bit MUST be clear if the SOA type bit is clear.		set and the NS type bit MUST be clear if the SOA type bit is clear.
	If this is not the case, it would be an indication that an attacker		If this is not the case, it would be an indication that an attacker
	is using them to falsely deny the existence of RRs for which the		is using them to falsely deny the existence of RRs for which the
	server is not authoritative.		server is not authoritative.
	In addition, the validator MUST verify that there is a NSEC4 RR that		In addition, the validator MUST verify that there is an NSEC4 RR that
	covers the next closer name.		covers the next closer name.
	7.4. Validating No Data Responses		8.4. Validating No Data Responses
	If QTYPE is not DS, a validator MUST verify that a NSEC4 RR that		If QTYPE is not DS, a validator MUST verify that an NSEC4 RR that
	matches QNAME is present and that both the QTYPE and the CNAME type		matches QNAME is present and that both the QTYPE and the CNAME type
	are not set in its Type Bit Maps field.		are not set in its Type Bit Maps field.
	Note that this test also covers the case where the NSEC4 RR exists		Note that this test also covers the case where the NSEC4 RR exists
	because it corresponds to an empty non-terminal, in which case the		because it corresponds to an empty non-terminal, in which case the
	NSEC4 RR will have an empty Type Bit Maps field.		NSEC4 RR will have an empty Type Bit Maps field.
	If QTYPE is DS, and there is a NSEC4 RR that matches QNAME present in		If QTYPE is DS, and there is an NSEC4 RR that matches QNAME present
	the response, then that NSEC4 RR MUST NOT have the bits corresponding		in the response, then that NSEC4 RR MUST NOT have the bits
	to DS and CNAME set in its Type Bit Maps field.		corresponding to DS and CNAME set in its Type Bit Maps field.
	If there is no such NSEC4 RR, then the validator MUST verify that		If there is no such NSEC4 RR, then the validator MUST verify that
	there is a closest provable encloser for QNAME present in the		there is a closest provable encloser for QNAME present in the
	response. The closest provable encloser is found in a similar way as		response. The closest provable encloser is found in a similar way as
	the closest encloser. In addition, the validator MUST verify that		the closest encloser. In addition, the validator MUST verify that
	there is a NSEC4 RR that covers the next closer name and has the Opt-		there is an NSEC4 RR that covers the next closer name and has the
	Out bit set.		Opt-Out bit set.
	7.5. Validating Wildcard Answer Responses		8.5. Validating Wildcard Answer Responses
	The verified wildcard answer RRSet in the response provides the		The verified wildcard answer RRSet in the response provides the
	validator with a closest encloser for QNAME. The validator can do so		validator with a closest encloser for QNAME. The validator can do so
	by checking the label count in the RRSIG and the number of labels in		by checking the label count in the RRSIG and the number of labels in
	the answer's owner name.		the answer's owner name.
	The validator MUST verify that there is a NSEC4 RR that covers the		The validator MUST verify that there is an NSEC4 RR that covers the
	next closer name to QNAME is present in the response. This proves		next closer name to QNAME is present in the response. This proves
	that QNAME itself did not exist and that the correct wildcard was		that QNAME itself did not exist and that the correct wildcard was
	used to generate the response.		used to generate the response.
	7.6. Validating Wildcard No Data Responses		8.6. Validating Wildcard No Data Responses
	The validator MUST verify that there is a NSEC4 RR present in the		The validator MUST verify that there is an NSEC4 RR present in the
	response that matches the source of synthesis.		response that matches the source of synthesis.
	In order to find the source of synthesis, the validator MUST find the		In order to find the source of synthesis, the validator MUST find the
	longest name, X, such that X is an ancestor of QNAME and that *.X is		longest name, X, such that X is an ancestor of QNAME and that *.X is
	matched by a NSEC4 RR present in the response.		matched by a NSEC4 RR present in the response.
	One possible algorithm for finding the source of synthesis is as		One possible algorithm for finding the source of synthesis is as
	follows:		follows:
	1. Set SNAME=QNAME;		1. Set SNAME=QNAME;
	skipping to change at page 20, line 13 ¶		skipping to change at page 21, line 4 ¶
	response that matches the source of synthesis.		response that matches the source of synthesis.
	In order to find the source of synthesis, the validator MUST find the		In order to find the source of synthesis, the validator MUST find the
	longest name, X, such that X is an ancestor of QNAME and that *.X is		longest name, X, such that X is an ancestor of QNAME and that *.X is
	matched by a NSEC4 RR present in the response.		matched by a NSEC4 RR present in the response.
	One possible algorithm for finding the source of synthesis is as		One possible algorithm for finding the source of synthesis is as
	follows:		follows:
	1. Set SNAME=QNAME;		1. Set SNAME=QNAME;
	2. Truncate SNAME by one label from the left. This is a candidate		2. Truncate SNAME by one label from the left. This is a candidate
	for the closest encloser;		for the closest encloser;
	3. Set WNAME to be SNAME with the asterisk label prepended:		3. Set WNAME to be SNAME with the asterisk label prepended:
	WNAME=*.SNAME;		WNAME=*.SNAME;
	4. If there is a NSEC4 RR in the response that matches WNAME, then		4. If there is an NSEC4 RR in the response that matches WNAME, then
	we have found the source of synthesis, with SNAME being the		we have found the source of synthesis, with SNAME being the
	closest encloser;		closest encloser;
	5. Go to step 2.		5. Go to step 2.
	The validator does not need to check that the closest encloser is		The validator does not need to check that the closest encloser is
	from the proper zone. The authoritative server returned a NSEC4 that		from the proper zone. The authoritative server returned an NSEC4
	matches the source of synthesis. According to [RFC2672], this proves		that matches the source of synthesis. According to [RFC6672], this
	that the server did not encounter a referral (step 3b of the server		proves that the server did not encounter a referral (step 3b of the
	algorithm [RFC1035]), nor did it encounter a DNAME (step 3c of the		server algorithm [RFC1035]), nor did it encounter a DNAME (step 3c of
	server algorithm [RFC1035]).		the server algorithm [RFC1035]).
	Now that the validator knows the source of synthesis and thus the		Now that the validator knows the source of synthesis and thus the
	closest encloser, it can derive the next closer name. The validator		closest encloser, it can derive the next closer name. The validator
	MUST verify that there is a NSEC4 RR that covers the next closer name		MUST verify that there is an NSEC4 RR that covers the next closer
	to QNAME, is present in the response.		name to QNAME, is present in the response.
	Note that, because the response included a NSEC4 that matches the		Note that, because the response included an NSEC4 that matches the
	source of synthesis, we know that there exists data in the zone below		source of synthesis, we know that there exists data in the zone below
	the closest encloser. Therefore, the closest encloser cannot be a		the closest encloser. Therefore, the closest encloser cannot be a
	delegation, nor can there exists a DNAME RRset at the closest		delegation, nor can there exists a DNAME RRset at the closest
	encloser.		encloser.
	7.7. Validating Referrals to Unsigned Subzones		[MM: As an additional check, the validator can verify if the NSEC4
			matching the closest encloser has the Wildcard Flag set.]
			8.7. Validating Referrals to Unsigned Subzones
	The delegation name in a referral is the owner name of the NS RRSet		The delegation name in a referral is the owner name of the NS RRSet
	present in the authority section of the referral response.		present in the authority section of the referral response.
	If there is a NSEC4 RR present in the response that matches the		If there is an NSEC4 RR present in the response that matches the
	delegation name, then the validator MUST ensure that the NS bit is		delegation name, then the validator MUST ensure that the NS bit is
	set and that the DS bit is not set in the Type Bit Maps field of the		set and that the DS bit is not set in the Type Bit Maps field of the
	NSEC4 RR. The validator MUST also ensure that the NSEC4 RR is from		NSEC4 RR. The validator MUST also ensure that the NSEC4 RR is from
	the correct (i.e., parent) zone. This is done by ensuring that the		the correct (i.e., parent) zone. This is done by ensuring that the
	SOA bit is not set in the Type Bit Maps field of this NSEC4 RR.		SOA bit is not set in the Type Bit Maps field of this NSEC4 RR.
	Note that the presence of a NS bit implies the absence of a DNAME		Note that the presence of an NS bit implies the absence of a DNAME
	bit, so there is no need to check for the DNAME bit in the Type Bit		bit, so there is no need to check for the DNAME bit in the Type Bit
	Maps field of the NSEC4 RR.		Maps field of the NSEC4 RR.
	If there is no NSEC4 RR present that matches the delegation name,		If there is no NSEC4 RR present that matches the delegation name,
	then the validator MUST verify that there is a closest provable		then the validator MUST verify that there is a closest provable
	encloser for the delegation name. In addition, the validator MUST		encloser for the delegation name. In addition, the validator MUST
	verify that there is a NSEC4 RR that covers the next closer name and		verify that there is an NSEC4 RR that covers the next closer name and
	has the Opt-Out bit set.		has the Opt-Out bit set.
	7.8. Validator Algorithm		9. Resolver Considerations
	The following steps describe one possible method of proper validation
	of an answer containing NSEC4 RRs.
	[TBD]
	8. Resolver Considerations
	8.1. NSEC4 Resource Record Caching		9.1. NSEC4 Resource Record Caching
	The same considerations as described in Section 9.1 of [RFC5155] for		The same considerations as described in Section 9.1 of [RFC5155] for
	NSEC3 apply to NSEC4.		NSEC3 apply to NSEC4.
	8.2. Use of the AD Bit		9.2. Use of the AD Bit
	The same considerations as described in Section 9.2 of [RFC5155] for		The same considerations as described in Section 9.2 of [RFC5155] for
	NSEC3 apply to NSEC4.		NSEC3 apply to NSEC4.
	9. Special Considerations		10. Special Considerations
	9.1. Domain Name Length Restrictions		10.1. Domain Name Length Restrictions
	The same considerations as described in Section 10.1 of [RFC5155]		The same considerations as described in Section 10.1 of [RFC5155]
	apply.		apply.
	9.2. DNAME at the Zone Apex		10.2. DNAME at the Zone Apex
	The DNAME specification in Section 3 of [RFC2672] has a 'no-		The DNAME specification in Section 3 of [RFC6672] has a 'no-
	descendants' limitation. If a DNAME RR is present at node N, there		descendants' limitation. If a DNAME RR is present at node N, there
	MUST be no data at any descendant of N.		MUST be no data at any descendant of N.
	[RFC5155] updates the DNAME specification to allow NSEC3 and RRSIG		[RFC5155] updates the DNAME specification to allow NSEC3 and RRSIG
	types at descendants of the apex regardless of the existence of DNAME		types at descendants of the apex regardless of the existence of DNAME
	at the apex.		at the apex.
	This document updates the DNAME specification to also allow NSEC4		This document updates the DNAME specification to also allow NSEC4
	types at descendants of the apex regardless of the existence of DNAME		types at descendants of the apex regardless of the existence of DNAME
	at the apex.		at the apex.
	9.3. Iterations value		10.3. Iterations value
	Like Section 10.3 in [RFC5155], but we recommend to read		Like Section 10.3 in [RFC5155], but we recommend to read
	[Schaeffer10] as it shows that a lower iterations value is also		[Schaeffer10] as it shows that a lower iterations value is also
	acceptable. The research shows that that the half performance count		acceptable. The research shows that that the half performance count
	for validators is roughly 150 to 600, depending on the key size. For		for validators is roughly 150 to 600, depending on the key size. For
	authoritative servers the half performance count is around 100		authoritative servers the half performance count is around 100
	iterations.		iterations.
	9.4. More Special Considerations		10.4. More Special Considerations
	Appendix C of [RFC5155] clarifies specific behavior and explains more		Appendix C of [RFC5155] clarifies specific behavior and explains more
	special considerations for implementations, regarding salting and		special considerations for implementations, regarding salting and
	hash collisions. These considerations for NSEC3 also apply to NSEC4.		hash collisions. These considerations for NSEC3 also apply to NSEC4.
	10. IANA Considerations		11. IANA Considerations
	Although the NSEC4 and NSEC4PARAM RR formats include a hash algorithm		Although the NSEC4 and NSEC4PARAM RR formats include a hash algorithm
	parameter, this document does not define a particular mechanism for		parameter, this document does not define a particular mechanism for
	safely transitioning from one NSEC4 hash algorithm to another. When		safely transitioning from one NSEC4 hash algorithm to another. When
	specifying a new hash algorithm for use with NSEC4, a transition		specifying a new hash algorithm for use with NSEC4, a transition
	mechanism MUST also be defined.		mechanism MUST also be defined.
	This document updates the IANA registry "DOMAIN NAME SYSTEM		This document updates the IANA registry "DOMAIN NAME SYSTEM
	PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-		PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-
	registry "TYPES", by defining two new types. Section 3 defines the		registry "TYPES", by defining two new types. Section 3 defines the
	skipping to change at page 23, line 40 ¶		skipping to change at page 24, line 21 ¶
	bits 0 - 6 are available for assignment.		bits 0 - 6 are available for assignment.
	Assignment of additional NSEC4PARAM Flags in this registry requires		Assignment of additional NSEC4PARAM Flags in this registry requires
	IETF Standards Action [RFC5226].		IETF Standards Action [RFC5226].
	Finally, this document creates a new IANA registry for NSEC4 hash		Finally, this document creates a new IANA registry for NSEC4 hash
	algorithms. This registry is named "DNSSEC NSEC4 Hash Algorithms".		algorithms. This registry is named "DNSSEC NSEC4 Hash Algorithms".
	The initial contents of this registry are:		The initial contents of this registry are:
	0 is Zero hashing.		0 is the Identity function.
	1 is SHA-1.		1 is SHA-1.
	2-255 Available for assignment.		2-255 Available for assignment.
	Assignment of additional NSEC4 hash algorithms in this registry		Assignment of additional NSEC4 hash algorithms in this registry
	requires IETF Standards Action [RFC5226].		requires IETF Standards Action [RFC5226].
	11. Security Considerations		12. Security Considerations
	This document does not introduce any new security issues beyond those		This document does not introduce any new security issues beyond those
	already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5155].		already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5155].
	12. Acknowledgements		13. Acknowledgements
	This document would not be possible without the help of Ed Lewis, Roy		This document would not be possible without the help of Ed Lewis, Roy
	Arends, Wouter Wijngaards, Karst Koymans, Marco Davids, Esther Makaay		Arends, Wouter Wijngaards, Karst Koymans, Mohan Parthasarathy, Marco
	and Antoin Verschuren.		Davids, Esther Makaay and Antoin Verschuren.
	This document was produced using the xml2rfc tool ([RFC2629]) and		This document was produced using the xml2rfc tool ([RFC2629]) and
	Pandoc2RFC ([Gieben11]).		Pandoc2rfc ([Gieben11]).
	13. Changelog		14. Changelog
	13.1. 00		14.1. 01
	o Initial document		o Clarification throughout the text (Mohan Parthasarathy);
	14. References		o Add section about empty non-terminals in NSEC, NSEC3 and NSEC4;
			o Rename Zero hashing to Identity function.
	14.1. Informative References		o No need for different ordering mechanisms: canonical ordering
			only.
			o Remove section on validator algorithm (already explained in
			RFC4035).
			14.2. 00
			o Initial document.
			15. References
			15.1. Informative References
	[Gieben11] Gieben, R., "Pandoc2RFC", September 2011,		[Gieben11] Gieben, R., "Pandoc2RFC", September 2011,
	<https://github.com/miekg/pandoc2rfc/>.		<https://github.com/miekg/pandoc2rfc/>.
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML",		[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML",
	RFC 2629, June 1999.		RFC 2629, June 1999.
	[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
	RFC 2672, August 1999.
	[RFC4592] Lewis, E., "The Role of Wildcards in the Domain		[RFC4592] Lewis, E., "The Role of Wildcards in the Domain
	Name System", RFC 4592, July 2006.		Name System", RFC 4592, July 2006.
	14.2. Normative References		[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in
			the DNS", RFC 6672, June 2012.
			15.2. Normative References
	[GiebenMekking11] Gieben, R. and W. Mekking, "Authenticated Denial		[GiebenMekking11] Gieben, R. and W. Mekking, "Authenticated Denial
	of Existence in the DNS", November 2011.		of Existence in the DNS", January 2012, <http://
			www.sidn.nl/fileadmin/docs/PDF-files_UK/
			wp-2011-0x01-v2.pdf>.
	[RFC1034] Mockapetris, P., "Domain names - concepts and		[RFC1034] Mockapetris, P., "Domain names - concepts and
	facilities", STD 13, RFC 1034, November 1987.		facilities", STD 13, RFC 1034, November 1987.
	[RFC1035] Mockapetris, P., "Domain names - implementation		[RFC1035] Mockapetris, P., "Domain names - implementation
	and specification", STD 13, RFC 1035,		and specification", STD 13, RFC 1035,
	November 1987.		November 1987.
	[RFC2119] Bradner, S., "Key words for use in RFCs to		[RFC2119] Bradner, S., "Key words for use in RFCs to
	Indicate Requirement Levels", BCP 14, RFC 2119,		Indicate Requirement Levels", BCP 14, RFC 2119,
	skipping to change at page 25, line 46 ¶		skipping to change at page 26, line 45 ¶
	[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka,		[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka,
	"DNS Security (DNSSEC) Hashed Authenticated Denial		"DNS Security (DNSSEC) Hashed Authenticated Denial
	of Existence", RFC 5155, March 2008.		of Existence", RFC 5155, March 2008.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
	Writing an IANA Considerations Section in RFCs",		Writing an IANA Considerations Section in RFCs",
	BCP 26, RFC 5226, May 2008.		BCP 26, RFC 5226, May 2008.
	[Schaeffer10] Schaeffer, Y., "NSEC3 Hash Performance",		[Schaeffer10] Schaeffer, Y., "NSEC3 Hash Performance",
	March 2010.		March 2010, <http://www.nlnetlabs.nl/downloads/
			publications/nsec3_hash_performance.pdf>.
	Appendix A. List of Hashed Owner Names		Appendix A. List of Hashed Owner Names
	The following owner names are used in this document. The hashed		The following owner names are used in this document. The hashed
	names are hashed with SHA1 using an empty salt and zero iterations.		names are hashed with SHA1 using an empty salt and zero iterations.
	+-----------------+----------------------------------+		+-----------------+----------------------------------+
	| Original Name | Hashed Name |		| Original Name | Hashed Name |
	+-----------------+----------------------------------+		+-----------------+----------------------------------+
	| example. | 3msev9usmd4br9s97v51r2tdvmr9iqo1 |		| example. | 3msev9usmd4br9s97v51r2tdvmr9iqo1 |
	skipping to change at page 26, line 40 ¶		skipping to change at page 27, line 40 ¶
	ns1 A 192.0.2.10		ns1 A 192.0.2.10
	;; secure delegation		;; secure delegation
	sd NS ns1.sd.example.		sd NS ns1.sd.example.
	DS 33694 253 2 ...		DS 33694 253 2 ...
	ns1.sd A 192.0.2.10		ns1.sd A 192.0.2.10
	;; unsecure delegation		;; unsecure delegation
	ud NS ns1.ud.example.		ud NS ns1.ud.example.
	ns1.ud A 192.0.2.10		ns1.ud A 192.0.2.10
	*.who TXT "Wildcard"		*.who TXT "Wildcard"
	B.2. Zero Hashing		B.2. Identity Function
	This is the same zone shown with Zero hashing. The RRSIG Signature		This is the same zone shown with the Identity function. The RRSIG
	field, the DNSKEY Public Key field and the DS Digest field are		Signature field, the DNSKEY Public Key field and the DS Digest field
	omitted. The RRSIG expiration and inception times are set to ".".		are omitted. The RRSIG expiration and inception times are set to
			".".
	$ORIGIN example.		$ORIGIN example.
	@ SOA ns1.example. bugs.example. 1 2 3 4 5		@ SOA ns1.example. bugs.example. 1 2 3 4 5
	RRSIG SOA 253 1 300 . . 39824 example. ...		RRSIG SOA 253 1 300 . . 39824 example. ...
	RRSIG NS 253 1 300 . . 39824 example. ...		RRSIG NS 253 1 300 . . 39824 example. ...
	RRSIG DNSKEY 253 1 300 . . 39824 example. ...		RRSIG DNSKEY 253 1 300 . . 39824 example. ...
	RRSIG NSEC4PARAM 253 1 3600 . . 39824 example. ...		RRSIG NSEC4PARAM 253 1 3600 . . 39824 example. ...
	RRSIG NSEC4 253 1 5 . . 39824 example. ...		RRSIG NSEC4 253 1 5 . . 39824 example. ...
	NS ns1.example.		NS ns1.example.
	DNSKEY 256 3 253 ...		DNSKEY 256 3 253 ...
	skipping to change at page 30, line 28 ¶		skipping to change at page 31, line 28 ¶
	;; Authority		;; Authority
	example. SOA ns1.example. bugs.example. 1 2 3 4 5		example. SOA ns1.example. bugs.example. 1 2 3 4 5
	example. RRSIG SOA 253 1 300 . . 39824 example. ...		example. RRSIG SOA 253 1 300 . . 39824 example. ...
	;; H(ns1.example) = m1o89lfdo9rrf2f8r8ss42d81d09v48m		;; H(ns1.example) = m1o89lfdo9rrf2f8r8ss42d81d09v48m
	m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. NSEC4 1 1 0 - (		m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. NSEC4 1 1 0 - (
	3msev9usmd4br9s97v51r2tdvmr9iqo1.example.		3msev9usmd4br9s97v51r2tdvmr9iqo1.example.
	A RRSIG )		A RRSIG )
	m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. RRSIG NSEC4 253 2 5 (		m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. RRSIG NSEC4 253 2 5 (
	. . 39824 example. ... )		. . 39824 example. ... )
	The query returned a NSEC4 RR that proves that the requested name		The query returned an NSEC4 RR that proves that the requested name
	exists ("ns1.example" hashes to "m1o89lfdo9rrf2f8r8ss42d81d09v48m"),		exists ("ns1.example" hashes to "m1o89lfdo9rrf2f8r8ss42d81d09v48m"),
	but the requested RR type does not exist (type MX is absent in the		but the requested RR type does not exist (type MX is absent in the
	type code list of the NSEC4 RR), and was not a CNAME (type CNAME is		type code list of the NSEC4 RR), and was not a CNAME (type CNAME is
	also absent in the type code list of the NSEC4 RR).		also absent in the type code list of the NSEC4 RR).
	C.3. Referral to an Opt-Out Unsigned Zone		C.3. Referral to an Opt-Out Unsigned Zone
	The NSEC4 RRs prove that nothing for this delegation was signed.		The NSEC4 RRs prove that nothing for this delegation was signed.
	There is no proof that the unsigned delegation exists.		There is no proof that the unsigned delegation exists.
	skipping to change at page 33, line 37 ¶		skipping to change at page 34, line 37 ¶
	TXT RRSIG )		TXT RRSIG )
	ht6ocje68mtm96jpes8olrlbf67jjvdu.example. RRSIG NSEC4 253 2 5 (		ht6ocje68mtm96jpes8olrlbf67jjvdu.example. RRSIG NSEC4 253 2 5 (
	. . 39824 example. ... )		. . 39824 example. ... )
	The query returned the NSEC4 RRs that prove that the requested data		The query returned the NSEC4 RRs that prove that the requested data
	does not exist and shows the types that do exist at the wildcard.		does not exist and shows the types that do exist at the wildcard.
	Authors' Addresses		Authors' Addresses
	R. (Miek) Gieben		R. (Miek) Gieben
	SIDN		SIDN Labs
	Meander 501		Meander 501
	Arnhem, 6825 MD		Arnhem, 6825 MD
	NL		NL
	Phone:		Phone:
	EMail: miek.gieben@sidn.nl		EMail: miek.gieben@sidn.nl
	URI: https://sidn.nl/		URI: https://sidn.nl/
	W. (Matthijs) Mekking		W. (Matthijs) Mekking
	NLnet Labs		NLnet Labs
	Science Park 400		Science Park 400
End of changes. 132 change blocks.
	239 lines changed or deleted		295 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/