< draft-ietf-dnsop-dns-zone-digest-04.txt		draft-ietf-dnsop-dns-zone-digest-05.txt >
	Internet Engineering Task Force D. Wessels		Internet Engineering Task Force D. Wessels
	Internet-Draft P. Barber		Internet-Draft P. Barber
	Intended status: Standards Track M. Weinberg		Intended status: Standards Track M. Weinberg
	Expires: August 24, 2020 Verisign		Expires: September 10, 2020 Verisign
	W. Kumari		W. Kumari
	Google		Google
	W. Hardaker		W. Hardaker
	USC/ISI		USC/ISI
	February 21, 2020		March 9, 2020
	Message Digest for DNS Zones		Message Digest for DNS Zones
	draft-ietf-dnsop-dns-zone-digest-04		draft-ietf-dnsop-dns-zone-digest-05
	Abstract		Abstract
	This document describes a protocol and new DNS Resource Record that		This document describes a protocol and new DNS Resource Record that
	can be used to provide a cryptographic message digest over DNS zone		can be used to provide a cryptographic message digest over DNS zone
	data. The ZONEMD Resource Record conveys the digest data in the zone		data. The ZONEMD Resource Record conveys the digest data in the zone
	itself. When a zone publisher includes an ZONEMD record, recipients		itself. When a zone publisher includes an ZONEMD record, recipients
	can verify the zone contents for accuracy and completeness. This		can verify the zone contents for accuracy and completeness. This
	provides assurance that received zone data matches published data,		provides assurance that received zone data matches published data,
	regardless of how the zone data has been transmitted and received.		regardless of how the zone data has been transmitted and received.
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 24, 2020.		This Internet-Draft will expire on September 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8		2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8
	2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8		2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8
	2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9		2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9
	2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9		2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9
	2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9		2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9
	2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9		2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9
	2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10		2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10
	3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10		3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10
	3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10		3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10
	3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10		3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10
	3.3. Canonical Format and Ordering . . . . . . . . . . . . . . 11		3.3. Canonical Format and Ordering . . . . . . . . . . . . . . 10
	3.3.1. Order of RRSets Having the Same Owner Name . . . . . 11		3.3.1. Order of RRSets Having the Same Owner Name . . . . . 11
	3.4. Inclusion/Exclusion Rules . . . . . . . . . . . . . . . . 11		3.4. Inclusion/Exclusion Rules . . . . . . . . . . . . . . . . 11
	3.5. Scheme-Specific Processing . . . . . . . . . . . . . . . 11		3.5. Scheme-Specific Processing . . . . . . . . . . . . . . . 11
	3.5.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12		3.5.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12
	3.6. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12		3.6. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12
	4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12		4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12
	4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 14
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14		5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14		5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14
	5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 14		5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15		6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15
	6.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 15		6.2. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 15
	6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 16		6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 16
	7. Performance Considerations . . . . . . . . . . . . . . . . . 16		7. Performance Considerations . . . . . . . . . . . . . . . . . 16
	7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 16		7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 16
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17		10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
	10.1. Authors' Implementation . . . . . . . . . . . . . . . . 17		10.1. Authors' Implementation . . . . . . . . . . . . . . . . 17
	10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 18		10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 18
	11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	12.1. Normative References . . . . . . . . . . . . . . . . . . 22		12.1. Normative References . . . . . . . . . . . . . . . . . . 23
	12.2. Informative References . . . . . . . . . . . . . . . . . 23		12.2. Informative References . . . . . . . . . . . . . . . . . 23
	Appendix A. Example Zones With Digests . . . . . . . . . . . . . 25		Appendix A. Example Zones With Digests . . . . . . . . . . . . . 25
	A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 25		A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 26
	A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 26		A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 26
	A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 26		A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 27
	A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 27		A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 28
	A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 30		A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	In the DNS, a zone is the collection of authoritative resource		In the DNS, a zone is the collection of authoritative resource
	records (RRs) sharing a common origin ([RFC7719]). Zones are often		records (RRs) sharing a common origin ([RFC8499]). Zones are often
	stored as files on disk in the so-called master file format		stored as files on disk in the so-called master file format
	[RFC1034]. Zones are generally distributed among name servers using		[RFC1034]. Zones are generally distributed among name servers using
	the AXFR [RFC5936], and IXFR [RFC1995] protocols. Zone files can		the AXFR [RFC5936], and IXFR [RFC1995] protocols. Zone files can
	also be distributed outside of the DNS, with such protocols as FTP,		also be distributed outside of the DNS, with such protocols as FTP,
	HTTP, rsync, and even via email. Currently there is no standard way		HTTP, rsync, and even via email. Currently there is no standard way
	to verify the authenticity of a stand-alone zone.		to verify the authenticity of a stand-alone zone.
	This document introduces a new RR type that serves as a cryptographic		This document introduces a new RR type that serves as a cryptographic
	message digest of the data in a zone. It allows a receiver of the		message digest of the data in a zone. It allows a receiver of the
	zone to verify the zone's authenticity, especially when used in		zone to verify the zone's authenticity, especially when used in
	skipping to change at page 5, line 18 ¶		skipping to change at page 5, line 18 ¶
	zone data upon restart cannot guarantee that the on-disk data has not		zone data upon restart cannot guarantee that the on-disk data has not
	been modified. For these reasons, it is preferable to secure the		been modified. For these reasons, it is preferable to secure the
	data itself.		data itself.
	Why not simply rely on DNSSEC, which provides certain data security		Why not simply rely on DNSSEC, which provides certain data security
	guarantees? Certainly for zones that are signed, a recipient could		guarantees? Certainly for zones that are signed, a recipient could
	validate all of the signed RRSets. Additionally, denial-of-existence		validate all of the signed RRSets. Additionally, denial-of-existence
	records can prove that RRSets have not been added or removed.		records can prove that RRSets have not been added or removed.
	However, not all RRSets in a zone are signed. The design of DNSSEC		However, not all RRSets in a zone are signed. The design of DNSSEC
	stipulates that delegations (non-apex NS records) are not signed, and		stipulates that delegations (non-apex NS records) are not signed, and
	neither are any glue records. Thus, changes to delegation and glue		neither are any glue records. ZONEMD protects the integrity of
	records cannot be detected by DNSSEC alone. Furthermore, zones that		delegation, glue, and other records that are not otherwise covered by
	employ NSEC3 with opt-out are susceptible to the removal or addition		DNSSEC. Furthermore, zones that employ NSEC3 with opt-out are
	of names between the signed nodes. Whereas DNSSEC is primarily		susceptible to the removal or addition of names between the signed
	designed to protect consumers of DNS response messages, this protocol		nodes. Whereas DNSSEC is primarily designed to protect consumers of
	is designed to protect consumers of zones.		DNS response messages, this protocol is designed to protect consumers
			of zones.
	There are existing tools and protocols that provide data security,		There are existing tools and protocols that provide data security,
	such as OpenPGP [RFC4880] and S/MIME [RFC3851]. In fact, the		such as OpenPGP [RFC4880] and S/MIME [RFC5751]. In fact, the
	internic.net site publishes PGP signatures along side the root zone		internic.net site publishes PGP signatures along side the root zone
	and other files available there. However, this is a detached		and other files available there. However, this is a detached
	signature with no strong association to the corresponding zone file		signature with no strong association to the corresponding zone file
	other than its timestamp. Non-detached signatures are, of course,		other than its timestamp. Non-detached signatures are, of course,
	possible, but these necessarily change the format of the file being		possible, but these necessarily change the format of the file being
	distributed. That is, a zone signed with OpenPGP or S/MIME no longer		distributed. That is, a zone signed with OpenPGP or S/MIME no longer
	looks like a DNS zone and could not directly be loaded into a name		looks like a DNS zone and could not directly be loaded into a name
	server. Once loaded the signature data is lost, so it does not		server. Once loaded the signature data is lost, so it does not
	survive further propagation.		survive further propagation.
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 12 ¶
	[RFC2535], omits the AXFR SIG, while at the same time introducing an		[RFC2535], omits the AXFR SIG, while at the same time introducing an
	IXFR SIG.		IXFR SIG.
	1.2. Design Overview		1.2. Design Overview
	This document introduces a new Resource Record type designed to		This document introduces a new Resource Record type designed to
	convey a message digest of the content of a zone. The digest is		convey a message digest of the content of a zone. The digest is
	calculated at the time of zone publication. Ideally the zone is		calculated at the time of zone publication. Ideally the zone is
	signed with DNSSEC to guarantee that any modifications of the digest		signed with DNSSEC to guarantee that any modifications of the digest
	can be detected. The procedures for digest calculation and DNSSEC		can be detected. The procedures for digest calculation and DNSSEC
	signing are similar (i.e., both require the same ordering of RRs) and		signing are similar. Both require data to be processed in a well-
	can be done in parallel.		defined order and format. In some cases it may be possible to
			perform DNSSEC signing and digest calculation in parallel.
	The zone digest is designed to be used on zones that are relatively		The zone digest is designed to be used on zones that are relatively
	stable and have infrequent updates. As currently specified, the		stable and have infrequent updates. As currently specified, the
	digest is re-calculated over the entire zone content each time. This		digest is re-calculated over the entire zone content each time. This
	specification does not provide an efficient mechanism for incremental		specification does not provide an efficient mechanism for incremental
	updates of zone data. It is, however, extensible so that future		updates of zone data. It is, however, extensible so that future
	schemes to support incremental zone digest algorithms (e.g. using		schemes to support incremental zone digest algorithms (e.g. using
	Merkle trees) can be accommodated.		Merkle trees) can be accommodated.
	It is expected that verification of a zone digest would be		It is expected that verification of a zone digest would be
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 32 ¶
	ICANN operates the Centralized Zone Data Service [CZDS], which is a		ICANN operates the Centralized Zone Data Service [CZDS], which is a
	repository of top-level domain zone files. Users request access to		repository of top-level domain zone files. Users request access to
	the system, and to individual zones, and are then able to download		the system, and to individual zones, and are then able to download
	zone data for certain uses. Adding a zone digest to these would		zone data for certain uses. Adding a zone digest to these would
	provide CZDS users with assurances that the data has not been		provide CZDS users with assurances that the data has not been
	modified. Note that ZONEMD could be added to CZDS zone data		modified. Note that ZONEMD could be added to CZDS zone data
	independently of the zone served by production name servers.		independently of the zone served by production name servers.
	1.3.5. General Purpose Comparison Check		1.3.5. General Purpose Comparison Check
	Since the zone digest does not depend on presentation format, it		Since the zone digest calculation does not depend on presentation
	could be used to compare multiple copies of a zone received from		format, it could be used to compare multiple copies of a zone
	different sources, or copies generated by different processes.		received from different sources, or copies generated by different
			processes.
	1.4. Requirements Language		1.4. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. The ZONEMD Resource Record		2. The ZONEMD Resource Record
	skipping to change at page 8, line 16 ¶		skipping to change at page 8, line 16 ¶
	[RFC7696] and rollovers. Each ZONEMD RR must specify a unique Scheme		[RFC7696] and rollovers. Each ZONEMD RR must specify a unique Scheme
	and Hash Algorithm tuple. It is recommended that a zone include only		and Hash Algorithm tuple. It is recommended that a zone include only
	one ZONEMD RR, unless the zone publisher is in the process of		one ZONEMD RR, unless the zone publisher is in the process of
	transitioning to a new Scheme or Hash Algorithm.		transitioning to a new Scheme or Hash Algorithm.
	2.1. Non-apex ZONEMD Records		2.1. Non-apex ZONEMD Records
	This specification utilizes ZONEMD RRs located at the zone apex.		This specification utilizes ZONEMD RRs located at the zone apex.
	Non-apex ZONEMD RRs are not forbidden, but have no meaning in this		Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
	specification. Non-apex ZONEMD RRs MUST NOT be used for		specification. Non-apex ZONEMD RRs MUST NOT be used for
	verification. Non-apex ZONEMD RRSets are treated like any other		verification.
	RRSet (which is to say they are included) during digest calculation.
			During digest calculation, non-apex ZONEMD RRs are treated like any
			other RRs. They are digested as-is and the RR is not replaced by a
			placeholder RR.
	Unless explicitly stated otherwise, "ZONEMD" always refers to apex		Unless explicitly stated otherwise, "ZONEMD" always refers to apex
	records throughout this document.		records throughout this document.
	2.2. ZONEMD RDATA Wire Format		2.2. ZONEMD RDATA Wire Format
	The ZONEMD RDATA wire format is encoded as follows:		The ZONEMD RDATA wire format is encoded as follows:
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	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
	skipping to change at page 10, line 18 ¶		skipping to change at page 10, line 18 ¶
	example.com. 86400 IN ZONEMD 2018031500 1 1 (		example.com. 86400 IN ZONEMD 2018031500 1 1 (
	FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE		FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
	7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )		7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
	3. Calculating the Digest		3. Calculating the Digest
	3.1. Add ZONEMD Placeholder		3.1. Add ZONEMD Placeholder
	In preparation for calculating the zone digest, any existing ZONEMD		In preparation for calculating the zone digest, any existing ZONEMD
	records at the zone apex are first deleted.		records (and covering RRSIGs) at the zone apex are first deleted.
	Prior to calculation of the digest, and prior to signing with DNSSEC,		Prior to calculation of the digest, and prior to signing with DNSSEC,
	a placeholder ZONEMD record is added to the zone apex. This serves		one or more placeholder ZONEMD records are added to the zone apex.
	two purposes: (1) it allows the digest to cover the Serial, Scheme,		This serves two purposes: (1) it allows the digest to cover the
	and Hash Algorithm fields, and (2) ensures that appropriate denial-		Serial, Scheme, and Hash Algorithm fields, and (2) ensures that
	of-existence (NSEC, NSEC3) records are created if the zone is signed		appropriate denial-of-existence (NSEC, NSEC3) records are created if
	with DNSSEC.		the zone is signed with DNSSEC. When multiple ZONEMD RRs are
			published in the zone, e.g., during an algorithm rollover, each must
			specify a unique Scheme and Hash Algorithm tuple.
	It is recommended that the TTL of the ZONEMD record match the TTL of		It is recommended that the TTL of the ZONEMD record match the TTL of
	the SOA.		the SOA.
	In the placeholder record, the Serial field is set to the current SOA		In the placeholder record, the Serial field is set to the current SOA
	Serial. The Scheme field is set to the value for the chosen		Serial. The Scheme field is set to the value for the chosen
	collation scheme. The Hash Algorithm field is set to the value for		collation scheme. The Hash Algorithm field is set to the value for
	the chosen hash algorithm. The Digest field is set to all zeroes and		the chosen hash algorithm. The Digest field is set to all zeroes and
	of length appropriate for the chosen hash algorithm.		of length appropriate for the chosen hash algorithm.
	If multiple digests are to be published in the zone, e.g., during an
	algorithm rollover, a placeholder record is added for each Scheme and
	Hash Algorithm.
	3.2. Optionally Sign the Zone		3.2. Optionally Sign the Zone
	Following addition of placeholder records, the zone may be signed		Following addition of placeholder records, the zone may be signed
	with DNSSEC. Note that when the digest calculation is complete, and		with DNSSEC. Note that when the digest calculation is complete, and
	the ZONEMD record is updated, the signature(s) for the ZONEMD RRSet		the ZONEMD record is updated, the signature(s) for the ZONEMD RRSet
	MUST be recalculated and updated as well. Therefore, the signer is		MUST be recalculated and updated as well. Therefore, the signer is
	not required to calculate a signature over the placeholder record at		not required to calculate a signature over the placeholder record at
	this step in the process, but it is harmless to do so.		this step in the process, but it is harmless to do so.
	3.3. Canonical Format and Ordering		3.3. Canonical Format and Ordering
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 12 ¶
	ordering of owner names, (2) ordering of RRSets with the same owner		ordering of owner names, (2) ordering of RRSets with the same owner
	name, and (3) ordering of RRs within an RRSet.		name, and (3) ordering of RRs within an RRSet.
	This specification adopts DNSSEC's canonical ordering for names		This specification adopts DNSSEC's canonical ordering for names
	(Section 6.1 of [RFC4034]), and canonical ordering for RRs within an		(Section 6.1 of [RFC4034]), and canonical ordering for RRs within an
	RRSet (Section 6.3 of [RFC4034]). It also adopts DNSSEC's canonical		RRSet (Section 6.3 of [RFC4034]). It also adopts DNSSEC's canonical
	RR form (Section 6.2 of [RFC4034]). However, since DNSSEC does not		RR form (Section 6.2 of [RFC4034]). However, since DNSSEC does not
	define a canonical ordering for RRSets having the same owner name,		define a canonical ordering for RRSets having the same owner name,
	that ordering is defined here.		that ordering is defined here.
			This specification adopts DNSSEC's canonical on-the-wire RR format
			(without name compression) as specified in [RFC4034]:
			RR(i) = owner | type | class | TTL | RDATA length | RDATA
			where "|" denotes concatenation.
	3.3.1. Order of RRSets Having the Same Owner Name		3.3.1. Order of RRSets Having the Same Owner Name
	For the purposes of calculating the zone digest, RRSets having the		For the purposes of calculating the zone digest, RRSets having the
	same owner name MUST be numerically ordered, in ascending order, by		same owner name MUST be numerically ordered, in ascending order, by
	their numeric RR TYPE.		their numeric RR TYPE.
	3.4. Inclusion/Exclusion Rules		3.4. Inclusion/Exclusion Rules
	When iterating over records in the zone, the following inclusion/		When iterating over records in the zone, the following inclusion/
	exclusion rules apply:		exclusion rules apply:
	skipping to change at page 12, line 14 ¶		skipping to change at page 12, line 14 ¶
	3.5.1. The SIMPLE Scheme		3.5.1. The SIMPLE Scheme
	For the SIMPLE scheme, the digest is calculated over the zone as a		For the SIMPLE scheme, the digest is calculated over the zone as a
	whole. This means that a change to a single RR in the zone requires		whole. This means that a change to a single RR in the zone requires
	iterating over all RRs in the zone to recalculate the digest. SIMPLE		iterating over all RRs in the zone to recalculate the digest. SIMPLE
	is a good choice for zones that are small and/or stable, but probably		is a good choice for zones that are small and/or stable, but probably
	not good for zones that are large and/or dynamic.		not good for zones that are large and/or dynamic.
	A zone digest using the SIMPLE scheme is calculated by concatenating		A zone digest using the SIMPLE scheme is calculated by concatenating
	the canonical on-the-wire form (without name compression) of all RRs		the canonical form of all RRs in the zone, in the order described in
	in the zone, in the order described in Section 3.3, subject to the		Section 3.3, subject to the inclusion/exclusion rules described in
	inclusion/exclusion rules described in Section 3.4, and then applying		Section 3.4, and then applying the SHA-384 algorithm:
	the SHA-384 algorithm:
	digest = hash( RR(1) | RR(2) | RR(3) | ... )		digest = hash( RR(1) | RR(2) | RR(3) | ... )
	where "|" denotes concatenation, and		where "|" denotes concatenation.
	RR(i) = owner | type | class | TTL | RDATA length | RDATA
	3.6. Update ZONEMD RR		3.6. Update ZONEMD RR
	Once a zone digest has been calculated, its value is then copied to		Once a zone digest has been calculated, the published ZONEMD record
	the Digest field of the placeholder ZONEMD record. Repeat for each		is finalised by inserting the digest into the placeholder ZONEMD.
	digest if multiple digests are to be published.		Repeat for each digest if multiple digests are to be published.
	If the zone is signed with DNSSEC, the appropriate RRSIG records		If the zone is signed with DNSSEC, the RRSIG record(s) covering the
	covering the ZONEMD RRSet MUST then be added or updated. Because the		ZONEMD RRSet MUST then be added or updated. Because the ZONEMD
	ZONEMD placeholder was added prior to signing, the zone will already		placeholder was added prior to signing, the zone will already have
	have the appropriate denial-of-existence (NSEC, NSEC3) records.		the appropriate denial-of-existence (NSEC, NSEC3) records.
	Some DNSSEC implementations (especially "online signing") might be		Some DNSSEC implementations (especially "online signing") might be
	designed such that the SOA serial number is updated whenever a new		designed such that the SOA serial number is updated whenever a new
	signature is made. To preserve the calculated digest, generation of		signature is made. To preserve the calculated digest, generation of
	an ZONEMD signature must not also result in a change to the SOA		an ZONEMD signature must not also result in a change to the SOA
	serial number. The ZONEMD RR and the matching SOA MUST be published		serial number. The ZONEMD RR and the matching SOA MUST be published
	at the same time.		at the same time.
	4. Verifying Zone Digest		4. Verifying Zone Digest
	The recipient of a zone that has a ZONEMD RR can verify the zone by		The recipient of a zone that has a ZONEMD RR can verify the zone by
	calculating the digest as follows:		calculating the digest as follows. If multiple ZONEMD RRs are
			present in the zone, e.g., during an algorithm rollover, a match
			using any one of the recipient's supported Schemes and Hash
			Algorithms is sufficient to verify the zone.
	1. The verifier MUST first determine whether or not to expect		1. The verifier MUST first determine whether or not to expect
	DNSSEC records in the zone. This can be done by examining		DNSSEC records in the zone. This can be done by examining
	locally configured trust anchors, or querying for (and		locally configured trust anchors, or querying for (and
	validating) DS RRs in the parent zone. For zones that are		validating) DS RRs in the parent zone. For zones that are
	provably insecure, or if DNSSEC validation can not be performed,		provably insecure, or if DNSSEC validation can not be performed,
	digest validation continues at step 4 below.		digest validation continues at step 4 below.
	2. For zones that are provably secure, the existence of the apex		2. For zones that are provably secure, the existence of the apex
	ZONEMD record MUST be verified. If the ZONEMD record provably		ZONEMD record MUST be verified. If the ZONEMD record provably
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 5 ¶
	10. The calculated digest is compared to the received digest stored		10. The calculated digest is compared to the received digest stored
	in the temporary location. If the two digest values match,		in the temporary location. If the two digest values match,
	verification is considered successful. Otherwise, verification		verification is considered successful. Otherwise, verification
	MUST NOT be considered successful.		MUST NOT be considered successful.
	11. The ZONEMD RR's RDATA is reset to the received Digest stored in		11. The ZONEMD RR's RDATA is reset to the received Digest stored in
	the temporary location. Thus, any downstream clients can		the temporary location. Thus, any downstream clients can
	similarly verify the zone.		similarly verify the zone.
	4.1. Verifying Multiple Digests
	If multiple digests are present in the zone, e.g., during an
	algorithm rollover, a match using any one of the recipient's
	supported Hash Algorithm algorithms is sufficient to verify the zone.
	Note that when multiple ZONEMD RRs are present in the zone, the		Note that when multiple ZONEMD RRs are present in the zone, the
	Digest field of each MUST be zeroed in step 8 above, even for		Digest field of each MUST be zeroed in step 8 above, even for
	unsupported Scheme and Hash Algorithm values.		unsupported Scheme and Hash Algorithm values.
	5. IANA Considerations		5. IANA Considerations
	5.1. ZONEMD RRtype		5.1. ZONEMD RRtype
	This document defines a new DNS RR type, ZONEMD, whose value 63 has		This document defines a new DNS RR type, ZONEMD, whose value 63 has
	been allocated by IANA from the "Resource Record (RR) TYPEs"		been allocated by IANA from the "Resource Record (RR) TYPEs"
	skipping to change at page 14, line 47 ¶		skipping to change at page 14, line 41 ¶
	| Value | Description | Mnemonic | Status | Reference |		| Value | Description | Mnemonic | Status | Reference |
	+---------+--------------------+----------+-----------+-------------+		+---------+--------------------+----------+-----------+-------------+
	| 0 | Reserved | RESERVED | N/A | N/A |		| 0 | Reserved | RESERVED | N/A | N/A |
	| 1 | Simple ZONEMD | SIMPLE | Mandatory | This |		| 1 | Simple ZONEMD | SIMPLE | Mandatory | This |
	| | collation | | | document |		| | collation | | | document |
	| 240-254 | Private Use | N/A | N/A | [RFC8126] |		| 240-254 | Private Use | N/A | N/A | [RFC8126] |
	+---------+--------------------+----------+-----------+-------------+		+---------+--------------------+----------+-----------+-------------+
	Table 1: ZONEMD Scheme Registry		Table 1: ZONEMD Scheme Registry
			The IANA policy for assigning new values to the ZONEMD Scheme
			registry shall be Specification Required, as described in [RFC8126].
	5.3. ZONEMD Hash Algorithm		5.3. ZONEMD Hash Algorithm
	This document asks IANA to create a new "ZONEMD Hash Algorithm"		This document asks IANA to create a new "ZONEMD Hash Algorithm"
	registry with initial contents as follows:		registry with initial contents as follows:
	+---------+----------------------+----------+-----------+-----------+		+---------+----------------------+----------+-----------+-----------+
	| Value | Description | Mnemonic | Status | Reference |		| Value | Description | Mnemonic | Status | Reference |
	+---------+----------------------+----------+-----------+-----------+		+---------+----------------------+----------+-----------+-----------+
	| 0 | Reserved | RESERVED | N/A | N/A |		| 0 | Reserved | RESERVED | N/A | N/A |
	| 1 | The SHA-384 hash | SHA384 | Mandatory | [RFC6234] |		| 1 | The SHA-384 hash | SHA384 | Mandatory | [RFC6234] |
	| | algorithm | | | |		| | algorithm | | | |
	| 240-254 | Private Use | N/A | N/A | [RFC8126] |		| 240-254 | Private Use | N/A | N/A | [RFC8126] |
	+---------+----------------------+----------+-----------+-----------+		+---------+----------------------+----------+-----------+-----------+
	Table 2: ZONEMD Hash Algorithm Registry		Table 2: ZONEMD Hash Algorithm Registry
			The IANA policy for assigning new values to the ZONEMD Hash Algorithm
			registry shall be Specification Required, as described in [RFC8126].
	6. Security Considerations		6. Security Considerations
	6.1. Attacks Against the Zone Digest		6.1. Attacks Against the Zone Digest
	The zone digest allows the receiver to verify that the zone contents		The zone digest allows the receiver to verify that the zone contents
	haven't been modified since the zone was generated/published.		haven't been modified since the zone was generated/published.
	Verification is strongest when the zone is also signed with DNSSEC.		Verification is strongest when the zone is also signed with DNSSEC.
	An attacker, whose goal is to modify zone content before it is used		An attacker, whose goal is to modify zone content before it is used
	by the victim, may consider a number of different approaches.		by the victim, may consider a number of different approaches.
	skipping to change at page 15, line 39 ¶		skipping to change at page 15, line 42 ¶
	The attacker might perform a downgrade attack by removing one or more		The attacker might perform a downgrade attack by removing one or more
	ZONEMD records. Such a removal is detectable only with DNSSEC		ZONEMD records. Such a removal is detectable only with DNSSEC
	validation and is why Section 4 talks about checking denial-of-		validation and is why Section 4 talks about checking denial-of-
	existence proofs in step 2 and signature validation in step 3.		existence proofs in step 2 and signature validation in step 3.
	The attacker might alter the Scheme, Hash Algorithm, or Digest fields		The attacker might alter the Scheme, Hash Algorithm, or Digest fields
	of the ZONEMD record. Such modifications are detectable only with		of the ZONEMD record. Such modifications are detectable only with
	DNSSEC validation.		DNSSEC validation.
	6.2. Attacks Utilizing the Zone Digest		6.2. Attacks Utilizing ZONEMD Queries
	Nothing in this specification prevents clients from making, and		Nothing in this specification prevents clients from making, and
	servers from responding to, ZONEMD queries. One might consider how		servers from responding to, ZONEMD queries. Servers SHOULD NOT
	well ZONEMD responses could be used in a distributed denial-of-		calculate zone digests dynamically (for each query) as this can be
	service amplification attack.		used as a CPU resource exhaustion attack.
	The ZONEMD RR is moderately sized, much like the DS RR. A single		One might consider how well ZONEMD responses could be used in a
	ZONEMD RR contributes approximately 40 to 65 octets to a DNS		distributed denial-of-service amplification attack. The ZONEMD RR is
	response, for currently defined digest types. Certainly other query		moderately sized, much like the DS RR. A single ZONEMD RR
	types result in larger amplification effects (i.e., DNSKEY).		contributes approximately 40 to 65 octets to a DNS response, for
			currently defined digest types. Certainly other RR types result in
			larger amplification effects (i.e., DNSKEY).
	6.3. Resilience and Fragility		6.3. Resilience and Fragility
	ZONEMD can be used to detect incomplete or corrupted zone data prior		ZONEMD can be used to detect incomplete or corrupted zone data prior
	to its use, thereby increasing resilience, but also introducing some		to its use, thereby increasing resilience, but also introducing some
	fragility. Publishers and consumers of zones containing ZONEMD		fragility. Publishers and consumers of zones containing ZONEMD
	records should be aware of these tradeoffs. While the intention is		records should be aware of these tradeoffs. While the intention is
	to secure the zone data, misconfigurations or implementation bugs are		to secure the zone data, misconfigurations or implementation bugs are
	generally indistinguishable from intentional tampering, and could		generally indistinguishable from intentional tampering, and could
	lead to service failures when verification is performed		lead to service failures when verification is performed
	skipping to change at page 17, line 21 ¶		skipping to change at page 17, line 21 ¶
	| 10000 - 99999 | 0.00602 |		| 10000 - 99999 | 0.00602 |
	| 100000 - 999999 | 0.00845 |		| 100000 - 999999 | 0.00845 |
	| 1000000 - 9999999 | 0.0108 |		| 1000000 - 9999999 | 0.0108 |
	| 10000000 - 99999999 | 0.0148 |		| 10000000 - 99999999 | 0.0148 |
	+---------------------+----------------+		+---------------------+----------------+
	For example, based on the above table, it takes approximately 0.13		For example, based on the above table, it takes approximately 0.13
	seconds to calculate a SIMPLE SHA384 digest for a zone with 22,000		seconds to calculate a SIMPLE SHA384 digest for a zone with 22,000
	RRs, and about 2.5 seconds for a zone with 300,000 RRs.		RRs, and about 2.5 seconds for a zone with 300,000 RRs.
			These benchmarks attempt to emulate a worst-case scenario and take
			into account the time required to canonicalize the zone for
			processing. Each of the 800+ zones were measured three times, and
			then averaged, with a different random sorting of the input data
			prior to each measurement.
	8. Privacy Considerations		8. Privacy Considerations
	This specification has no impacts on user privacy.		This specification has no impact on user privacy.
	9. Acknowledgments		9. Acknowledgments
	The authors wish to thank David Blacka, Scott Hollenbeck, and Rick		The authors wish to thank David Blacka, Scott Hollenbeck, and Rick
	Wilhelm for providing feedback on early drafts of this document.		Wilhelm for providing feedback on early drafts of this document.
	Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,		Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,
	Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul Hoffman, Evan		Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul Hoffman, Evan
	Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt Kaliski,		Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt Kaliski,
	Shane Kerr, Matt Larson, John Levine, Ed Lewis, Matt Pounsett, Mukund		Shane Kerr, Matt Larson, John Levine, Ed Lewis, Matt Pounsett, Mukund
	Sivaraman, Petr Spacek, Ondrej Sury, Willem Toorop, Florian Weimer,		Sivaraman, Petr Spacek, Ondrej Sury, Willem Toorop, Florian Weimer,
	skipping to change at page 22, line 32 ¶		skipping to change at page 22, line 37 ¶
	words.		words.
	o Clarified that all ZONEMD RRs, even for unsupported hash		o Clarified that all ZONEMD RRs, even for unsupported hash
	algorithms, must be zeroized during digest calculation.		algorithms, must be zeroized during digest calculation.
	o Added Resilience and Fragility to security considerations.		o Added Resilience and Fragility to security considerations.
	o Updated examples since changes in this version result in different		o Updated examples since changes in this version result in different
	hash values.		hash values.
			From -04 to -05:
			o Clarifications about non-apex and multiple ZONEMD RRs.
			o Clarifications about benchmark results.
			o Don't compute ZONEMD on-the-fly.
			o Specifciation Required for updates to ZONEMD protocol registries.
			o Other rewording based on WGLC feedback.
			o Updated RFC numbers for some references.
			o Use documentation IP addresses instead of loopback.
			o Updated examples in the appendix.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[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,
	<https://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, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
	<https://www.rfc-editor.org/info/rfc2181>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,		RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<https://www.rfc-editor.org/info/rfc4034>.		<https://www.rfc-editor.org/info/rfc4034>.
	[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,		(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	DOI 10.17487/RFC6234, May 2011,		DOI 10.17487/RFC6234, May 2011,
	<https://www.rfc-editor.org/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
	skipping to change at page 24, line 18 ¶		skipping to change at page 24, line 36 ¶
	[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.		[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
	Wellington, "Secret Key Transaction Authentication for DNS		Wellington, "Secret Key Transaction Authentication for DNS
	(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,		(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
	<https://www.rfc-editor.org/info/rfc2845>.		<https://www.rfc-editor.org/info/rfc2845>.
	[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures		[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
	( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September		( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
	2000, <https://www.rfc-editor.org/info/rfc2931>.		2000, <https://www.rfc-editor.org/info/rfc2931>.
	[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
	Extensions (S/MIME) Version 3.1 Message Specification",
	RFC 3851, DOI 10.17487/RFC3851, July 2004,
	<https://www.rfc-editor.org/info/rfc3851>.
	[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.		[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
	Thayer, "OpenPGP Message Format", RFC 4880,		Thayer, "OpenPGP Message Format", RFC 4880,
	DOI 10.17487/RFC4880, November 2007,		DOI 10.17487/RFC4880, November 2007,
	<https://www.rfc-editor.org/info/rfc4880>.		<https://www.rfc-editor.org/info/rfc4880>.
			[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
			Mail Extensions (S/MIME) Version 3.2 Message
			Specification", RFC 5751, DOI 10.17487/RFC5751, January
			2010, <https://www.rfc-editor.org/info/rfc5751>.
	[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol		[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
	(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,		(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
	<https://www.rfc-editor.org/info/rfc5936>.		<https://www.rfc-editor.org/info/rfc5936>.
	[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm		[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
	Agility and Selecting Mandatory-to-Implement Algorithms",		Agility and Selecting Mandatory-to-Implement Algorithms",
	BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,		BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
	<https://www.rfc-editor.org/info/rfc7696>.		<https://www.rfc-editor.org/info/rfc7696>.
	[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root		[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
	Servers by Running One on Loopback", RFC 7706,		Servers by Running One on Loopback", RFC 7706,
	DOI 10.17487/RFC7706, November 2015,		DOI 10.17487/RFC7706, November 2015,
	<https://www.rfc-editor.org/info/rfc7706>.		<https://www.rfc-editor.org/info/rfc7706>.
	[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>.
	[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
	and P. Hoffman, "Specification for DNS over Transport		and P. Hoffman, "Specification for DNS over Transport
	Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May		Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
	2016, <https://www.rfc-editor.org/info/rfc7858>.		2016, <https://www.rfc-editor.org/info/rfc7858>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
			[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
			Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
			January 2019, <https://www.rfc-editor.org/info/rfc8499>.
	[RootServers]		[RootServers]
	Root Server Operators, "Root Server Technical Operations",		Root Server Operators, "Root Server Technical Operations",
	July 2018, <https://www.root-servers.org/>.		July 2018, <https://www.root-servers.org/>.
	[RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones		[RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones
	(RPZ)", draft-vixie-dnsop-dns-rpz-00 (work in progress),		(RPZ)", draft-vixie-dnsop-dns-rpz-00 (work in progress),
	June 2018, <https://tools.ietf.org/html/draft-vixie-dnsop-		June 2018, <https://tools.ietf.org/html/draft-vixie-dnsop-
	dns-rpz-00>.		dns-rpz-00>.
	[ZoneDigestHackathon]		[ZoneDigestHackathon]
	skipping to change at page 25, line 40 ¶		skipping to change at page 26, line 15 ¶
	A.1. Simple EXAMPLE Zone		A.1. Simple EXAMPLE Zone
	Here, the EXAMPLE zone contains an SOA record, NS and glue records,		Here, the EXAMPLE zone contains an SOA record, NS and glue records,
	and a ZONEMD record.		and a ZONEMD record.
	example. 86400 IN SOA ns1 admin 2018031900 (		example. 86400 IN SOA ns1 admin 2018031900 (
	1800 900 604800 86400 )		1800 900 604800 86400 )
	86400 IN NS ns1		86400 IN NS ns1
	86400 IN NS ns2		86400 IN NS ns2
	86400 IN ZONEMD 2018031900 1 1 (		86400 IN ZONEMD 2018031900 1 1 (
	b3437dca3d6c9047		e12a0dd55a1dd1b8
	9f43d4bf0c1a805e		e29ec9b1d42d71ec
	fbfca88635df014f		09329da5f162f327
	04a1049368a23a77		e1eb4803947995ec
	577d896f0c58c5c7		f7c65aa566cf6cfd
	338aabc7aa4314b5 )		36a0caf8bdb03ac4 )
	ns1 3600 IN A 127.0.0.1		ns1 3600 IN A 203.0.113.63
	ns2 3600 IN AAAA ::1		ns2 3600 IN AAAA 2001:db8::63
	A.2. Complex EXAMPLE Zone		A.2. Complex EXAMPLE Zone
	Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR,		Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR,
	and one out-of-zone RR.		and one out-of-zone RR.
	example. 86400 IN SOA ns1 admin 2018031900 (		example. 86400 IN SOA ns1 admin 2018031900 (
	1800 900 604800 86400 )		1800 900 604800 86400 )
	86400 IN NS ns1		86400 IN NS ns1
	86400 IN NS ns2		86400 IN NS ns2
	86400 IN ZONEMD 2018031900 1 1 (		86400 IN ZONEMD 2018031900 1 1 (
	9c31e37bd2d97ad4		626637812169d7ab
	9ead67b3a44f267e		fcb24f13cb704f13
	a223cc70c1a0988d		b8a131fee1c3bc73
	49ac98da1b7ca1ed		29144fa5ec2608a4
	ede57661b6cefc52		1b596d41ff8c8310
	80d10d6b4b0b6cb1 )		b2897e73f6e521fc )
	ns1 3600 IN A 127.0.0.1		ns1 3600 IN A 203.0.113.63
	ns2 3600 IN AAAA ::1		ns2 3600 IN AAAA 2001:db8::63
	occluded.sub 7200 IN TXT "I'm occluded but must be digested"		occluded.sub 7200 IN TXT "I'm occluded but must be digested"
	sub 7200 IN NS ns1		sub 7200 IN NS ns1
	duplicate 300 IN TXT "I must be digested just once"		duplicate 300 IN TXT "I must be digested just once"
	duplicate 300 IN TXT "I must be digested just once"		duplicate 300 IN TXT "I must be digested just once"
	foo.test. 555 IN TXT "out-of-zone data must be excluded"		foo.test. 555 IN TXT "out-of-zone data must be excluded"
	non-apex 900 IN ZONEMD 2018031900 1 1 (		non-apex 900 IN ZONEMD 2018031900 1 1 (
	616c6c6f77656420		616c6c6f77656420
	6275742069676e6f		6275742069676e6f
	7265642e20616c6c		7265642e20616c6c
	6f77656420627574		6f77656420627574
	skipping to change at page 27, line 10 ¶		skipping to change at page 28, line 10 ¶
	private range (240-254). These additional private-range digests are		private range (240-254). These additional private-range digests are
	not verifiable, but note that their other fields (Serial, Scheme,		not verifiable, but note that their other fields (Serial, Scheme,
	Hash Algorithm) are included in the calculation of all ZONEMD		Hash Algorithm) are included in the calculation of all ZONEMD
	digests.		digests.
	example. 86400 IN SOA ns1 admin 2018031900 (		example. 86400 IN SOA ns1 admin 2018031900 (
	1800 900 604800 86400 )		1800 900 604800 86400 )
	example. 86400 IN NS ns1.example.		example. 86400 IN NS ns1.example.
	example. 86400 IN NS ns2.example.		example. 86400 IN NS ns2.example.
	example. 86400 IN ZONEMD 2018031900 1 1 (		example. 86400 IN ZONEMD 2018031900 1 1 (
	6a126e222407923d		366d22ea3bd8df44
	f70e7aa44d5e813b		0fa44b6213359d9b
	0b18b469b78d3d50		1f73bb9d8dd67a1b
	84cd3cbf24152eea		4c0bdf6f0b3657c5
	a68c00b6536bba2a		0316f770fbb03057
	1f2cab0fd03a8162 )		0c06adb87c121431 )
	example. 86400 IN ZONEMD 2018031900 1 240 (		example. 86400 IN ZONEMD 2018031900 1 240 (
	e2d523f654b9422a		e2d523f654b9422a
	96c5a8f44607bbee )		96c5a8f44607bbee )
	example. 86400 IN ZONEMD 2018031900 1 241 (		example. 86400 IN ZONEMD 2018031900 1 241 (
	5732dd91240611f8		5732dd91240611f8
	314adb6b4769bdd2 )		314adb6b4769bdd2 )
	example. 86400 IN ZONEMD 2018031900 1 242 (		example. 86400 IN ZONEMD 2018031900 1 242 (
	7c32e06779315c7d		7c32e06779315c7d
	81ba8c72f5cf9116		81ba8c72f5cf9116
	496b6395 )		496b6395 )
	skipping to change at page 27, line 38 ¶		skipping to change at page 28, line 38 ¶
	2e674e305b8d0d11		2e674e305b8d0d11
	3dfe0837 )		3dfe0837 )
	example. 86400 IN ZONEMD 2018031900 1 244 (		example. 86400 IN ZONEMD 2018031900 1 244 (
	e1846540e33a9e41		e1846540e33a9e41
	89792d18d5d131f6		89792d18d5d131f6
	05fc283e )		05fc283e )
	example. 86400 IN ZONEMD 2018031900 240 1 (		example. 86400 IN ZONEMD 2018031900 240 1 (
	e1846540e33a9e41		e1846540e33a9e41
	89792d18d5d131f6		89792d18d5d131f6
	05fc283e )		05fc283e )
	ns1.example. 3600 IN A 127.0.0.1		ns1.example. 3600 IN A 203.0.113.63
	ns2.example. 86400 IN TXT "This example has multiple digests"		ns2.example. 86400 IN TXT "This example has multiple digests"
	ns2.example. 3600 IN AAAA ::1		ns2.example. 3600 IN AAAA 2001:db8::63
	A.4. The URI.ARPA Zone		A.4. The URI.ARPA Zone
	The URI.ARPA zone retrieved 2018-10-21. Note this sample zone has		The URI.ARPA zone retrieved 2018-10-21. Note this sample zone has
	(expired) signatures, but no signature for the ZONEMD RR.		(expired) signatures, but no signature for the ZONEMD RR.
	; <<>> DiG 9.9.4 <<>> @lax.xfr.dns.icann.org uri.arpa axfr		; <<>> DiG 9.9.4 <<>> @lax.xfr.dns.icann.org uri.arpa axfr
	; (2 servers found)		; (2 servers found)
	;; global options: +cmd		;; global options: +cmd
	uri.arpa. 3600 IN SOA sns.dns.icann.org. (		uri.arpa. 3600 IN SOA sns.dns.icann.org. (
End of changes. 44 change blocks.
	106 lines changed or deleted		138 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/