Summary

  • RFC 8976 defines the apex ZONEMD record so a receiver can calculate a digest over a complete zone and compare it with the publisher's value independently of the transfer method.
  • DNSSEC-authenticated ZONEMD can support integrity and origin authenticity for the whole zone; an unsigned record is only a checksum against accidental change, and the specified scheme is costly for large dynamic zones.

Analysis

Zone distribution and zone verification answer different questions. AXFR can deliver a whole zone, IXFR can deliver changes, and a publisher can distribute a zone through an ordinary file channel. Each mechanism can complete without giving the receiver a standard proof that the resulting collection of records is exactly the publisher's intended whole.

RFC 8976 introduces the ZONEMD resource record for that gap. The record sits at the zone apex and has type 63. Its data binds a digest to the zone's SOA serial, a collation scheme and a hash algorithm. The receiver calculates the digest over its copy and compares the result after receipt. A non-apex ZONEMD record has no verification meaning under the specification.

The distinction between integrity and authenticity is essential. When the zone is signed with DNSSEC, the receiver can authenticate the ZONEMD RRset and use its digest to verify that the complete zone matches the signed publisher state. Without DNSSEC, the digest remains useful as a checksum against unintentional modification, but it cannot establish who authorized the value.

The SIMPLE scheme makes comparison independent of presentation details. Records are processed in canonical wire form and canonical order. The calculation includes the zone's data under defined rules, while excluding the placeholder apex ZONEMD record and the signature that covers the final ZONEMD RRset. The digest is inserted before the covering signature is finalized, and the matching SOA serial and ZONEMD record must be published together.

IANA records SIMPLE as scheme 1, SHA-384 as algorithm 1 and SHA-512 as algorithm 2. RFC 8976 requires implementations of the specified scheme to support SHA-384 and also defines SHA-512. Multiple scheme-and-algorithm tuples support transition, but more records also add calculation and operational complexity.

A mismatch is evidence of disagreement, not a diagnosis. It can point to an incomplete transfer, a stale serial, different canonical input, an ordering defect, a signing sequence problem or unintended modification. The standards do not identify which cause applies to a particular incident. A receiving operator therefore needs a rule for quarantining the copy, preserving both calculations and reconciling publisher and receiver state before promotion.

The mechanism also has a declared boundary. The SIMPLE digest is recalculated over the zone as a whole. RFC 8976 says this is impractical as specified for large, frequently changing zones, while leaving room for future schemes. No source in this package establishes current adoption, a universal performance budget or a prevented incident.

Sources