Summary

  • ZONEMD binds one SOA serial to a digest of the canonically ordered whole zone, including glue and occluded data. It can expose a copy that completed transfer and looks current but is not the publisher's committed content.
  • A signed, verified digest is an activation receipt—not a certificate of correct policy or live deployment. Operators still need trust-anchor policy, staged enforcement, a known-good fallback and proof from loaded generation to authoritative answers.

The incoming zone appeared routine. Its SOA serial matched the release ticket. The AXFR had ended cleanly, the receiving process had written a file and the parser accepted every line it could see. A control based on sequence and transport would have marked the generation ready.

It was not ready. A glue RR had disappeared between the publisher's build and the secondary's staging directory. The omission did not make the file syntactically invalid. Nor did it necessarily change the serial: two files can carry the same serial while differing in content, whether because of corruption, incomplete reconstruction, a repository mistake or an operator error. If the receiver loaded the copy, referrals depending on the missing address could fail even while the fleet reported the expected version.

RFC 8976 gives that receiver a separate question to ask. The apex ZONEMD record carries a digest over the zone data at rest. The receiver constructs the same canonical record stream, calculates the digest and compares it with the publisher's value. In the opening case, the serial can match and the digest cannot. That difference is the reason ZONEMD belongs at the activation boundary rather than in a dashboard of optional cryptographic ornament.

A serial orders versions; it does not identify their contents

The SOA serial is indispensable. RFC 1035 placed it in the Start of Authority record, and RFC 1982 later defined how bounded serial arithmetic compares values around wraparound. Secondaries use the number to decide whether another version appears newer.

That is a decision about order, not equality of all records. The serial is chosen by the publisher. If a distribution or storage fault changes content without changing the SOA, the number cannot detect it. If two build paths accidentally emit different zones with one serial, a receiver cannot resolve the conflict by comparing the number with itself.

ZONEMD does not abolish the serial. It places the current SOA serial in the ZONEMD RDATA so the digest is explicitly bound to one version. The other fields identify the collation scheme and hash algorithm, followed by the digest. The relation is therefore useful precisely because the two objects answer different questions: the serial says which generation the publisher names; the digest says which complete canonical content belongs to that name.

The distinction also separates Round 52 from the mechanics of notification and transfer. RFC 1995 describes incremental zone transfer, while RFC 5936 specifies AXFR as a complete-zone transfer. NOTIFY, IXFR and AXFR can shorten staleness and deliver a candidate generation. None of them leaves a durable, publisher-authenticated commitment over the reconstructed copy after it has passed through files, repositories, restarts and loaders.

The record commits to a canonical zone, not a text file

ZONEMD is RR type 63. Its RDATA contains four fields: Serial, Scheme, Hash Algorithm and Digest. Under RFC 8976, the only standardized collation scheme is SIMPLE, value 1, which implementations must support. SHA-384, algorithm 1, is mandatory to support and publishes its full 48-octet result. SHA-512, algorithm 2, should be supported and publishes all 64 octets. The current assignments remain visible in the IANA DNS Parameters registry.

SIMPLE does not hash the bytes of a master file as written. Comments, whitespace and capitalization can vary without changing the DNS data. Instead, records are converted into the uncompressed canonical wire form and ordered using the rules of RFC 4034, with RRsets at one owner additionally sorted by numeric RR type. The result is a commitment to DNS semantics rather than to one editor's formatting.

The inclusion rules are unusually important. All records in the zone are included unless a specific exclusion applies. Glue records count. Occluded data counts. Exact duplicate RRs count once. DNSSEC records count in a signed zone, with a carefully constructed exception for the signature that will cover the final ZONEMD RRset. Data outside the zone does not become part of the commitment merely because it appears beside the zone in a file.

This coverage closes a gap that is easy to miss when “DNSSEC protects the zone” becomes shorthand. DNSSEC normally authenticates RRsets used in DNS response validation, but delegation NS records below the apex and glue are not all protected as ordinary signed authoritative RRsets in the child. ZONEMD commits to the complete zone artifact, including those distribution-critical records. It is not a replacement for DNSSEC; it is a differently grained object for consumers of complete zones.

The cost follows directly from that design. Under SIMPLE, one changed RR requires another pass over the whole zone. RFC 8976 calls the scheme suitable for small or stable zones and warns that it may be impractical for large or highly dynamic ones. The right leadership question is not “does the software support ZONEMD?” It is “is full recalculation comfortably inside this zone's update and propagation budget, including failure and replay?”

Publication is a choreography, not a hash command

The publisher cannot simply calculate a digest over a finished signed zone and append the answer. Adding a new apex type changes the denial-of-existence structures in a DNSSEC-signed zone. RFC 8976 therefore begins by removing prior apex ZONEMD records and their covering signatures, then inserting a placeholder before signing. That lets NSEC or NSEC3 type bitmaps reflect the presence of ZONEMD.

The signer can then process the zone. SIMPLE calculates over the canonically ordered record stream, excluding the apex placeholder ZONEMD record and excluding the RRSIG that will cover the final ZONEMD RRset. Once the digest replaces the placeholder, the publisher adds or refreshes that covering signature.

One operational rule deserves to be promoted out of the implementation notes: creating the ZONEMD signature must not cause another SOA serial change. The matching SOA and ZONEMD have to be published together. Otherwise the act of authenticating the commitment would move the version it claims to describe.

This sequence gives the evidence ledger a natural shape. Retain the source snapshot, build identity, signer release, SOA serial, chosen scheme and algorithm, computed digest, DNSSEC key context and final publication time. A hex string copied from a live query cannot reconstruct who built the zone, which input entered the calculation or whether SOA and commitment crossed the publication boundary atomically.

