< draft-vcelak-nsec5-05.txt		draft-vcelak-nsec5-06.txt >
	Network Working Group J. Vcelak		Network Working Group J. Vcelak
	Internet-Draft CZ.NIC		Internet-Draft CZ.NIC
	Intended status: Standards Track S. Goldberg		Intended status: Standards Track S. Goldberg
	Expires: January 04, 2018 Boston University		Expires: July 6, 2018 Boston University
	D. Papadopoulos		D. Papadopoulos
	University of Maryland		HKUST
	S. Huque		S. Huque
	Salesforce		Salesforce
	D. Lawrence		D. Lawrence
	Akamai Technologies		Akamai Technologies
	July 03, 2017		January 2, 2018
	NSEC5, DNSSEC Authenticated Denial of Existence		NSEC5, DNSSEC Authenticated Denial of Existence
	draft-vcelak-nsec5-05		draft-vcelak-nsec5-06
	Abstract		Abstract
	The Domain Name System Security Extensions (DNSSEC) introduced two		The Domain Name System Security Extensions (DNSSEC) introduced two
	resource records (RR) for authenticated denial of existence: the NSEC		resource records (RR) for authenticated denial of existence: the NSEC
	RR and the NSEC3 RR. This document introduces NSEC5 as an		RR and the NSEC3 RR. This document introduces NSEC5 as an
	alternative mechanism for DNSSEC authenticated denial of existence.		alternative mechanism for DNSSEC authenticated denial of existence.
	NSEC5 uses verifiable random functions (VRFs) to prevent offline		NSEC5 uses verifiable random functions (VRFs) to prevent offline
	enumeration of zone contents. NSEC5 also protects the integrity of		enumeration of zone contents. NSEC5 also protects the integrity of
	the zone contents even if an adversary compromises one of the		the zone contents even if an adversary compromises one of the
	skipping to change at page 2, line 8 ¶		skipping to change at page 2, line 5 ¶
	requests.		requests.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 04, 2018.		This Internet-Draft will expire on July 6, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 11 ¶
	8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 12		8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 12
	8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 13		8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 13
	8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 13		8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 13
	8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 14		8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 14
	8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 14		8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 14
	8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 14		8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 14
	9. Authoritative Server Considerations . . . . . . . . . . . . . 15		9. Authoritative Server Considerations . . . . . . . . . . . . . 15
	9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 15		9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 15
	9.1.1. Precomputing Closest Provable Encloser Proofs . . . . 16		9.1.1. Precomputing Closest Provable Encloser Proofs . . . . 16
	9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 17		9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 17
	9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 17		9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 18
	9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 18		9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 18
	9.5. Zones Using Unknown NSEC5 Algorithms . . . . . . . . . . 18		9.5. Zones Using Unknown NSEC5 Algorithms . . . . . . . . . . 18
	9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 18		9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 18
	10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 19		10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 19
	11. Validator Considerations . . . . . . . . . . . . . . . . . . 19		11. Validator Considerations . . . . . . . . . . . . . . . . . . 19
	11.1. Validating Responses . . . . . . . . . . . . . . . . . . 19		11.1. Validating Responses . . . . . . . . . . . . . . . . . . 19
	11.2. Validating Referrals to Unsigned Subzones . . . . . . . 20		11.2. Validating Referrals to Unsigned Subzones . . . . . . . 20
	11.3. Responses With Unknown NSEC5 Algorithms . . . . . . . . 20		11.3. Responses With Unknown NSEC5 Algorithms . . . . . . . . 20
	12. Special Considerations . . . . . . . . . . . . . . . . . . . 20		12. Special Considerations . . . . . . . . . . . . . . . . . . . 20
	12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 20		12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 20
	12.2. Private NSEC5 keys . . . . . . . . . . . . . . . . . . . 20		12.2. Private NSEC5 keys . . . . . . . . . . . . . . . . . . . 20
	12.3. Domain Name Length Restrictions . . . . . . . . . . . . 20		12.3. Domain Name Length Restrictions . . . . . . . . . . . . 21
	13. Implementation Status . . . . . . . . . . . . . . . . . . . . 21		13. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
	14. Performance Considerations . . . . . . . . . . . . . . . . . 21		14. Performance Considerations . . . . . . . . . . . . . . . . . 21
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 21		15. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	15.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 21		15.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 21
	15.2. Compromise of the Private NSEC5 Key . . . . . . . . . . 22		15.2. Compromise of the Private NSEC5 Key . . . . . . . . . . 22
	15.3. Key Length Considerations . . . . . . . . . . . . . . . 22		15.3. Key Length Considerations . . . . . . . . . . . . . . . 22
	15.4. NSEC5 Hash Collisions . . . . . . . . . . . . . . . . . 22		15.4. NSEC5 Hash Collisions . . . . . . . . . . . . . . . . . 22
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23		17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		18. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	18.1. Normative References . . . . . . . . . . . . . . . . . . 23		18.1. Normative References . . . . . . . . . . . . . . . . . . 24
	18.2. Informative References . . . . . . . . . . . . . . . . . 25		18.2. Informative References . . . . . . . . . . . . . . . . . 25
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 27
	A.1. Name Error Example . . . . . . . . . . . . . . . . . . . 27		A.1. Name Error Example . . . . . . . . . . . . . . . . . . . 27
	A.2. No Data Example . . . . . . . . . . . . . . . . . . . . . 28		A.2. No Data Example . . . . . . . . . . . . . . . . . . . . . 29
	A.3. Delegation to an Unsigned Zone in an Opt-Out span Example 29		A.3. Delegation to an Unsigned Zone in an Opt-Out span Example 30
	A.4. Wildcard Example . . . . . . . . . . . . . . . . . . . . 31		A.4. Wildcard Example . . . . . . . . . . . . . . . . . . . . 31
	A.5. Wildcard No Data Example . . . . . . . . . . . . . . . . 32		A.5. Wildcard No Data Example . . . . . . . . . . . . . . . . 32
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	1.1. Rationale		1.1. Rationale
	NSEC5 provides an alternative mechanism for authenticated denial of		NSEC5 provides an alternative mechanism for authenticated denial of
	existence for the DNS Security Extensions (DNSSEC). NSEC5 has two		existence for the DNS Security Extensions (DNSSEC). NSEC5 has two
	key security properties. First, NSEC5 protects the integrity of the		key security properties. First, NSEC5 protects the integrity of the
	zone contents even if an adversary compromises one of the		zone contents even if an adversary compromises one of the
	authoritative servers for the zone. Second, NSEC5 prevents offline		authoritative servers for the zone. Second, NSEC5 prevents offline
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 20 ¶
	| Unsigned | NO | NO | YES | NO |		| Unsigned | NO | NO | YES | NO |
	| NSEC | YES | YES | NO | NO |		| NSEC | YES | YES | NO | NO |
	| NSEC3 | YES | YES | NO | NO |		| NSEC3 | YES | YES | NO | NO |
	| NSEC3-WL | YES | NO | YES | YES |		| NSEC3-WL | YES | NO | YES | YES |
	| NSEC5 | YES | YES | YES | YES |		| NSEC5 | YES | YES | YES | YES |
	+----------+-------------+---------------+----------------+---------+		+----------+-------------+---------------+----------------+---------+
	NSEC5 prevents offline zone enumeration and also protects integrity		NSEC5 prevents offline zone enumeration and also protects integrity
	even if a zone's authoritative server is compromised. To do this,		even if a zone's authoritative server is compromised. To do this,
	NSEC5 replaces the unkeyed cryptographic hash function used in NSEC3		NSEC5 replaces the unkeyed cryptographic hash function used in NSEC3
	with a verifiable random function (VRF) [MRV99]. A VRF is the		with a verifiable random function (VRF) [I-D.goldbe-vrf] [MRV99]. A
	public-key version of a keyed cryptographic hash. Only the holder of		VRF is the public-key version of a keyed cryptographic hash. Only
	the private VRF key can compute the hash, but anyone with public VRF		the holder of the private VRF key can compute the hash, but anyone
	key can verify the correctness of the hash.		with public VRF key can verify the correctness of the hash.
	The public VRF key is distributed in an NSEC5KEY RR, similar to a		The public VRF key is distributed in an NSEC5KEY RR, similar to a
	DNSKEY RR, and is used to verify NSEC5 hash values. The private VRF		DNSKEY RR, and is used to verify NSEC5 hash values. The private VRF
	key is present on all authoritative servers for the zone, and is used		key is present on all authoritative servers for the zone, and is used
	to compute hash values. For every query that elicits a negative		to compute hash values. For every query that elicits a negative
	response, the authoritative server hashes the query on the fly using		response, the authoritative server hashes the query on the fly using
	the private VRF key, and also returns the corresponding precomputed		the private VRF key, and also returns the corresponding precomputed
	NSEC5 record(s). In contrast to the online signing approach		NSEC5 record(s). In contrast to the online signing approach
	[RFC7129], the private key that is present on all authoritative		[RFC7129], the private key that is present on all authoritative
	servers for NSEC5 cannot be used to modify the zone contents.		servers for NSEC5 cannot be used to modify the zone contents.
	Like online signing approaches, NSEC5 requires the authoritative		Like online signing approaches, NSEC5 requires the authoritative
	server to perform online public key cryptographic operations for		server to perform online public key cryptographic operations for
	every query eliciting a denying response. This is necessary; [nsec5]		every query eliciting a denying response. This is necessary; [nsec5]
	proved that online cryptography is required to prevent offline zone		proved that online cryptography is required to prevent offline zone
	enumeration while still protecting the integrity of zone contents		enumeration while still protecting the integrity of zone contents
	against network attacks.		against network attacks.
	NSEC5 is not intended to replace NSEC or NSEC3. It is an alternative		NSEC5 is not intended to replace NSEC or NSEC3. It is an alternative
	mechanism for authenticated denial of existence. This document		mechanism for authenticated denial of existence. This document
	specifies NSEC5 based on the FIPS 186-3 P-256 elliptic curve and on		specifies NSEC5 based on the VRFs in [I-D.goldbe-vrf] over the FIPS
	the Ed25519 elliptic curve. A formal cryptographic proof of security		186-3 P-256 elliptic curve and over the the Ed25519 elliptic curve.
	for elliptic curve (EC) NSEC5 is in [nsec5ecc].		A formal cryptographic proof of security for NSEC5 is in [nsec5ecc].
	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
	The reader is assumed to be familiar with the basic DNS and DNSSEC		The reader is assumed to be familiar with the basic DNS and DNSSEC
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 37 ¶
	This document defines the EC-P256-SHA256 NSEC5 algorithm as follows:		This document defines the EC-P256-SHA256 NSEC5 algorithm as follows:
	o The VRF is the EC-VRF algorithm using the EC-VRF-P256-SHA256		o The VRF is the EC-VRF algorithm using the EC-VRF-P256-SHA256
	ciphersuite specified in [I-D.goldbe-vrf].		ciphersuite specified in [I-D.goldbe-vrf].
	o The public key format to be used in the NSEC5KEY RR is defined in		o The public key format to be used in the NSEC5KEY RR is defined in
	Section 4 of [RFC6605] and thus is the same as the format used to		Section 4 of [RFC6605] and thus is the same as the format used to
	store ECDSA public keys in DNSKEY RRs.		store ECDSA public keys in DNSKEY RRs.
	[NOTE: This specification does not compress the elliptic curve		[NOTE: This specification does not compress the elliptic curve
	point used for the public key! But we do compress curve points in		point used for the public key, but we do compress curve points in
	every other place we use them with the P256 ECVRF. We could save		every other place we use them. The NSEC5KEY record can be shrunk
	31 octets in the NSEC5KEY record by encoding the public key with		by 31 additional octets by encoding the public key with point
	point compression!]		compression.]
	This document defines the EC-ED25519-SHA256 NSEC5 algorithm as		This document defines the EC-ED25519-SHA256 NSEC5 algorithm as
	follows:		follows:
	o The VRF is the EC-VRF algorithm using the EC-VRF-ED25519-SHA256		o The VRF is the EC-VRF algorithm using the EC-VRF-ED25519-SHA256
	ciphersuite specified in [I-D.goldbe-vrf].		ciphersuite specified in [I-D.goldbe-vrf].
	o The public key format to be used in the NSEC5KEY RR is defined in		o The public key format to be used in the NSEC5KEY RR is defined in
	Section 3 of [RFC8080] and thus is the same as the format used to		Section 3 of [RFC8080] and thus is the same as the format used to
	store Ed25519 public keys in DNSKEY RRs.		store Ed25519 public keys in DNSKEY RRs.
	skipping to change at page 12, line 24 ¶		skipping to change at page 12, line 24 ¶
	8. Types of Authenticated Denial of Existence with NSEC5		8. Types of Authenticated Denial of Existence with NSEC5
	This section summarizes all possible types of authenticated denial of		This section summarizes all possible types of authenticated denial of
	existence. For each type the following lists are included:		existence. For each type the following lists are included:
	1. Facts to prove: the minimum amount of information that an		1. Facts to prove: the minimum amount of information that an
	authoritative server must provide to a client to assure the		authoritative server must provide to a client to assure the
	client that the response content is valid.		client that the response content is valid.
	2. Authoritative server proofs: the names for which the NSEC5PROOF		2. Authoritative server proofs: the names for which the NSEC5PROOF
	RRs are synthesized and added into the response along the NSEC5		RRs are synthesized and added into the response along with the
	RRs matching or covering each such name. These records together		NSEC5 RRs matching or covering each such name. These records
	prove the listed facts.		together prove the listed facts.
	3. Validator checks: the individual checks that a validating server		3. Validator checks: the individual checks that a validating server
	is required to perform on a response. The response content is		is required to perform on a response. The response content is
	considered valid only if all of the checks pass.		considered valid only if all of the checks pass.
	If NSEC5 is said to match a domain name, the owner name of the NSEC5		If NSEC5 is said to match a domain name, the owner name of the NSEC5
	RR has to be equivalent to an NSEC5 hash of that domain name. If an		RR has to be equivalent to an NSEC5 hash of that domain name. If an
	NSEC5 RR is said to cover a domain name, the NSEC5 hash of the domain		NSEC5 RR is said to cover a domain name, the NSEC5 hash of the domain
	name must sort in canonical order between that NSEC5 RR's Owner Name		name must sort in canonical order between that NSEC5 RR's Owner Name
	and Next Hashed Owner Name.		and Next Hashed Owner Name.
	skipping to change at page 12, line 52 ¶		skipping to change at page 12, line 52 ¶
	Non-existence of the domain name that explictly matches the QNAME.		Non-existence of the domain name that explictly matches the QNAME.
	Non-existence of the wildcard that matches the QNAME.		Non-existence of the wildcard that matches the QNAME.
	Authoritative server proofs:		Authoritative server proofs:
	NSEC5PROOF for closest encloser and matching NSEC5 RR.		NSEC5PROOF for closest encloser and matching NSEC5 RR.
	NSEC5PROOF for next closer name and covering NSEC5 RR.		NSEC5PROOF for next closer name and covering NSEC5 RR.
	The QNAME does not fall into a delegation.
	The QNAME does not fall into a DNAME redirection.
	Validator checks:		Validator checks:
	Closest encloser is in the zone.		Closest encloser is in the zone.
	The NSEC5 RR matching the closest encloser has its Wildcard flag		The NSEC5 RR matching the closest encloser has its Wildcard flag
	cleared.		cleared.
	The NSEC5 RR matching the closest encloser does not have NS		The NSEC5 RR matching the closest encloser does not have NS
	without SOA in the Type Bit Map.		without SOA in the Type Bit Map.
	skipping to change at page 15, line 43 ¶		skipping to change at page 15, line 43 ¶
	RR MUST have the Wildcard flag set in the Flags field. Otherwise,		RR MUST have the Wildcard flag set in the Flags field. Otherwise,
	the flag MUST be cleared.		the flag MUST be cleared.
	o The zone apex MUST include an NSEC5KEY RRset containing a NSEC5		o The zone apex MUST include an NSEC5KEY RRset containing a NSEC5
	public key allowing verification of the current NSEC5 chain.		public key allowing verification of the current NSEC5 chain.
	The following steps describe one possible method to properly add		The following steps describe one possible method to properly add
	required NSEC5 related records into a zone. This is not the only		required NSEC5 related records into a zone. This is not the only
	such existing method.		such existing method.
	1. Select an algorithm for NSEC5. Generate the public and private		1. Select an algorithm for NSEC5 and generate the public and private
	NSEC5 keys.		NSEC5 keys.
	2. Add an NSEC5KEY RR into the zone apex containing the public NSEC5		2. Add an NSEC5KEY RR into the zone apex containing the public NSEC5
	key.		key.
	3. For each unique original domain name in the zone and each empty		3. For each unique original domain name in the zone and each empty
	non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names		non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names
	of unsigned delegations MAY be excluded.		of unsigned delegations MAY be excluded.
	A. The owner name of the NSEC5 RR is the NSEC5 hash of the		A. The owner name of the NSEC5 RR is the NSEC5 hash of the
	original owner name encoded in Base32hex without padding,		original owner name encoded in Base32hex without padding,
	prepended as a single label to the zone name.		prepended as a single label to the zone name.
	B. Set the Key Tag field to be the key tag corresponding to the		B. Set the Key Tag field to be the key tag corresponding to the
	public NSEC5 key.		public NSEC5 key.
	C. Clear the Flags field. If Opt-Out is being used, set the Opt-		C. Clear the Flags field. If Opt-Out is being used, set the
	Out flag. If there is a wildcard label directly descending from		Opt-Out flag. If there is a wildcard label directly descending
	the original domain name, set the Wildcard flag. Note that the		from the original domain name, set the Wildcard flag. Note that
	wildcard can be an empty non-terminal (i.e., the wildcard		the wildcard can be an empty non-terminal (i.e., the wildcard
	synthesis does not take effect and therefore the flag is not to		synthesis does not take effect and therefore the flag is not to
	be set).		be set).
	D. Set the Next Length field to a value determined by the used		D. Set the Next Length field to a value determined by the used
	NSEC5 algorithm. Leave the Next Hashed Owner Name field blank.		NSEC5 algorithm. Leave the Next Hashed Owner Name field blank.
	E. Set the Type Bit Maps field based on the RRsets present at the		E. Set the Type Bit Maps field based on the RRsets present at
	original owner name.		the original owner name.
	4. Sort the set of NSEC5 RRs into canonical order.		4. Sort the set of NSEC5 RRs into canonical order.
	5. For each NSEC5 RR, set the Next Hashed Owner Name field by using		5. For each NSEC5 RR, set the Next Hashed Owner Name field by using
	the owner name of the next NSEC5 RR in the canonical order. If		the owner name of the next NSEC5 RR in the canonical order. If
	the updated NSEC5 is the last NSEC5 RR in the chain, the owner		the updated NSEC5 is the last NSEC5 RR in the chain, the owner
	name of the first NSEC5 RR in the chain is used instead.		name of the first NSEC5 RR in the chain is used instead.
	The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA		The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA
	RR. Also the NSEC5 RRs SHOULD have the same TTL value as the SOA		RR. Also the NSEC5 RRs SHOULD have the same TTL value as the SOA
	minimum TTL field.		minimum TTL field.
	Notice that a use of Opt-Out is not indicated in the zone. This does		Notice that a use of Opt-Out is not indicated in the zone. This does
	not affect the ability of a server to prove insecure delegations.		not affect the ability of a server to prove insecure delegations.
	The Opt-Out MAY be part of the zone-signing tool configuration.		The Opt-Out MAY be part of the zone-signing tool configuration.
	9.1.1. Precomputing Closest Provable Encloser Proofs		9.1.1. Precomputing Closest Provable Encloser Proofs
	Per Section 8, the worst-case scenario when answering a negative		Per Section 8, the worst-case scenario when answering a negative
	query with NSEC5 requires authoritative server to respond with two		query with NSEC5 requires the authoritative server to respond with
	NSEC5PROOF RRs and two NSEC5 RRs. One pair of NSEC5PROOF and NSEC5		two NSEC5PROOF RRs and two NSEC5 RRs. One pair of NSEC5PROOF and
	RRs corresponds to the closest provable encloser, and the other pair		NSEC5 RRs corresponds to the closest provable encloser, and the other
	corresponds to the next closer name. The NSEC5PROOF corresponding to		pair corresponds to the next closer name. The NSEC5PROOF
	the next closer name MUST be computed on the fly by the authoritative		corresponding to the next closer name MUST be computed on the fly by
	server when responding to the query. However, the NSEC5PROOF		the authoritative server when responding to the query. However, the
	corresponding to the closest provable encloser MAY be precomputed and		NSEC5PROOF corresponding to the closest provable encloser MAY be
	stored as part of zone signing.		precomputed and stored as part of zone signing.
	Precomputing NSEC5PROOF RRs can halve the number of online		Precomputing NSEC5PROOF RRs can halve the number of online
	cryptographic computations required when responding to a negative		cryptographic computations required when responding to a negative
	query. NSEC5PROOF RRs MAY be precomputed as part of zone signing as		query. NSEC5PROOF RRs MAY be precomputed as part of zone signing as
	follows: For each NSEC5 RR, compute an NSEC5PROOF RR corresponding to		follows: For each NSEC5 RR, compute an NSEC5PROOF RR corresponding to
	the original owner name of the NSEC5 RR. The content of the		the original owner name of the NSEC5 RR. The content of the
	precomputed NSEC5PROOF record MUST be the same as if the record was		precomputed NSEC5PROOF record MUST be the same as if the record was
	computed on the fly when serving the zone. NSEC5PROOF records are		computed on the fly when serving the zone. NSEC5PROOF records are
	not part of the zone and SHOULD be stored separately from the zone		not part of the zone and SHOULD be stored separately from the zone
	file.		file.
	skipping to change at page 24, line 12 ¶		skipping to change at page 24, line 20 ¶
	National Institute for Standards and Technology, "Digital		National Institute for Standards and Technology, "Digital
	Signature Standard (DSS)", FIPS PUB 186-3, June 2009.		Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
	[I-D.goldbe-vrf]		[I-D.goldbe-vrf]
	Goldberg, S., Papadopoulos, D., and J. Vcelak, "Verifiable		Goldberg, S., Papadopoulos, D., and J. Vcelak, "Verifiable
	Random Functions (VRFs)", draft-goldbe-vrf-01 (work in		Random Functions (VRFs)", draft-goldbe-vrf-01 (work in
	progress), June 2017.		progress), June 2017.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<http://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
			November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[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,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,		[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
	"Dynamic Updates in the Domain Name System (DNS UPDATE)",		"Dynamic Updates in the Domain Name System (DNS UPDATE)",
	RFC 2136, DOI 10.17487/RFC2136, April 1997,		RFC 2136, DOI 10.17487/RFC2136, April 1997,
	<http://www.rfc-editor.org/info/rfc2136>.		<https://www.rfc-editor.org/info/rfc2136>.
	[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS		[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,		Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
	<http://www.rfc-editor.org/info/rfc2181>.		<https://www.rfc-editor.org/info/rfc2181>.
	[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS		[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
	NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,		NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
	<http://www.rfc-editor.org/info/rfc2308>.		<https://www.rfc-editor.org/info/rfc2308>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements", RFC		Rose, "DNS Security Introduction and Requirements",
	4033, March 2005.		RFC 4033, DOI 10.17487/RFC4033, March 2005,
			<https://www.rfc-editor.org/info/rfc4033>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, March 2005.		RFC 4034, DOI 10.17487/RFC4034, March 2005,
			<https://www.rfc-editor.org/info/rfc4034>.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, March 2005.		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
			<https://www.rfc-editor.org/info/rfc4035>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<http://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman		[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
	Groups for Use with IETF Standards", RFC 5114, DOI		Groups for Use with IETF Standards", RFC 5114,
	10.17487/RFC5114, January 2008,		DOI 10.17487/RFC5114, January 2008,
	<http://www.rfc-editor.org/info/rfc5114>.		<https://www.rfc-editor.org/info/rfc5114>.
	[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,
			<https://www.rfc-editor.org/info/rfc5155>.
	[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms		[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487		(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	/RFC6234, May 2011,		DOI 10.17487/RFC6234, May 2011,
	<http://www.rfc-editor.org/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
	[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital		[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
	Signature Algorithm (DSA) for DNSSEC", RFC 6605, April		Signature Algorithm (DSA) for DNSSEC", RFC 6605,
	2012.		DOI 10.17487/RFC6605, April 2012,
			<https://www.rfc-editor.org/info/rfc6605>.
	[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves		[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
	for Security", RFC 7748, DOI 10.17487/RFC7748, January		for Security", RFC 7748, DOI 10.17487/RFC7748, January
	2016, <http://www.rfc-editor.org/info/rfc7748>.		2016, <https://www.rfc-editor.org/info/rfc7748>.
	[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security		[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
	Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/		Algorithm (EdDSA) for DNSSEC", RFC 8080,
	RFC8080, February 2017,		DOI 10.17487/RFC8080, February 2017,
	<http://www.rfc-editor.org/info/rfc8080>.		<https://www.rfc-editor.org/info/rfc8080>.
	18.2. Informative References		18.2. Informative References
	[I-D.gieben-nsec4]		[I-D.gieben-nsec4]
	Gieben, R. and M. Mekking, "DNS Security (DNSSEC)		Gieben, R. and M. Mekking, "DNS Security (DNSSEC)
	Authenticated Denial of Existence", draft-gieben-nsec4-01		Authenticated Denial of Existence", draft-gieben-nsec4-01
	(work in progress), July 2012.		(work in progress), July 2012.
	[MRV99] Michali, S., Rabin, M., and S. Vadhan, "Verifiable Random
	Functions", in FOCS, 1999.
	[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
	Operational Practices, Version 2", RFC 6781, DOI 10.17487/
	RFC6781, December 2012,
	<http://www.rfc-editor.org/info/rfc6781>.
	[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
	Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
	February 2014, <http://www.rfc-editor.org/info/rfc7129>.
	[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", RFC 7719, DOI 10.17487/RFC7719, December
	2015, <http://www.rfc-editor.org/info/rfc7719>.
	[ldns-walk]		[ldns-walk]
	NLNetLabs, "ldns", 2015,		NLNetLabs, "ldns", 2015,
	<http://git.nlnetlabs.nl/ldns/tree/examples/ldns-walk.c>.		<http://git.nlnetlabs.nl/ldns/tree/examples/ldns-walk.c>.
			[MRV99] Michali, S., Rabin, M., and S. Vadhan, "Verifiable Random
			Functions", in FOCS, 1999.
	[nmap-nsec-enum]		[nmap-nsec-enum]
	Bond, J., "nmap: dns-nsec-enum", 2011, <https://nmap.org/		Bond, J., "nmap: dns-nsec-enum", 2011,
	nsedoc/scripts/dns-nsec-enum.html>.		<https://nmap.org/nsedoc/scripts/dns-nsec-enum.html>.
	[nmap-nsec3-enum]		[nmap-nsec3-enum]
	Nikolic, A. and J. Bond, "nmap: dns-nsec3-enum", 2011,		Nikolic, A. and J. Bond, "nmap: dns-nsec3-enum", 2011,
	<https://nmap.org/nsedoc/scripts/dns-nsec3-enum.html>.		<https://nmap.org/nsedoc/scripts/dns-nsec3-enum.html>.
	[nsec3gpu]		[nsec3gpu]
	Wander, M., Schwittmann, L., Boelmann, C., and T. Weis,		Wander, M., Schwittmann, L., Boelmann, C., and T. Weis,
	"GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network		"GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network
	Computing and Applications (NCA), 2014.		Computing and Applications (NCA), 2014.
	[nsec3map]		[nsec3map]
	anonion0, "nsec3map with John the Ripper plugin", 2015,		anonion0, "nsec3map with John the Ripper plugin", 2015,
	<https://github.com/anonion0/nsec3map.>.		<https://github.com/anonion0/nsec3map.>.
	[nsec3walker]		[nsec3walker]
	Bernstein, D., "Nsec3 walker", 2011,		Bernstein, D., "Nsec3 walker", 2011,
	<http://dnscurve.org/nsec3walker.html>.		<http://dnscurve.org/nsec3walker.html>.
	[nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L.,		[nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L.,
	Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC		Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC
	Zone Enumeration", in NDSS'15, July 2014, <https://		Zone Enumeration", in NDSS'15, July 2014,
	eprint.iacr.org/2014/582.pdf>.		<https://eprint.iacr.org/2014/582.pdf>.
	[nsec5ecc]		[nsec5ecc]
	Papadopoulos, D., Wessels, D., Huque, S., Vcelak, J.,		Papadopoulos, D., Wessels, D., Huque, S., Vcelak, J.,
	Naor, M., Reyzin, L., and S. Goldberg, "Can NSEC5 be		Naor, M., Reyzin, L., and S. Goldberg, "Can NSEC5 be
	Practical for DNSSEC Deployments?", in ePrint Cryptology		Practical for DNSSEC Deployments?", in ePrint Cryptology
	Archive 2017/099, February 2017, <https://eprint.iacr.org/		Archive 2017/099, February 2017,
	2017/099.pdf>.		<https://eprint.iacr.org/2017/099.pdf>.
			[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
			Operational Practices, Version 2", RFC 6781,
			DOI 10.17487/RFC6781, December 2012,
			<https://www.rfc-editor.org/info/rfc6781>.
			[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
			Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
			February 2014, <https://www.rfc-editor.org/info/rfc7129>.
			[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
			Terminology", RFC 7719, DOI 10.17487/RFC7719, December
			2015, <https://www.rfc-editor.org/info/rfc7719>.
	Appendix A. Examples		Appendix A. Examples
	We use small DNS zone to illustrate how denying responses are handled		We use a small DNS zone to illustrate how negative responses are
	with NSEC5. For brevity, the class is not shown (defaults to IN) and		handled with NSEC5. For brevity, the class is not shown (defaults to
	the SOA record is shortened, resulting in the following zone file:		IN) and the SOA record is shortened, resulting in the following zone
			file:
	example.org. SOA ( ... )		example.org. SOA ( ... )
	example.org. NS a.example.org		example.org. NS a.example.org
	a.example.org. A 192.0.2.1		a.example.org. A 192.0.2.1
	c.example.org. A 192.0.2.2		c.example.org. A 192.0.2.2
	c.example.org. TXT "c record"		c.example.org. TXT "c record"
	d.example.org. NS ns1.d.example.org		d.example.org. NS ns1.d.example.org
	skipping to change at page 27, line 33 ¶		skipping to change at page 28, line 5 ¶
	The server must prove the following facts:		The server must prove the following facts:
	o Existence of closest encloser c.example.org.		o Existence of closest encloser c.example.org.
	o Non-existence of wildcard at closest encloser *.c.example.org.		o Non-existence of wildcard at closest encloser *.c.example.org.
	o Non-existence of next closer b.c.example.org.		o Non-existence of next closer b.c.example.org.
	To do this, the server returns:		To do this, the server returns:
	;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 5937		;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 5937
	;; QUESTION SECTION:		;; QUESTION SECTION:
	;; a.b.c.example.org. IN A		;; a.b.c.example.org. IN A
	;; AUTHORITY SECTION:		;; AUTHORITY SECTION:
	example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (		example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (
	2010111214 21600 3600 604800 86400 )		2010111214 21600 3600 604800 86400 )
	example.org. 3600 IN RRSIG SOA 16 2 3600 (		example.org. 3600 IN RRSIG SOA 16 2 3600 (
	20170412024301 20170313024301 5137 example.org. rT231b1rH... )		20170412024301 20170313024301 5137 example.org. rT231b1rH... )
	This is an NSEC5PROOF RR for c.example.com. It's RDATA is the NSEC5		This is an NSEC5PROOF RR for c.example.com. It's RDATA is the NSEC5
	proof corresponding to c.example.com. (NSEC5 proofs are randomized		proof corresponding to c.example.com. (NSEC5 proofs are randomized
	values, because NSEC5 proof values are computed uses the EC-VRF from		values, because NSEC5 proof values are computed uses the EC-VRF from
	[I-D.goldbe-vrf].) Per Section 9.1.1, this NSEC5PROOF RR may be		[I-D.goldbe-vrf].) Per Section 9.1.1, this NSEC5PROOF RR may be
	precomputed.		precomputed.
	c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT...		c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT...
	This is a signed NSEC5 RR "matching" c.example.org, which proves the		This is a signed NSEC5 RR "matching" c.example.org, which proves the
	existence of closest encloser c.example.org. The NSEC5 RR has its		existence of closest encloser c.example.org. The NSEC5 RR has its
	owner name equal to the NSEC5 hash of c.example.org, which is O4K89V.		owner name equal to the NSEC5 hash of c.example.org, which is O4K89V.
	(NSEC5 hash values are deterministic given the public NSEC5 key.)		(NSEC5 hash values are deterministic given the public NSEC5 key.)
	The NSEC5 RR also has its Wildcard flag cleared (see the "0" after		The NSEC5 RR also has its Wildcard flag cleared (see the "0" after
	the key ID 48566). This proves the non-existence of the wildcard at		the key ID 48566). This proves the non-existence of the wildcard at
	the closest encloser *.c.example.com. NSEC5 RRs are precomputed.		the closest encloser *.c.example.com. NSEC5 RRs are precomputed.
	o4k89v.example.org. 86400 IN NSEC5 48566 0 0O49PI A TXT RRSIG		o4k89v.example.org. 86400 IN NSEC5 48566 0 0O49PI A TXT RRSIG
	o4k89v.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (		o4k89v.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
	20170412024301 20170313024301 5137 example.org. zDNTSMQNlz... )		20170412024301 20170313024301 5137 example.org. zDNTSMQNlz... )
	This is an NSEC5PROOF RR for b.c.example.org. It's RDATA is the		This is an NSEC5PROOF RR for b.c.example.org. It's RDATA is the
	NSEC5 proof corresponding to b.c.example.com. This NSEC5PROOF RR		NSEC5 proof corresponding to b.c.example.com. This NSEC5PROOF RR
	must be computed on-the-fly.		must be computed on the fly.
	b.c.example.org. 86400 IN NSEC5PROOF 48566 AuvvJqbUcEs8sCpY...		b.c.example.org. 86400 IN NSEC5PROOF 48566 AuvvJqbUcEs8sCpY...
	This is a signed NSEC5 RR "covering" b.c.example.org, which proves		This is a signed NSEC5 RR "covering" b.c.example.org, which proves
	the non-existence of the next closer name b.c.example.org The NSEC5		the non-existence of the next closer name b.c.example.org The NSEC5
	hash of b.c.example.org, which is AO5OF, sorts in canonical order		hash of b.c.example.org, which is AO5OF, sorts in canonical order
	between the "covering" NSEC5 RR's Owner Name (which is 0O49PI) and		between the "covering" NSEC5 RR's Owner Name (which is 0O49PI) and
	Next Hashed Owner Name (which is BAPROH).		Next Hashed Owner Name (which is BAPROH).
	0o49pi.example.org. 86400 IN NSEC5 48566 0 BAPROH (		0o49pi.example.org. 86400 IN NSEC5 48566 0 BAPROH (
	NS SOA RRSIG DNSKEY NSEC5KEY )		NS SOA RRSIG DNSKEY NSEC5KEY )
	0o49pi.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (		0o49pi.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
	20170412024301 20170313024301 5137 example.org. 4HT1uj1YlMzO)		20170412024301 20170313024301 5137 example.org. 4HT1uj1YlMzO)
	[TODO: Add discussion of CNAME and DNAME to the example?]		[TODO: Add discussion of CNAME and DNAME to the example?]
	A.2. No Data Example		A.2. No Data Example
	Consider a query for a type MX record for c.example.org.		Consider a query for a type MX record for c.example.org.
	The server must prove the following facts:		The server must prove the following facts:
	o Existence of c.example.org. for any type other than MX or CNAME		o Existence of c.example.org. for any type other than MX or CNAME
	To do this, the server returns:		To do this, the server returns:
	;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 38781		;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 38781
	;; QUESTION SECTION:		;; QUESTION SECTION:
	;; c.example.org. IN MX		;; c.example.org. IN MX
	;; AUTHORITY SECTION:		;; AUTHORITY SECTION:
	example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (		example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (
	2010111214 21600 3600 604800 86400 )		2010111214 21600 3600 604800 86400 )
	example.org. 3600 IN RRSIG SOA 16 2 3600 20170412024301 20170313024301 5137 example.org. /rT231b1rH/p		example.org. 3600 IN RRSIG SOA 16 2 3600 20170412024301 20170313024301 5137 example.org. /rT231b1rH/p
	This is an NSEC5PROOF RR for c.example.com. Its RDATA corresponds to		This is an NSEC5PROOF RR for c.example.com. Its RDATA corresponds to
	the NSEC5 proof for c.example.com. which is a randomized value. Per		the NSEC5 proof for c.example.com. which is a randomized value. Per
	Section 9.1.1, this NSEC5PROOF RR may be precomputed.		Section 9.1.1, this NSEC5PROOF RR may be precomputed.
	c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT		c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT
	This is a signed NSEC5 RR "matching" c.example.org. with CNAME and MX		This is a signed NSEC5 RR "matching" c.example.org. with CNAME and MX
	Type Bits cleared and its TXT Type Bit set. This NSEC5 RR has its		Type Bits cleared and its TXT Type Bit set. This NSEC5 RR has its
	owner name equal to the NSEC5 hash of c.example.org. This proves the		owner name equal to the NSEC5 hash of c.example.org. This proves the
	existence of c.example.org. for a type other than MX and CNAME.		existence of c.example.org. for a type other than MX and CNAME.
	NSEC5 RR are precomputed.		NSEC5 RR are precomputed.
	o4k89v.example.org. 86400 IN NSEC5 48566 0 0O49PI A TXT RRSIG		o4k89v.example.org. 86400 IN NSEC5 48566 0 0O49PI A TXT RRSIG
	o4k89v.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (		o4k89v.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
	20170412024301 20170313024301 5137 example.org. zDNTSMQNlz/J)		20170412024301 20170313024301 5137 example.org. zDNTSMQNlz/J)
	A.3. Delegation to an Unsigned Zone in an Opt-Out span Example		A.3. Delegation to an Unsigned Zone in an Opt-Out span Example
	Consider a query for a type A record for foo.d.example.org.		Consider a query for a type A record for foo.d.example.org.
	Here, d.example.org is a delegation to an unsigned zone, which sits		Here, d.example.org is a delegation to an unsigned zone, which lies
	within an Opt-Out span.		within an Opt-Out span.
	The server must prove the following facts:		The server must prove the following facts:
	o Non-existence of signature on next closer name d.example.org.		o Non-existence of signature on next closer name d.example.org.
	o Opt-out bit is set in NSEC5 record covering next closer name		o Opt-out bit is set in NSEC5 record covering next closer name
	d.example.org.		d.example.org.
	o Existence of closest provable encloser example.org		o Existence of closest provable encloser example.org
	skipping to change at page 30, line 13 ¶		skipping to change at page 30, line 31 ¶
	To do this, the server returns:		To do this, the server returns:
	;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 45866		;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 45866
	;; QUESTION SECTION:		;; QUESTION SECTION:
	;; foo.d.example.org. IN A		;; foo.d.example.org. IN A
	;; AUTHORITY SECTION:		;; AUTHORITY SECTION:
	d.example.org. 3600 IN NS ns1.d.example.org.		d.example.org. 3600 IN NS ns1.d.example.org.
	This is an NSEC5PROOF RR for d.example.org. It's RDATA is the NSEC5		This is an NSEC5PROOF RR for d.example.org. Its RDATA is the NSEC5
	proof corresponding to d.example.org. This NSEC5PROOF RR is computed		proof corresponding to d.example.org. This NSEC5PROOF RR is computed
	on the fly.		on the fly.
	d.example.org. 86400 IN NSEC5PROOF 48566 A9FpmeH79q7g6VNW		d.example.org. 86400 IN NSEC5PROOF 48566 A9FpmeH79q7g6VNW
	This is a signed NSEC5 RR "covering" d.example.org with its Opt-out		This is a signed NSEC5 RR "covering" d.example.org with its Opt-out
	bit set (see the "1" after the key ID 48566). The NSEC5 hash of		bit set (see the "1" after the key ID 48566). The NSEC5 hash of
	d.example.org (which is BLE8LR) sorts in canonical order between the		d.example.org (which is BLE8LR) sorts in canonical order between the
	"covering" NSEC5 RR's Owner Name (BAPROH) and Next Hashed Owner Name		"covering" NSEC5 RR's Owner Name (BAPROH) and Next Hashed Owner Name
	(JQBMG4). This proves that no signed RR exists for d.example.org,		(JQBMG4). This proves that no signed RR exists for d.example.org,
	but that the zone might contain a unsigned RR for a name whose NSEC5		but that the zone might contain a unsigned RR for a name whose NSEC5
	hash sorts in canonical order between BAPROH and JQBMG4.		hash sorts in canonical order between BAPROH and JQBMG4.
	baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG		baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG
	baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (		baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
	20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1)		20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1)
	This is an NSEC5PROOF RR for example.com. It's RDATA is the NSEC5		This is an NSEC5PROOF RR for example.com. It's RDATA is the NSEC5
	proof corresponding to example.com. Per Section 9.1.1, this		proof corresponding to example.com. Per Section 9.1.1, this
	NSEC5PROOF RR may be precomputed.		NSEC5PROOF RR may be precomputed.
	example.org. 86400 IN NSEC5PROOF 48566 AjwsPCJZ8zH/D0Tr		example.org. 86400 IN NSEC5PROOF 48566 AjwsPCJZ8zH/D0Tr
	This is a signed NSEC5 RR "matching" example.org which proves the		This is a signed NSEC5 RR "matching" example.org which proves the
	existence of a signed RRs for example.org. This NSEC5 RR has its		existence of a signed RRs for example.org. This NSEC5 RR has its
	owner name equal to the NSEC5 hash of example.org which is 0O49PI.		owner name equal to the NSEC5 hash of example.org which is 0O49PI.
	NSEC5 RR are precomputed.		NSEC5 RR are precomputed.
	0o49pi.example.org. 86400 IN NSEC5 48566 0 BAPROH (		0o49pi.example.org. 86400 IN NSEC5 48566 0 BAPROH (
	NS SOA RRSIG DNSKEY NSEC5KEY)		NS SOA RRSIG DNSKEY NSEC5KEY)
	0o49pi.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (		0o49pi.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
	20170412034216 20170313034216 5137 example.org. 4HT1uj1YlMzO)		20170412034216 20170313034216 5137 example.org. 4HT1uj1YlMzO)
	A.4. Wildcard Example		A.4. Wildcard Example
	Consider a query for a type TXT record for foo.a.example.org.		Consider a query for a type TXT record for foo.a.example.org.
	The server must prove the following facts:		The server must prove the following facts:
	o Existence of the TXT record for the wildcard *.a.example.org		o Existence of the TXT record for the wildcard *.a.example.org
	o Non-existence of the next closer name foo.a.example.org.		o Non-existence of the next closer name foo.a.example.org.
	skipping to change at page 31, line 25 ¶		skipping to change at page 31, line 38 ¶
	To do this, the server returns:		To do this, the server returns:
	;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 53731		;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 53731
	;; QUESTION SECTION:		;; QUESTION SECTION:
	;; foo.a.example.org. IN TXT		;; foo.a.example.org. IN TXT
	This is a signed TXT record for the wildcard at a.example.org (number		This is a signed TXT record for the wildcard at a.example.org (number
	of labels is set to 3 in the RRSIG record).		of labels is set to 3 in the RRSIG record).
	;; ANSWER SECTION:		;; ANSWER SECTION:
	foo.a.example.org. 3600 IN TXT "wildcard record"		foo.a.example.org. 3600 IN TXT "wildcard record"
	foo.a.example.org. 3600 IN RRSIG TXT 16 3 3600 (		foo.a.example.org. 3600 IN RRSIG TXT 16 3 3600 (
	20170412024301 20170313024301 5137 example.org. aeaLgZ8sk+98)		20170412024301 20170313024301 5137 example.org. aeaLgZ8sk+98)
	;; AUTHORITY SECTION:		;; AUTHORITY SECTION:
	example.org. 3600 IN NS a.example.org.		example.org. 3600 IN NS a.example.org.
	example.org. 3600 IN RRSIG NS 16 2 3600 (		example.org. 3600 IN RRSIG NS 16 2 3600 (
	20170412024301 20170313024301 5137 example.org. 8zuN0h2x5WyF)		20170412024301 20170313024301 5137 example.org. 8zuN0h2x5WyF)
	This is an NSEC5PROOF RR for foo.a.example.org. This NSEC5PROOF RR		This is an NSEC5PROOF RR for foo.a.example.org. This NSEC5PROOF RR
	must be computed on-the-fly.		must be computed on-the-fly.
	foo.a.example.org. 86400 IN NSEC5PROOF 48566 AjqF5FGGVso40Lda		foo.a.example.org. 86400 IN NSEC5PROOF 48566 AjqF5FGGVso40Lda
	This is a signed NSEC5 RR "covering" foo.a.example.org. The NSEC5		This is a signed NSEC5 RR "covering" foo.a.example.org. The NSEC5
	hash of foo.a.example.org is FORDMO and sorts in canonical order		hash of foo.a.example.org is FORDMO and sorts in canonical order
	between the NSEC5 RR's Owner Name (which is BAPROH) and Next Hashed		between the NSEC5 RR's Owner Name (which is BAPROH) and Next Hashed
	Owner Name (which is JQBMG4). This proves the non-existence of the		Owner Name (which is JQBMG4). This proves the non-existence of the
	next closer name foo.a.example.com. NSEC5 RRs are precomputed.		next closer name foo.a.example.com. NSEC5 RRs are precomputed.
	baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG		baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG
	baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (		baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
	20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1		20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1
	A.5. Wildcard No Data Example		A.5. Wildcard No Data Example
	Consider a query for a type MX record for foo.a.example.org.		Consider a query for a type MX record for foo.a.example.org.
	The server must prove the following facts:		The server must prove the following facts:
	o Existence of wildcard at closest encloser *.a.example.org. for any		o Existence of wildcard at closest encloser *.a.example.org. for any
	type other than MX or CNAME.		type other than MX or CNAME.
	o Non-existence of the next closer name foo.a.example.org.		o Non-existence of the next closer name foo.a.example.org.
	To do this, the server returns:		To do this, the server returns:
	;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17332		;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17332
	;; QUESTION SECTION:		;; QUESTION SECTION:
	;; foo.a.example.org. IN MX		;; foo.a.example.org. IN MX
	;; AUTHORITY SECTION:		;; AUTHORITY SECTION:
	example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (		example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (
	2010111214 21600 3600 604800 86400 )		2010111214 21600 3600 604800 86400 )
	example.org. 3600 IN RRSIG SOA 16 2 3600 (		example.org. 3600 IN RRSIG SOA 16 2 3600 (
	20170412024301 20170313024301 5137 example.org. /rT231b1rH/p )		20170412024301 20170313024301 5137 example.org. /rT231b1rH/p )
	This is an NSEC5PROOF RR for *.a.example.com, with RDATA equal to the		This is an NSEC5PROOF RR for *.a.example.com, with RDATA equal to the
	NSEC5 proof for *.a.example.com. Per Section 9.1.1, this NSEC5PROOF		NSEC5 proof for *.a.example.com. Per Section 9.1.1, this NSEC5PROOF
	RR may be precomputed.		RR may be precomputed.
	*.a.example.org. 86400 IN NSEC5PROOF 48566 Aq38RWWPhbs/vtih		*.a.example.org. 86400 IN NSEC5PROOF 48566 Aq38RWWPhbs/vtih
	This is a signed NSEC5 RR "matching" *.a.example.org with its CNAME		This is a signed NSEC5 RR "matching" *.a.example.org with its CNAME
	and MX Type Bits cleared and its TXT Type Bit set. This NSEC5 RR has		and MX Type Bits cleared and its TXT Type Bit set. This NSEC5 RR has
	its owner name equal to the NSEC5 hash of *.a.example.org. NSEC5 RRs		its owner name equal to the NSEC5 hash of *.a.example.org. NSEC5 RRs
	are precomputed.		are precomputed.
	mpu6c4.example.org. 86400 IN NSEC5 48566 0 O4K89V TXT RRSIG		mpu6c4.example.org. 86400 IN NSEC5 48566 0 O4K89V TXT RRSIG
	mpu6c4.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (		mpu6c4.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
	20170412024301 20170313024301 5137 example.org. m3I75ttcWwVC )		20170412024301 20170313024301 5137 example.org. m3I75ttcWwVC )
	This is an NSEC5PROOF RR for foo.a.example.com. This NSEC5PROOF RR		This is an NSEC5PROOF RR for foo.a.example.com. This NSEC5PROOF RR
	must be computed on-the-fly.		must be computed on-the-fly.
	foo.a.example.org. 86400 IN NSEC5PROOF 48566 AjqF5FGGVso40Lda		foo.a.example.org. 86400 IN NSEC5PROOF 48566 AjqF5FGGVso40Lda
	This is a signed NSEC5 RR "covering" foo.a.example.org. The NSEC5		This is a signed NSEC5 RR "covering" foo.a.example.org. The NSEC5
	hash of foo.a.example.org is FORDMO, and sorts in canonical order		hash of foo.a.example.org is FORDMO, and sorts in canonical order
	between this covering NSEC5 RR's Owner Name (which is BAPROH) and		between this covering NSEC5 RR's Owner Name (which is BAPROH) and
	Next Hashed Owner Name (which is JQBMG4). This proves the existence		Next Hashed Owner Name (which is JQBMG4). This proves the existence
	of the wildcard at closest encloser *.a.example.org. for any type		of the wildcard at closest encloser *.a.example.org. for any type
	other than MX or CNAME. NSEC5 RRs are precomputed.		other than MX or CNAME. NSEC5 RRs are precomputed.
	baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG		baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG
	baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (		baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
	20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1 )		20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1 )
	Appendix B. Change Log		Appendix B. Change Log
	Note to RFC Editor: if this document does not obsolete an existing		Note to RFC Editor: if this document does not obsolete an existing
	RFC, please remove this appendix before publication as an RFC.		RFC, please remove this appendix before publication as an RFC.
	pre 00 - initial version of the document submitted to mailing list		pre 00 - initial version of the document submitted to mailing list
	only		only
	00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA,		00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA,
	skipping to change at page 34, line 5 ¶		skipping to change at page 34, line 8 ¶
	04 - Edit Rationale, How NSEC5 Works, and Security Consideration		04 - Edit Rationale, How NSEC5 Works, and Security Consideration
	sections for clarity. Edit Zone Signing section, adding		sections for clarity. Edit Zone Signing section, adding
	precomputation of NSEC5PROOFs. Remove RSA-based NSEC5		precomputation of NSEC5PROOFs. Remove RSA-based NSEC5
	specification. Rewrite Performance Considerations and		specification. Rewrite Performance Considerations and
	Implementation Status sections.		Implementation Status sections.
	05 - Remove appendix specifying VRFs and add reference to		05 - Remove appendix specifying VRFs and add reference to
	[I-D.goldbe-vrf]. Add Appendix A.		[I-D.goldbe-vrf]. Add Appendix A.
			06 - Editorial changes. Minor updates to Section 8.1.
	Authors' Addresses		Authors' Addresses
	Jan Vcelak		Jan Vcelak
	CZ.NIC		CZ.NIC
	Milesovska 1136/5		Milesovska 1136/5
	Praha 130 00		Praha 130 00
	CZ		CZ
	EMail: jan.vcelak@nic.cz		EMail: jan.vcelak@nic.cz
	Sharon Goldberg		Sharon Goldberg
	Boston University		Boston University
	111 Cummington St, MCS135		111 Cummington St, MCS135
	Boston, MA 02215		Boston, MA 02215
	USA		USA
	EMail: goldbe@cs.bu.edu		EMail: goldbe@cs.bu.edu
	Dimitrios Papadopoulos		Dimitrios Papadopoulos
	University of Maryland		HKUST
	8223 Paint Branch Dr		Clearwater Bay
	College Park, MD 20740		Hong Kong
	USA
	EMail: dipapado@umd.edu		EMail: dipapado@ust.hk
	Shumon Huque		Shumon Huque
	Salesforce		Salesforce
	2550 Wasser Terr		2550 Wasser Terr
	Herndon, VA 20171		Herndon, VA 20171
	USA		USA
	EMail: shuque@gmail.com		EMail: shuque@gmail.com
	David C Lawrence		David C Lawrence
	Akamai Technologies		Akamai Technologies
	150 Broadway		150 Broadway
	Boston, MA 02142-1054		Boston, MA 02142-1054
	USA		USA
	EMail: tale@akamai.com		EMail: tale@akamai.com
End of changes. 88 change blocks.
	169 lines changed or deleted		175 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/