draft-ietf-dnsop-dns-zone-digest-05.txt   draft-ietf-dnsop-dns-zone-digest-06.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: September 10, 2020 Verisign Expires: October 10, 2020 Verisign
W. Kumari W. Kumari
Google Google
W. Hardaker W. Hardaker
USC/ISI USC/ISI
March 9, 2020 April 8, 2020
Message Digest for DNS Zones Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-05 draft-ietf-dnsop-dns-zone-digest-06
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 September 10, 2020. This Internet-Draft will expire on October 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 3, line 7 skipping to change at page 3, line 7
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 . . . . . . . . . . . . . . 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
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . 16 6.3. Resilience and Fragility . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . 26 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 25
A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 26 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 26
A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 27 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 27
A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 28 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 27
A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 31 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 4, line 45 skipping to change at page 4, line 45
DNS Request and Transaction Signatures (SIG(0) [RFC2931]) is another DNS Request and Transaction Signatures (SIG(0) [RFC2931]) is another
protocol extension designed to authenticate individual DNS protocol extension designed to authenticate individual DNS
transactions. Whereas SIG records were originally designed to cover transactions. Whereas SIG records were originally designed to cover
specific RR types, SIG(0) is used to sign an entire DNS message. specific RR types, SIG(0) is used to sign an entire DNS message.
Unlike TSIG, SIG(0) uses public key cryptography rather than shared Unlike TSIG, SIG(0) uses public key cryptography rather than shared
secrets. secrets.
The Transport Layer Security protocol suite is also designed to The Transport Layer Security protocol suite is also designed to
provide channel security. One can easily imagine the distribution of provide channel security. One can easily imagine the distribution of
zones over HTTPS-enabled web servers, as well as DNS-over-HTTPS zones over HTTPS-enabled web servers, as well as DNS-over-HTTPS
[dns-over-https], and perhaps even a future version of DNS-over-TLS [RFC8484], and perhaps even a future version of DNS-over-TLS
([RFC7858]). ([RFC7858]).
Unfortunately, the protections provided by these channel security Unfortunately, the protections provided by these channel security
techniques are (in practice) ephemeral and are not retained after the techniques are (in practice) ephemeral and are not retained after the
data transfer is complete. They can ensure that the client receives data transfer is complete. They can ensure that the client receives
the data from the expected server, and that the data sent by the the data from the expected server, and that the data sent by the
server is not modified during transmission. However, they do not server is not modified during transmission. However, they do not
guarantee that the server transmits the data as originally published, guarantee that the server transmits the data as originally published,
and do not provide any methods to verify data that is read after and do not provide any methods to verify data that is read after
transmission is complete. For example, a name server loading saved transmission is complete. For example, a name server loading saved
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 serves two purposes: (1) it allows the digest to cover the This ensures that appropriate denial-of-existence (NSEC, NSEC3)
Serial, Scheme, and Hash Algorithm fields, and (2) ensures that records are created if the zone is signed with DNSSEC. When multiple
appropriate denial-of-existence (NSEC, NSEC3) records are created if ZONEMD RRs are published in the zone, e.g., during an algorithm
the zone is signed with DNSSEC. When multiple ZONEMD RRs are rollover, each must specify a unique Scheme and Hash Algorithm tuple.
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. Since ZONEMD records are excluded from
of length appropriate for the chosen hash algorithm. digest calculation, the value of the Digest field does not matter at
this point in the process. Implementations MAY want to set the
Digest field to all zeroes anyway.
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.
skipping to change at page 11, line 37 skipping to change at page 11, line 37
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
and RDATA SHALL be included ([RFC4034] Section 6.3). and RDATA SHALL be included ([RFC4034] Section 6.3).
o The placeholder ZONEMD RR(s) MUST be included. o The placeholder ZONEMD RR(s) MUST NOT 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. Scheme-Specific Processing 3.5. Scheme-Specific Processing
At this time, only the SIMPLE collation scheme is defined. At this time, only the SIMPLE collation scheme is defined.
Additional schemes may be defined in future updates to this document. Additional schemes may be defined in future updates to this document.
skipping to change at page 12, line 48 skipping to change at page 12, line 48
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. If multiple ZONEMD RRs are calculating the digest as follows. If multiple ZONEMD RRs are
present in the zone, e.g., during an algorithm rollover, a match present in the zone, e.g., during an algorithm rollover, a match
using any one of the recipient's supported Schemes and Hash using any one of the recipient's supported Schemes and Hash
Algorithms is sufficient to verify the zone. 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
DNSSEC records in the zone. This can be done by examining records in the zone. This can be done by examining locally
locally configured trust anchors, or querying for (and configured trust anchors, or querying for (and validating) DS RRs
validating) DS RRs in the parent zone. For zones that are in the parent zone. For zones that are provably insecure, or if
provably insecure, or if DNSSEC validation can not be performed, DNSSEC validation can not be performed, digest validation
digest validation continues at step 4 below. continues at step 4 below.
2. For zones that are provably secure, the existence of the apex
ZONEMD record MUST be verified. If the ZONEMD record provably
does not exist, digest verification cannot be done. If the
ZONEMD record does provably exist, but is not found in the zone,
digest verification MUST NOT be considered successful.
3. For zones that are provably secure, the SOA and ZONEMD RRSets
MUST have valid signatures, chaining up to a trust anchor. If
DNSSEC validation of the SOA or ZONEMD records fails, digest
verification MUST NOT be considered successful.
4. If the ZONEMD RRSet contains more than one RR with the same 2. For zones that are provably secure, the existence of the apex
Scheme and Hash Algorithm, digest verification MUST NOT be ZONEMD record MUST be verified. If the ZONEMD record provably
considered successful. does not exist, digest verification cannot be done. If the
ZONEMD record does provably exist, but is not found in the zone,
digest verification MUST NOT be considered successful.
5. The SOA Serial field MUST exactly match the ZONEMD Serial field. 3. For zones that are provably secure, the SOA and ZONEMD RRSets
If the fields to not match, digest verification MUST NOT be MUST have valid signatures, chaining up to a trust anchor. If
considered successful. DNSSEC validation of the SOA or ZONEMD records fails, digest
verification MUST NOT be considered successful.
6. The ZONEMD Hash Algorithm field MUST be checked. If the 4. If the ZONEMD RRSet contains more than one RR with the same
verifier does not support the given Hash Algorithm, it SHOULD Scheme and Hash Algorithm, digest verification MUST NOT be
report that the zone digest could not be verified due to an considered successful.
unsupported algorithm.
7. The received Digest value is copied to a temporary location. 5. Loop over all apex ZONEMD RRs and perform the following steps:
Repeat for each ZONEMD RR present.
8. The ZONEMD RR's Digest field MUST be set to all zeroes. Repeat A. The SOA Serial field MUST exactly match the ZONEMD Serial
for each RR present in the apex ZONEMD RRSet, even for field. If the fields do not match, digest verification MUST
unsupported Scheme and Hash Algorithm values. NOT be considered successful with this ZONEMD RR.
9. The zone digest is computed over the zone data as described in B. The Scheme field MUST be checked. If the verifier does not
Section 3.5. support the given scheme, it SHOULD report that the RR's
digest could not be verified due to an unsupported scheme.
10. The calculated digest is compared to the received digest stored C. The Hash Algorithm field MUST be checked. If the verifier
in the temporary location. If the two digest values match, does not support the given hash algorithm, it SHOULD report
verification is considered successful. Otherwise, verification that the RR's digest could not be verified due to an
MUST NOT be considered successful. unsupported algorithm.
11. The ZONEMD RR's RDATA is reset to the received Digest stored in D. The zone digest is computed over the zone data as described
the temporary location. Thus, any downstream clients can in Section 3.5, using the Scheme and Hash Algorithm for the
similarly verify the zone. current ZONEMD RR.
Note that when multiple ZONEMD RRs are present in the zone, the E. The computed digest is compared to the received digest. If
Digest field of each MUST be zeroed in step 8 above, even for the two digest values match, verification is considered
unsupported Scheme and Hash Algorithm values. successful. Otherwise, verification MUST NOT be considered
successful for this ZONEMD RR.
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"
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
skipping to change at page 23, line 7 skipping to change at page 22, line 46
o Specifciation Required for updates to ZONEMD protocol registries. o Specifciation Required for updates to ZONEMD protocol registries.
o Other rewording based on WGLC feedback. o Other rewording based on WGLC feedback.
o Updated RFC numbers for some references. o Updated RFC numbers for some references.
o Use documentation IP addresses instead of loopback. o Use documentation IP addresses instead of loopback.
o Updated examples in the appendix. o Updated examples in the appendix.
From -05 to -06:
o Per WG suggestion, no longer include any apex ZONEMD record in
digest calculation.
o Updated examples in the appendix.
o Clarified verification procedure by describing a loop over all
ZONEMD RRs.
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 23, line 44 skipping to change at page 23, line 45
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-12 (work in
progress), June 2018, <https://tools.ietf.org/html/draft-
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>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
skipping to change at page 25, line 25 skipping to change at page 25, line 20
[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>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/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),
skipping to change at page 26, line 15 skipping to change at page 26, line 10
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 (
e12a0dd55a1dd1b8 c68090d90a7aed71
e29ec9b1d42d71ec 6bc459f9340e3d7c
09329da5f162f327 1370d4d24b7e2fc3
e1eb4803947995ec a1ddc0b9a87153b9
f7c65aa566cf6cfd a9713b3c9ae5cc27
36a0caf8bdb03ac4 ) 777f98b8e730044c )
ns1 3600 IN A 203.0.113.63 ns1 3600 IN A 203.0.113.63
ns2 3600 IN AAAA 2001:db8::63 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 (
626637812169d7ab 31cefb03814f5062
fcb24f13cb704f13 ad12fa951ba0ef5f
b8a131fee1c3bc73 8da6ae354a415767
29144fa5ec2608a4 246f7dc932ceb1e7
1b596d41ff8c8310 42a2108f529db6a3
b2897e73f6e521fc ) 3a11c01493de358d )
ns1 3600 IN A 203.0.113.63 ns1 3600 IN A 203.0.113.63
ns2 3600 IN AAAA 2001:db8::63 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
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 Hash Algorithm is defined at this time (SHA384), this example one Scheme (SIMPLE) and one Hash Algorithm (SHA384) is defined at
utilizes additional ZONEMD records with Hash Algorithm values in the this time, this example utilizes additional ZONEMD records with
private range (240-254). These additional private-range digests are Scheme and Hash Algorithm values in the private range (240-254).
not verifiable, but note that their other fields (Serial, Scheme, These additional private-range digests are not verifiable.
Hash Algorithm) 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 1 ( example. 86400 IN ZONEMD 2018031900 1 1 (
366d22ea3bd8df44 62e6cf51b02e54b9
0fa44b6213359d9b b5f967d547ce4313
1f73bb9d8dd67a1b 6792901f9f88e637
4c0bdf6f0b3657c5 493daaf401c92c27
0316f770fbb03057 9dd10f0edb1c56f8
0c06adb87c121431 ) 080211f8480ee306 )
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 241 1 (
5732dd91240611f8
314adb6b4769bdd2 )
example. 86400 IN ZONEMD 2018031900 1 242 (
7c32e06779315c7d
81ba8c72f5cf9116
496b6395 )
example. 86400 IN ZONEMD 2018031900 1 243 (
183770af4a629f80
2e674e305b8d0d11
3dfe0837 )
example. 86400 IN ZONEMD 2018031900 1 244 (
e1846540e33a9e41
89792d18d5d131f6
05fc283e )
example. 86400 IN ZONEMD 2018031900 240 1 (
e1846540e33a9e41 e1846540e33a9e41
89792d18d5d131f6 89792d18d5d131f6
05fc283e ) 05fc283e )
ns1.example. 3600 IN A 203.0.113.63 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 2001:db8::63 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
skipping to change at page 31, line 38 skipping to change at page 30, line 30
NSEC ) NSEC )
urn.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( urn.uri.arpa. 604800 IN NAPTR 0 0 "" "" (
"/urn:([^:]+)/\\1/i" . ) "/urn:([^:]+)/\\1/i" . )
uri.arpa. 3600 IN SOA sns.dns.icann.org. ( uri.arpa. 3600 IN SOA sns.dns.icann.org. (
noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 )
;; Query time: 66 msec ;; Query time: 66 msec
;; SERVER: 192.0.32.132#53(192.0.32.132) ;; SERVER: 192.0.32.132#53(192.0.32.132)
;; WHEN: Sun Oct 21 20:39:28 UTC 2018 ;; WHEN: Sun Oct 21 20:39:28 UTC 2018
;; XFR size: 34 records (messages 1, bytes 3941) ;; XFR size: 34 records (messages 1, bytes 3941)
uri.arpa. 3600 IN ZONEMD 2018100702 1 1 ( uri.arpa. 3600 IN ZONEMD 2018100702 1 1 (
cc4a0b6556272fc739b8ff74b80b4a43ac9575d91445ecc0dc22f5 1291b78ddf7669b1a39d014d87626b709b55774c5d7d58fa
09fa27c62448a7100660bbdb4c90667424b734956b ) dc556439889a10eaf6f11d615900a4f996bd46279514e473 )
A.5. The ROOT-SERVERS.NET Zone A.5. The ROOT-SERVERS.NET Zone
The ROOT-SERVERS.NET zone retreived 2018-10-21. The ROOT-SERVERS.NET zone retreived 2018-10-21.
root-servers.net. 3600000 IN SOA a.root-servers.net. ( root-servers.net. 3600000 IN SOA a.root-servers.net. (
nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 )
root-servers.net. 3600000 IN NS a.root-servers.net. root-servers.net. 3600000 IN NS a.root-servers.net.
root-servers.net. 3600000 IN NS b.root-servers.net. root-servers.net. 3600000 IN NS b.root-servers.net.
root-servers.net. 3600000 IN NS c.root-servers.net. root-servers.net. 3600000 IN NS c.root-servers.net.
skipping to change at page 32, line 51 skipping to change at page 31, line 51
j.root-servers.net. 3600000 IN A 192.58.128.30 j.root-servers.net. 3600000 IN A 192.58.128.30
k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1
k.root-servers.net. 3600000 IN A 193.0.14.129 k.root-servers.net. 3600000 IN A 193.0.14.129
l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42
l.root-servers.net. 3600000 IN A 199.7.83.42 l.root-servers.net. 3600000 IN A 199.7.83.42
m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35
m.root-servers.net. 3600000 IN A 202.12.27.33 m.root-servers.net. 3600000 IN A 202.12.27.33
root-servers.net. 3600000 IN SOA a.root-servers.net. ( root-servers.net. 3600000 IN SOA a.root-servers.net. (
nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 )
root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 ( root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 (
4fb752b314e4dccb845832b611590b669a80daebb736d4bd22aa76ec06 f1ca0ccd91bd5573d9f431c00ee0101b2545c97602be0a97
6737c79185c1f7dfd49ec91d9523e6240ea2c4 ) 8a3b11dbfc1c776d5b3e86ae3d973d6b5349ba7f04340f79 )
Authors' Addresses Authors' Addresses
Duane Wessels Duane Wessels
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: dwessels@verisign.com Email: dwessels@verisign.com
 End of changes. 33 change blocks. 
115 lines changed or deleted 97 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/