Verification begins by deciding what security should exist

A recipient cannot safely start with “there is a ZONEMD record, so compare it.” It must first determine whether DNSSEC is expected. Local trust anchors and, for non-root zones, a validated parent DS chain establish whether the SOA and ZONEMD RRsets should be signed. RFC 4035 supplies the DNSSEC validation context.

If signatures are expected, the verifier must validate both the existence of ZONEMD and the signatures over SOA and ZONEMD. Authenticated denial that the record does not exist means digest verification cannot occur. Proof that it should exist followed by its absence in the received zone is not success. Failed signatures are not downgraded into a checksum merely because a locally calculated digest happens to match.

The verifier then checks structure. Every record in a multi-record ZONEMD RRset needs a unique scheme-and-algorithm tuple. The local policy may ignore a tuple it rejects. For each acceptable candidate, the SOA and ZONEMD serials must match; scheme and algorithm must be supported; the digest length must be correct; and the locally calculated value must equal the received one. During an algorithm transition, a match on one supported and permitted tuple is enough.

That last convenience has a governance consequence. RFC 8976 warns that a set of multiple digests is only as secure as the weakest accepted algorithm. Old tuples should leave after transition rather than remain as permanent compatibility doors. Algorithm agility needs an expiry condition, not just an addition procedure.

Verification should produce a reasoned status. “Failed” can mean expected commitment missing, DNSSEC chain unavailable, SOA mismatch, duplicate tuple, unsupported scheme, invalid length or actual content mismatch. Those conditions do not share one owner or one safe response. An activation system that collapses them into a red lamp has thrown away the information needed to contain the event.

Without DNSSEC, the attacker edits the answer too

An unsigned ZONEMD is still useful, but its claim must be named accurately. It catches accidental truncation, transmission errors and other unintentional changes when the received digest remains the publisher's original value. An attacker able to modify the zone can simply calculate a new digest and alter the ZONEMD record as well.

DNSSEC changes that boundary by authenticating the ZONEMD commitment and making removal or alteration detectable. It does not transform the digest into a judgment about the publisher. A malicious or mistaken authorized publisher can commit perfectly to the wrong policy. A valid digest does not establish ownership of a domain, legitimacy of a delegation, compliance with a change ticket or safety of the service behind an address.

The same separation applies to transport. RFC 8945 defines TSIG, which can authenticate DNS transactions using a shared secret. It is valuable for AXFR and IXFR peer identity and message integrity. But channel protection is operationally ephemeral: once a zone is written, repackaged, restored or loaded after restart, the old transaction MAC is not a commitment that travels with the complete data. ZONEMD protects the object across those later boundaries.

Even signed verification has a time dimension. Trust anchors and parent DS state can change. A historical ZONEMD signature may remain inside its own validity interval while the chain needed to validate it is no longer available. Long-lived evidence therefore needs the relevant trust material and validation context, not only an archived zone file.

Refusing a bad zone can also refuse service

RFC 8976 expects that name-server software may verify a candidate zone and refuse to serve it after failure. That is the integrity benefit in its most concrete form: corrupt content never becomes authoritative.

It is also a new availability dependency. A publishing bug, canonicalization defect or missing record is generally indistinguishable from deliberate tampering at the moment of verification. Hard failure can leave a good portion of a zone unavailable because another portion is wrong. If every provider or anycast site reacts differently, the namespace can fragment across generations.

The RFC therefore discusses gradual deployment: verification failures can begin as warnings and later become errors after operators gain experience. ICANN's RZERC003 advice treated root-zone introduction as a coordinated change across the Root Zone Maintainer, root server operators, software implementers and local-root consumers. The important lesson is not that one root-zone policy should be copied everywhere. It is that the commitment changes several failure domains and requires their owners to agree before enforcement.

A mature activation policy distinguishes at least three states. A candidate may be verified and eligible to load. It may fail and enter quarantine while the prior verified generation continues serving for a bounded period. Or the available evidence may be insufficient—for example, a trust-chain problem rather than a content mismatch—and require an explicitly authorized fail-open or fail-closed decision. Each state needs a time limit and named escalation owner.

The prior generation is not an indefinite refuge. Continuing to serve it preserves known integrity but accumulates staleness. The zone's refresh, expiry and business risk decide how long that trade remains acceptable. Rollback is therefore a separately tested product: the previous object must still be available, independently verified, loadable and observable in answers.

The activation receipt must reach the packet edge

ZONEMD can validate a file in staging and still leave production divided. Authoritative service may span several providers and many anycast instances, a setting discussed by RFC 8901. A successful check on one build host does not prove every node loaded the same generation. A successful reload command does not prove the process serves it. A query to one anycast catchment does not prove global convergence.

The activation receipt therefore needs a chain. At the publisher, it binds source snapshot, serial and signed digest. At transport or repository boundaries, it records the object, size, local hash and custody events. At the verifier, it records expected DNSSEC state, trust anchors, accepted tuple, computed value and reasoned result. At activation, it binds the verified object to the old and new serving generations. At runtime, it samples authoritative SOA, ZONEMD and selected included records from the required fleet scope.

Canaries should include the record classes the control was meant to protect. A query for SOA alone repeats the serial problem. Test delegation-sensitive names, selected glue addresses, signed RRsets and negative answers, and retain which authoritative identity and network vantage returned them. For a hyperlocal root deployment under RFC 8806, the local copy and its refresh path need their own receipt rather than borrowing proof from the public root fleet.

Closure also requires negative evidence. After rollback or retirement, the rejected digest and generation should disappear from staging eligibility, serving processes and sampled answers. Otherwise a node that missed the control event can preserve the very copy the investigation declared unfit.

Sources