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