Message Digest for DNS Zones
Extracted elements (31)
Placeholder ZONEMD RRs are added before DNSSEC signing so that denial-of-existence (NSEC/NSEC3) records include the ZONEMD type in their Type Bit Maps. Adding ZONEMD after signing would require updating NSEC/NSEC3 RRs, which would invalidate the digest.
The digest is embedded in the zone itself (rather than as a detached signature) so that the zone retains its standard DNS zone format, can be directly loaded into a name server, and carries the integrity proof with it through any distribution mechanism.
The SIMPLE scheme is intentionally limited to static digest-over-whole-zone for small/stable zones. The extensible Scheme field anticipates future incremental-update schemes for large or highly dynamic zones, which SIMPLE cannot efficiently support.
ZONEMD fills a gap that DNSSEC leaves: delegation (non-apex NS) records and glue records are not signed by DNSSEC, and NSEC3 with Opt-Out allows names to be added or removed between signed nodes. ZONEMD protects the zone as a whole, including unsigned records.
ZONEMD is OPTIONAL to implement by both publishers and consumers of zone data. A verifier receiving a zone with multiple ZONEMD RRs MAY ignore a record whose Scheme or Hash Algorithm violates local policy; a match on any one supported tuple is sufficient for successful verification.
During verification, for zones where DNSSEC signatures are expected, the SOA and ZONEMD RRsets MUST have valid signatures chaining up to a trust anchor; if DNSSEC validation fails, digest verification MUST NOT be considered successful.
During verification, the SOA Serial field MUST exactly match the ZONEMD Serial field; a mismatch means verification MUST NOT be considered successful for that ZONEMD RR.
For the SIMPLE scheme, all records including glue and occluded data MUST be included in the digest; duplicate RRs MUST be omitted (only one instance digested); the placeholder apex ZONEMD RR(s) and the RRSIG covering the apex ZONEMD RRset MUST NOT be included.
Generation of a ZONEMD signature MUST NOT also result in a change to the SOA serial number, because any SOA serial change would invalidate the computed digest. The ZONEMD RR and the matching SOA MUST be published at the same time.
Non-apex ZONEMD RRs MUST NOT be used for verification; during digest calculation they are treated as ordinary RRs and digested as-is without placeholder substitution.
Servers SHOULD NOT calculate zone digests dynamically (per query) because doing so can be exploited as a CPU resource exhaustion attack.
SHA-384 (Hash Algorithm value 1) MUST be supported by all implementations; the 48-octet digest result MUST NOT be truncated.
SHA-512 (Hash Algorithm value 2) SHOULD be supported by implementations; the 64-octet digest result MUST NOT be truncated.
SIMPLE scheme digest calculation requires RRs to be processed in DNSSEC canonical on-the-wire format (no name compression) per RFC 4034 Sections 6.1–6.3, with RRsets sharing the same owner name additionally ordered numerically ascending by RR TYPE.
The SIMPLE collation scheme (Scheme value 1) MUST be supported by all implementations.
When multiple ZONEMD RRs are present in the zone, each MUST specify a unique Scheme and Hash Algorithm tuple; if the RRset contains two or more records with the same tuple, verification for those records MUST NOT be considered successful.
This specification has no impact on user privacy.
ZONEMD is a new DNS Resource Record (RR type 63) that conveys a cryptographic message digest of zone data at the zone apex. Its RDATA consists of four fields: Serial (32-bit), Scheme (8-bit), Hash Algorithm (8-bit), and Digest (variable-length). The RR is class independent.
IANA allocated RR type 63 for ZONEMD ('Message Digest Over Zone Data') in the 'Resource Record (RR) TYPEs' subregistry of 'Domain Name System (DNS) Parameters'.
IANA created the 'ZONEMD Hash Algorithms' registry under 'Domain Name System (DNS) Parameters' with registration procedure Specification Required. Initial values: 0 Reserved, 1 SHA-384, 2 SHA-512, 3–239 Unassigned, 240–254 Private Use, 255 Reserved.
IANA created the 'ZONEMD Schemes' registry under 'Domain Name System (DNS) Parameters' with registration procedure Specification Required. Initial values: 0 Reserved, 1 SIMPLE, 2–239 Unassigned, 240–254 Private Use, 255 Reserved.
Attackers may perform downgrade attacks by removing ZONEMD records or stripping DNSSEC signatures; these are only detectable via DNSSEC validation of denial-of-existence proofs and RRset signatures. Verifiers must check for expected DNSSEC coverage before trusting the digest.
When multiple ZONEMD RRs with different hash algorithms are published, the overall security is only as strong as the weakest algorithm. Publishers SHOULD publish multiple records only during transitions and remove the old algorithm once the rollover is complete.
Without DNSSEC, ZONEMD provides no protection against intentional attacks because an attacker can modify zone content and recompute the Digest field. In the absence of DNSSEC it functions only as an unintentional-corruption checksum.
ZONEMD introduces denial-of-service fragility: valid zone data becomes unavailable if any portion is missing or corrupt and verification is enforced. Misconfigurations and implementation bugs are indistinguishable from tampering. Operators are advised to deploy verification gradually, initially treating failures as warnings.
Digest calculation follows a four-step procedure: (1) delete existing apex ZONEMD records and add placeholder ZONEMD RR(s); (2) optionally sign the zone with DNSSEC; (3) compute the digest over zone data per scheme-specific rules; (4) insert computed digest into the placeholder record and update any covering RRSIGs. Steps must proceed in this order to ensure correct denial-of-existence records.
The Digest field is a variable-length octet sequence whose length is derived from the RDATA size minus the fixed 6-octet prefix. It MUST NOT be shorter than 12 octets (96 bits of equivalent strength minimum for future algorithms).
The Hash Algorithm field is an 8-bit unsigned integer; value 1 is SHA-384 (48-octet digest), value 2 is SHA-512 (64-octet digest). Values 240–254 are Private Use; 0 and 255 are Reserved.
The Scheme field is an 8-bit unsigned integer identifying the collation method; value 1 designates the SIMPLE scheme. Values 240–254 are Private Use; 0 and 255 are Reserved.
The Serial field is a 32-bit unsigned integer in network byte order containing the SOA serial number for which the digest was generated, binding the ZONEMD RR to a specific version of the zone.
The ZONEMD RDATA wire format encodes Serial as a 32-bit unsigned integer in network byte order, followed by Scheme (8-bit), Hash Algorithm (8-bit), and Digest (variable-length octet sequence). Total fixed overhead before the digest is 6 octets.