draft-ietf-dnsop-dns-zone-digest-07.txt   draft-ietf-dnsop-dns-zone-digest-08.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 Verisign
Expires: October 30, 2020 Verisign Expires: December 14, 2020 M. Weinberg
Amazon
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
April 28, 2020 June 12, 2020
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-07 draft-ietf-dnsop-dns-zone-digest-08
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 October 30, 2020. This Internet-Draft will expire on December 14, 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 . . . . . . . . . . . . . . 10 3.3. Canonical Format and Ordering . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 12
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
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 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 ZONEMD Queries . . . . . . . . . . . . 15 6.2. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 15
6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 15 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
10.3. NIC Chile Labs Implementation . . . . . . . . . . . . . 18 10.3. NIC Chile Labs Implementation . . . . . . . . . . . . . 18
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Example Zones With Digests . . . . . . . . . . . . . 26 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 26
A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 26 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 26 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 27
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 27 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 28
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 28 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 31 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 ([RFC8499]). 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
skipping to change at page 10, line 22 skipping to change at page 10, line 22
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 (and covering RRSIGs) 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,
one or more placeholder ZONEMD records are added to the zone apex. one or more placeholder ZONEMD records are added to the zone apex.
This ensures that appropriate denial-of-existence (NSEC, NSEC3) This ensures that denial-of-existence (NSEC, NSEC3) records are
records are created if the zone is signed with DNSSEC. When multiple created correctly if the zone is signed with DNSSEC. If placeholders
ZONEMD RRs are published in the zone, e.g., during an algorithm are not added prior to signing, the later addition of ZONEMD records
rollover, each must specify a unique Scheme and Hash Algorithm tuple. would also require updating the Type Bit Maps field of any apex NSEC/
NSEC3 RRs, which then invalidates the calculated digest value.
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. Since ZONEMD records are excluded from the chosen hash algorithm. Since ZONEMD records are excluded from
digest calculation, the value of the Digest field does not matter at digest calculation, the value of the Digest field does not matter at
this point in the process. Implementations MAY want to set the this point in the process. Implementations MAY want to set the
skipping to change at page 11, line 8 skipping to change at page 11, line 15
3.3. Canonical Format and Ordering 3.3. Canonical Format and Ordering
Calculation of a zone digest REQUIRES RRs to be processed in a Calculation of a zone digest REQUIRES RRs to be processed in a
consistent format and ordering. Correct ordering depends on (1) consistent format and ordering. Correct ordering depends on (1)
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]).
define a canonical ordering for RRSets having the same owner name,
that ordering is defined here. However, since DNSSEC does not define a canonical ordering for RRSets
having the same owner name, that ordering is defined here. For the
purposes of calculating the zone digest, RRSets having the same owner
name MUST be numerically ordered, in ascending order, by their
numeric RR TYPE.
This specification adopts DNSSEC's canonical on-the-wire RR format This specification adopts DNSSEC's canonical on-the-wire RR format
(without name compression) as specified in [RFC4034]: (without name compression) as specified in [RFC4034]:
RR(i) = owner | type | class | TTL | RDATA length | RDATA RR(i) = owner | type | class | TTL | RDATA length | RDATA
where "|" denotes concatenation. where "|" denotes concatenation.
3.3.1. Order of RRSets Having the Same Owner Name
For the purposes of calculating the zone digest, RRSets having the
same owner name MUST be numerically ordered, in ascending order, by
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:
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 Only one instance of duplicate RRs with equal owner, class, type o Only one instance of duplicate RRs with equal owner, class, type
skipping to change at page 23, line 25 skipping to change at page 23, line 42
o Updated examples in the appendix. o Updated examples in the appendix.
o Clarified verification procedure by describing a loop over all o Clarified verification procedure by describing a loop over all
ZONEMD RRs. ZONEMD RRs.
From -06 to -07: From -06 to -07:
o Added NIC Chile Labs implementation. o Added NIC Chile Labs implementation.
From -07 to -08:
o Update an author's affiliation.
o Clarified why placeholder RRs are still important (for NSEC/
NSEC3).
o Moved subsection ("Order of RRSets Having the Same Owner Name")
with single sentence paragraph up into parent section.
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 33, line 26 skipping to change at page 34, line 26
Piet Barber Piet Barber
Verisign Verisign
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: pbarber@verisign.com Email: pbarber@verisign.com
URI: http://verisign.com URI: http://verisign.com
Matt Weinberg Matt Weinberg
Verisign Amazon
12061 Bluemont Way
Reston, VA 20190
Phone: +1 703 948-3200 Email: matweinb@amazon.com
Email: mweinberg@verisign.com URI: http://amazon.com
URI: http://verisign.com
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
Email: warren@kumari.net Email: warren@kumari.net
Wes Hardaker Wes Hardaker
USC/ISI USC/ISI
 End of changes. 17 change blocks. 
38 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/