< draft-ietf-dnsop-dns-zone-digest-01.txt   draft-ietf-dnsop-dns-zone-digest-02.txt >
Internet Engineering Task Force D. Wessels Internet Engineering Task Force D. Wessels
Internet-Draft P. Barber Internet-Draft P. Barber
Intended status: Experimental M. Weinberg Intended status: Experimental M. Weinberg
Expires: March 8, 2020 Verisign Expires: April 30, 2020 Verisign
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
September 5, 2019 October 28, 2019
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-01 draft-ietf-dnsop-dns-zone-digest-02
Abstract Abstract
This document describes an experimental protocol and new DNS Resource This document describes an experimental protocol and new DNS Resource
Record that can be used to provide a message digest over DNS zone Record that can be used to provide a message digest over DNS zone
data. The ZONEMD Resource Record conveys the message digest data in data. The ZONEMD Resource Record conveys the message digest data in
the zone itself. When a zone publisher includes an ZONEMD record, the zone itself. When a zone publisher includes an ZONEMD record,
recipients can verify the zone contents for accuracy and recipients can verify the zone contents for accuracy and
completeness. This provides assurance that received zone data completeness. This provides assurance that received zone data
matches published data, regardless of how the zone data has been matches published data, regardless of how the zone data has been
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 March 8, 2020. This Internet-Draft will expire on April 30, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 40 skipping to change at page 2, line 40
1.3.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6 1.3.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. Providers, Secondaries, and Anycast . . . . . . . . . 6 1.3.2. Providers, Secondaries, and Anycast . . . . . . . . . 6
1.3.3. Response Policy Zones . . . . . . . . . . . . . . . . 7 1.3.3. Response Policy Zones . . . . . . . . . . . . . . . . 7
1.3.4. Centralized Zone Data Service . . . . . . . . . . . . 7 1.3.4. Centralized Zone Data Service . . . . . . . . . . . . 7
1.3.5. General Purpose Comparison Check . . . . . . . . . . 7 1.3.5. General Purpose Comparison Check . . . . . . . . . . 7
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7
2.1. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8 2.1. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8
2.1.1. The Serial Field . . . . . . . . . . . . . . . . . . 8 2.1.1. The Serial Field . . . . . . . . . . . . . . . . . . 8
2.1.2. The Digest Type Field . . . . . . . . . . . . . . . . 8 2.1.2. The Digest Type Field . . . . . . . . . . . . . . . . 8
2.1.3. The Reserved Field . . . . . . . . . . . . . . . . . 8 2.1.3. The Parameter Field . . . . . . . . . . . . . . . . . 8
2.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 9 2.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 9
2.2. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9 2.2. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9
2.3. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 9 2.3. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 9
3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 9 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 9
3.1. Canonical Format and Ordering . . . . . . . . . . . . . . 9 3.1. Canonical Format and Ordering . . . . . . . . . . . . . . 9
3.1.1. Order of RRSets Having the Same Owner Name . . . . . 10 3.1.1. Order of RRSets Having the Same Owner Name . . . . . 10
3.1.2. Duplicate RRs . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Duplicate RRs . . . . . . . . . . . . . . . . . . . . 10
3.2. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 3.2. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10
3.3. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10 3.3. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10
3.4. Calculate the Digest . . . . . . . . . . . . . . . . . . 11 3.4. Calculate the Digest . . . . . . . . . . . . . . . . . . 11
3.4.1. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11 3.4.1. SHA384-STABLE Calculation . . . . . . . . . . . . . . 11
3.4.2. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11
3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 11 3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12
4. Verifying Zone Message Digest . . . . . . . . . . . . . . . . 12 4. Verifying Zone Message Digest . . . . . . . . . . . . . . . . 12
4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 13 4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 13
5. Scope of Experimentation . . . . . . . . . . . . . . . . . . 13 5. Scope of Experimentation . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 13 6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14
6.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 14 6.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 14 7.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 14
7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 14 7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 15
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
10.1. Authors' Implementation . . . . . . . . . . . . . . . . 15 10.1. Authors' Implementation . . . . . . . . . . . . . . . . 15
10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 15 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 16
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 21 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 22
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 22 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 22
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 22 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 23
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 23 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 23
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 24 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 24
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 27 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 ([RFC7719]). 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
skipping to change at page 7, line 45 skipping to change at page 7, line 45
"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
This section describes the ZONEMD Resource Record, including its This section describes the ZONEMD Resource Record, including its
fields, wire format, and presentation format. The Type value for the fields, wire format, and presentation format. The Type value for the
ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of
the resource record consists of four fields: Serial, Digest Type, the resource record consists of four fields: Serial, Digest Type,
Reserved, and Digest. Parameter, and Digest.
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. specification.
A zone MAY contain multiple ZONEMD RRs to support algorithm agility A zone MAY contain multiple ZONEMD RRs to support algorithm agility
[RFC7696] and rollovers. Each ZONEMD RR MUST specify a unique Digest [RFC7696] and rollovers. Each ZONEMD RR MUST specify a unique Digest
Type. It is RECOMMENDED that a zone include only one ZONEMD RR, Type and Parameter tuple. It is RECOMMENDED that a zone include only
unless the zone publisher is in the process of transitioning to a new one ZONEMD RR, unless the zone publisher is in the process of
Digest Type. transitioning to a new Digest Type.
2.1. ZONEMD RDATA Wire Format 2.1. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial | | Serial |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type | Reserved | | | Digest Type | Parameter | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Digest | | Digest |
/ / / /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1. The Serial Field 2.1.1. The Serial Field
The Serial field is a 32-bit unsigned integer in network order. It The Serial field is a 32-bit unsigned integer in network order. It
is equal to the serial number from the zone's SOA record ([RFC1035] is equal to the serial number from the zone's SOA record ([RFC1035]
skipping to change at page 8, line 40 skipping to change at page 8, line 40
The zone's serial number is included here in order to make DNS The zone's serial number is included here in order to make DNS
response messages of type ZONEMD meaningful. Without the serial response messages of type ZONEMD meaningful. Without the serial
number, a stand-alone ZONEMD digest has no association to any number, a stand-alone ZONEMD digest has no association to any
particular instance of a zone. particular instance of a zone.
2.1.2. The Digest Type Field 2.1.2. The Digest Type Field
The Digest Type field is an 8-bit unsigned integer that identifies The Digest Type field is an 8-bit unsigned integer that identifies
the algorithm used to construct the digest. the algorithm used to construct the digest.
At the time of this writing, SHA384, with value 1, is the only At the time of this writing, SHA384-STABLE, with value 1, is the only
standardized Digest Type defined for ZONEMD records. The Digest Type standardized Digest Type defined for ZONEMD records. The Digest Type
registry is further described in Section 6. registry is further described in Section 6.
Digest Type values 240-254 are allocated for Private Use as described Digest Type values 240-254 are allocated for Private Use as described
in [RFC8126]. in [RFC8126].
2.1.3. The Reserved Field 2.1.3. The Parameter Field
The Reserved field is an 8-bit unsigned integer, which is always set The Parameter field is an 8-bit unsigned integer whose meaning
to zero. This field is reserved for future work to support efficient depends on the Digest Type in use. For SHA384-STABLE, the Parameter
incremental updates. field plays no role in digest calculation or verification.
2.1.4. The Digest Field 2.1.4. The Digest Field
The Digest field is a variable-length sequence of octets containing The Digest field is a variable-length sequence of octets containing
the message digest. The Digest field MUST NOT be empty. Section 3 the message digest. The Digest field MUST NOT be empty. Section 3
describes how to calculate the digest for a zone. Section 4 describes how to calculate the digest for a zone. Section 4
describes how to use the digest to verify the contents of a zone. describes how to use the digest to verify the contents of a zone.
2.2. ZONEMD Presentation Format 2.2. ZONEMD Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
The Serial field MUST be represented as an unsigned decimal integer. The Serial field MUST be represented as an unsigned decimal integer.
The Digest Type field MUST be represented as an unsigned decimal The Digest Type field MUST be represented as an unsigned decimal
integer. integer.
The Reserved field MUST be represented as an unsigned decimal integer The Parameter field MUST be represented as an unsigned decimal
set to zero. integer.
The Digest MUST be represented as a sequence of case-insensitive The Digest MUST be represented as a sequence of case-insensitive
hexadecimal digits. Whitespace is allowed within the hexadecimal hexadecimal digits. Whitespace is allowed within the hexadecimal
text. text.
2.3. ZONEMD Example 2.3. ZONEMD Example
The following example shows a ZONEMD RR. The following example shows a ZONEMD RR.
example.com. 86400 IN ZONEMD 2018031500 1 0 ( example.com. 86400 IN ZONEMD 2018031500 1 0 (
FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )
3. Calculating the Digest 3. Calculating the Digest
3.1. Canonical Format and Ordering 3.1. Canonical Format and Ordering
Calculation of the zone digest REQUIRES the RRs in a zone to be Calculation of the zone digest REQUIRES RRs to be processed in a
processed in a consistent format and ordering. Correct ordering of consistent format and ordering. Correct ordering depends on (1)
the zone depends on (1) ordering of owner names in the zone, (2) ordering of owner names, (2) ordering of RRSets with the same owner
ordering of RRSets with the same owner name, and (3) ordering of RRs name, and (3) ordering of RRs within an RRSet.
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.
3.1.1. Order of RRSets Having the Same Owner Name 3.1.1. Order of RRSets Having the Same Owner Name
skipping to change at page 10, line 26 skipping to change at page 10, line 26
MUST NOT be included in the calculation of a zone digest. MUST NOT be included in the calculation of a zone digest.
3.2. Add ZONEMD Placeholder 3.2. 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 MUST first be deleted. records at the zone apex MUST first be 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 MUST be added to the zone apex. This a placeholder ZONEMD record MUST be added to the zone apex. This
serves two purposes: (1) it allows the digest to cover the Serial, serves two purposes: (1) it allows the digest to cover the Serial,
Digest Type, and Reserved field values, and (2) ensures that Digest Type, and Parameter field values, and (2) ensures that
appropriate denial-of-existence (NSEC, NSEC3) records are created if appropriate denial-of-existence (NSEC, NSEC3) records are created if
the zone is signed with DNSSEC. the zone is signed with DNSSEC.
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 MUST be set to the In the placeholder record, the Serial field MUST be set to the
current SOA Serial. The Digest Type field MUST be set to the value current SOA Serial. The Digest Type field MUST be set to the value
for the chosen digest algorithm. The Reserved field MUST be set to for the chosen digest algorithm. The Parameter field is set to a
zero. The Digest field MUST be set to all zeroes and of length value whose meaning depends on the Digest Type. The Digest field
appropriate for the chosen digest algorithm. MUST be set to all zeroes and of length appropriate for the chosen
digest algorithm.
If multiple digests are to be published in the zone, e.g., during an If multiple digests are to be published in the zone, e.g., during an
algorithm rollover, there MUST be one placeholder record for each algorithm rollover, there MUST be one placeholder record for each
Digest Type. Digest Type.
3.3. Optionally Sign the Zone 3.3. 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.4. Calculate the Digest 3.4. Calculate the Digest
The digest calculation details vary depending upon the Digest Type.
This document describes digest calculation for SHA384-STABLE only.
Digest calculation for additional types may be defined in future
updates to this document.
3.4.1. SHA384-STABLE Calculation
The Parameter field is not used in the calculation of SHA384-STABLE
message digets. The Parameter field SHOULD be set to zero in
SHA384-STABLE placeholder records.
The zone digest is calculated by concatenating the canonical on-the- The zone digest is calculated by concatenating the canonical on-the-
wire form (without name compression) of all RRs in the zone, in the wire form (without name compression) of all RRs in the zone, in the
order described above, subject to the inclusion/exclusion rules order described above, subject to the inclusion/exclusion rules
described below, and then applying the digest algorithm: described below, and then applying the SHA384 digest algorithm
[RFC6605]:
digest = digest_algorithm( RR(1) | RR(2) | RR(3) | ... ) digest = SHA384( RR(1) | RR(2) | RR(3) | ... )
where "|" denotes concatenation, and where "|" denotes concatenation, and
RR(i) = owner | type | class | TTL | RDATA length | RDATA RR(i) = owner | type | class | TTL | RDATA length | RDATA
3.4.1. Inclusion/Exclusion Rules 3.4.2. Inclusion/Exclusion Rules
When calculating the digest, the following inclusion/exclusion rules When calculating the digest, the following inclusion/exclusion rules
apply: apply:
o All records in the zone, including glue records, MUST be included. o All records in the zone, including glue records, MUST be included.
o Occluded data ([RFC5936] Section 3.5) MUST be included. o Occluded data ([RFC5936] Section 3.5) MUST be included.
o Duplicate RRs with equal owner, class, type, and RDATA MUST NOT be o Duplicate RRs with equal owner, class, type, and RDATA MUST NOT be
included. included.
o The placeholder ZONEMD RR(s) MUST be included. o The placeholder ZONEMD RR(s) MUST be included.
o If the zone is signed, DNSSEC RRs MUST be included, except: o If the zone is signed, DNSSEC RRs MUST be included, except:
o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG
will be updated after all digests have been calculated. will be updated after all digests have been calculated.
3.5. Update ZONEMD RR 3.5. Update ZONEMD RR
Once the zone digest has been calculated, its value is then copied to Once a zone digest has been calculated, its value is then copied to
the Digest field of the ZONEMD record. the Digest field of the placeholder ZONEMD record. 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 appropriate RRSIG records
covering the ZONEMD RRSet MUST then be added or updated. Because the covering the ZONEMD RRSet MUST then be added or updated. Because the
ZONEMD placeholder was added prior to signing, the zone will already ZONEMD placeholder was added prior to signing, the zone will already
have the appropriate denial-of-existence (NSEC, NSEC3) records. have the appropriate denial-of-existence (NSEC, NSEC3) records.
Some implementations of incremental DNSSEC signing might update the Some implementations of incremental DNSSEC signing might update the
zone's serial number for each resigning. However, to preserve the zone's serial number for each resigning. However, to preserve the
calculated digest, generation of the ZONEMD signature at this time calculated digest, generation of the ZONEMD signature at this time
MUST NOT also result in a change of the SOA serial number. MUST NOT also result in a change of the SOA serial number.
skipping to change at page 12, line 27 skipping to change at page 12, line 43
ZONEMD record MUST be verified. If the ZONEMD record provably ZONEMD record MUST be verified. If the ZONEMD record provably
does not exist, digest verification cannot be done. If the does not exist, digest verification cannot be done. If the
ZONEMD record does provably exist, but is not found in the zone, ZONEMD record does provably exist, but is not found in the zone,
digest verification MUST NOT be considered successful. digest verification MUST NOT be considered successful.
3. For zones that are provably secure, the SOA and ZONEMD RRSets 3. For zones that are provably secure, the SOA and ZONEMD RRSets
MUST have valid signatures, chaining up to a trust anchor. If MUST have valid signatures, chaining up to a trust anchor. If
DNSSEC validation of the SOA or ZONEMD records fails, digest DNSSEC validation of the SOA or ZONEMD records fails, digest
verification MUST NOT be considered successful. verification MUST NOT be considered successful.
4. If the zone contains more than one apex ZONEMD RR, digest 4. If the ZONEMD RRSet contains more than one RR with the same
verification MUST NOT be considered successful. Digest Type and Paremter, digest verification MUST NOT be
considered successful.
5. The SOA Serial field MUST exactly match the ZONEMD Serial field. 5. The SOA Serial field MUST exactly match the ZONEMD Serial field.
If the fields to not match, digest verification MUST NOT be If the fields to not match, digest verification MUST NOT be
considered successful. considered successful.
6. The ZONEMD Digest Type field MUST be checked. If the verifier 6. The ZONEMD Digest Type field MUST be checked. If the verifier
does not support the given digest type, it SHOULD report that does not support the given digest type, it SHOULD report that
the zone digest could not be verified due to an unsupported the zone digest could not be verified due to an unsupported
algorithm. algorithm.
7. The Reserved field MUST be checked. If the Reserved field value 7. The received Digest Type and Digest values are copied to a
is not zero, verification MUST NOT be considered successful.
8. The received Digest Type and Digest values are copied to a
temporary location. temporary location.
9. The ZONEMD RR's RDATA is reset to the placeholder values 8. The ZONEMD RR's RDATA is reset to the placeholder values
described in Section 3.2. described in Section 3.2.
10. The zone digest is computed over the zone data as described in 9. The zone digest is computed over the zone data as described in
Section 3.4. Section 3.4.
11. 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.
12. The ZONEMD RR's RDATA is reset to the received Digest Type and 11. The ZONEMD RR's RDATA is reset to the received Digest Type and
Digest stored in the temporary location. Thus, any downstream Digest stored in the temporary location. Thus, any downstream
clients can similarly verify the zone. clients can similarly verify the zone.
4.1. Verifying Multiple Digests 4.1. Verifying Multiple Digests
If multiple digests are present in the zone, e.g., during an If multiple digests are present in the zone, e.g., during an
algorithm rollover, a match using any one of the recipient's algorithm rollover, a match using any one of the recipient's
supported Digest Type algorithms is sufficient to verify the zone. supported Digest Type algorithms is sufficient to verify the zone.
5. Scope of Experimentation 5. Scope of Experimentation
This memo is published as an Experimental RFC. The purpose of the This memo is published as an Experimental RFC. The purpose of the
experimental period is to provide the community time to analyze and experimental period is to provide the community time to analyze and
evaluate the methods defined in this document, particularly with evaluate the methods defined in this document, particularly with
regard to the wide variety of DNS zones in use on the Internet. regard to the wide variety of DNS zones in use on the Internet.
Additionally, the ZONEMD record defined in this document includes a Additionally, the ZONEMD record defined in this document includes a
Reserved field in the form of an 8-bit integer. The authors have a Parameter field in the form of an 8-bit integer. The authors have a
particular future use in mind for this field, namely to support particular future use in mind for this field, namely to support
efficient digests in large, dynamic zones. We intend to conduct efficient digests in large, dynamic zones. We intend to conduct
future experiments using Merkle trees of varying depth. The choice future experiments using Merkle trees of varying depth. The choice
of tree depth can be encoded in this reserved field. We expect of tree depth can be encoded in this reserved field. We expect
values for tree depth to range from 0 to 10, requiring at most four values for tree depth to range from 0 to 10, requiring at most four
bits of this field. This leaves another four bits available for bits of this field. This leaves another four bits available for
other future uses, if absolutely necessary. other future uses, if absolutely necessary.
The duration of the experiment is expected to be no less than two The duration of the experiment is expected to be no less than two
years from the publication of this document. If the experiment is years from the publication of this document. If the experiment is
skipping to change at page 14, line 4 skipping to change at page 14, line 18
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"
subregistry of the "Domain Name System (DNS) Parameters" registry: subregistry of the "Domain Name System (DNS) Parameters" registry:
Type: ZONEMD Type: ZONEMD
Value: 63 Value: 63
Meaning: Message Digest Over Zone Data Meaning: Message Digest Over Zone Data
Reference: This document Reference: This document
6.2. ZONEMD Digest Type 6.2. ZONEMD Digest Type
This document asks IANA to create a new "ZONEMD Digest Types" This document asks IANA to create a new "ZONEMD Digest Types"
registry with initial contents as follows: registry with initial contents as follows:
+---------+-------------+-----------+-----------+ +---------+-----------------+---------------+-----------+-----------+
| Value | Description | Status | Reference | | Value | Description | Mnemonic | Status | Reference |
+---------+-------------+-----------+-----------+ +---------+-----------------+---------------+-----------+-----------+
| 1 | SHA384 | Mandatory | [RFC6605] | | 1 | SHA384 for | SHA384-STABLE | Mandatory | This |
| 240-254 | Private Use | | [RFC8126] | | | stable zones | | | document |
+---------+-------------+-----------+-----------+ | 240-254 | Private Use | - | - | [RFC8126] |
+---------+-----------------+---------------+-----------+-----------+
Table 1: ZONEMD Digest Types Table 1: ZONEMD Digest Types
7. Security Considerations 7. Security Considerations
7.1. Attacks Against the Zone Digest 7.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.
skipping to change at page 15, line 15 skipping to change at page 15, line 29
types result in larger amplification effects (i.e., DNSKEY). types result in larger amplification effects (i.e., DNSKEY).
8. Privacy Considerations 8. Privacy Considerations
This specification has no impacts on user privacy. This specification has no impacts 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, Olafur Gudmundsson, Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,
Paul Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Burt Kaliski, Richard Gibson, Olafur Gudmundsson, Paul Hoffman, Evan Hunt, Shumon
Shane Kerr, Matt Larson, John Levine, Ed Lewis, Matt Pounsett, Mukund Huque, Tatuya Jinmei, Burt Kaliski, Shane Kerr, Matt Larson, John
Sivaraman, Petr Spacek, Ondrej Sury, Florian Weimer, Tim Wicinksi, Levine, Ed Lewis, Matt Pounsett, Mukund Sivaraman, Petr Spacek,
Paul Wouters, and other members of the dnsop working group for their Ondrej Sury, Willem Toorop, Florian Weimer, Tim Wicinksi, Wouter
input. Wijngarrds, Paul Wouters, and other members of the dnsop working
group for their input.
10. Implementation Status 10. Implementation Status
10.1. Authors' Implementation 10.1. Authors' Implementation
The authors have an open source implementation in C, using the ldns The authors have an open source implementation in C, using the ldns
library [ldns-zone-digest]. This implementation is able to perform library [ldns-zone-digest]. This implementation is able to perform
the following functions: the following functions:
o Read an input zone and output a zone with the ZONEMD placeholder. o Read an input zone and output a zone with the ZONEMD placeholder.
skipping to change at page 19, line 5 skipping to change at page 19, line 19
From -00 to -01: From -00 to -01:
o Simplified requirements around verifying multiple digests. Any o Simplified requirements around verifying multiple digests. Any
one match is sufficient. one match is sufficient.
o Updated implementation notes. o Updated implementation notes.
o Both implementations produce expected results on examples given in o Both implementations produce expected results on examples given in
this document. this document.
From -01 to -02:
o Changed the name of the Reserved field to Parameter.
o Changed the name of Digest Type 1 from SHA384 to SHA384-STABLE.
o The meaning of the Parameter field now depends on Digest Type.
o No longer require Parameter field to be zero in verification.
o Updated a rule from earlier versions that said multiple ZONEMD RRs
were not allowed.
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,
skipping to change at page 19, line 49 skipping to change at page 20, line 28
12.2. Informative References 12.2. Informative References
[CZDS] Internet Corporation for Assigned Names and Numbers, [CZDS] Internet Corporation for Assigned Names and Numbers,
"Centralized Zone Data Service", October 2018, "Centralized Zone Data Service", October 2018,
<https://czds.icann.org/>. <https://czds.icann.org/>.
[dns-over-https] [dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-12 (work in (DoH)", draft-ietf-doh-dns-over-https-12 (work in
progress), June 2018, <https://tools.ietf.org/html/ progress), June 2018, <https://tools.ietf.org/html/draft-
draft-ietf-doh-dns-over-https-12>. ietf-doh-dns-over-https-12>.
[InterNIC] [InterNIC]
ICANN, "InterNIC FTP site", May 2018, ICANN, "InterNIC FTP site", May 2018,
<ftp://ftp.internic.net/domain/>. <ftp://ftp.internic.net/domain/>.
[ldns-zone-digest] [ldns-zone-digest]
Verisign, "Implementation of Message Digests for DNS Zones Verisign, "Implementation of Message Digests for DNS Zones
using the ldns library", July 2018, using the ldns library", July 2018,
<https://github.com/verisign/ldns-zone-digest>. <https://github.com/verisign/ldns-zone-digest>.
skipping to change at page 21, line 35 skipping to change at page 22, line 16
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>.
[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/ June 2018, <https://tools.ietf.org/html/draft-vixie-dnsop-
draft-vixie-dnsop-dns-rpz-00>. dns-rpz-00>.
[ZoneDigestHackathon] [ZoneDigestHackathon]
Kerr, S., "Prototype implementation of ZONEMD for the IETF Kerr, S., "Prototype implementation of ZONEMD for the IETF
102 hackathon in Python", July 2018, 102 hackathon in Python", July 2018,
<https://github.com/shane-kerr/ZoneDigestHackathon>. <https://github.com/shane-kerr/ZoneDigestHackathon>.
Appendix A. Example Zones With Digests Appendix A. Example Zones With Digests
This appendix contains example zones with accurate ZONEMD records. This appendix contains example zones with accurate ZONEMD records.
These can be used to verify an implementation of the zone digest These can be used to verify an implementation of the zone digest
skipping to change at page 23, line 34 skipping to change at page 23, line 39
616c6c6f77656420 616c6c6f77656420
6275742069676e6f 6275742069676e6f
7265642e20616c6c 7265642e20616c6c
6f77656420627574 6f77656420627574
2069676e6f726564 2069676e6f726564
2e20616c6c6f7765 ) 2e20616c6c6f7765 )
A.3. EXAMPLE Zone with multiple digests A.3. EXAMPLE Zone with multiple digests
Here, the EXAMPLE zone contains multiple ZONEMD records. Since only Here, the EXAMPLE zone contains multiple ZONEMD records. Since only
one Digest Type is defined at this time (SHA384), this example one Digest Type is defined at this time (SHA384-STABLE), this example
utilizes additional ZONEMD records with Digest Type values in the utilizes additional ZONEMD records with Digest Type values in the
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, Reserved, not verifiable, but note that their other fields (Serial, Parameter,
Digest Type) are included in the calculation of all ZONEMD digests. Digest Type) are included in the calculation of all ZONEMD 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 0 ( example. 86400 IN ZONEMD 2018031900 1 0 (
c0218e8eeb4f0275 c0218e8eeb4f0275
d54c0e5ce7791f4d d54c0e5ce7791f4d
23742b4756708d50 23742b4756708d50
 End of changes. 41 change blocks. 
70 lines changed or deleted 97 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/