Skip to content
Control Plane Labs
Search

ZONEMD record

Publishes a digest of a DNS zone so a validator can detect unauthorized or incomplete zone transfers.

Written and maintained by Ben Ennis

Last reviewed July 27, 2026 · How we verify this

Zone-file example

example.com. 3600 IN ZONEMD 2026081700 1 1 7A3F...

Typical uses

  • Detecting changes to a signed or transferred zone that were not authorized by the zone owner
  • Checking that secondary servers received the same zone contents as the primary
  • Adding an integrity signal to environments where transfer authentication alone is insufficient
  • Monitoring authoritative DNS infrastructure for drift between published copies

When it breaks, check

  • The serial in ZONEMD must match the zone version being digested, so regenerate it after every change
  • The digest excludes the ZONEMD record itself and follows the canonical ordering rules in the RFC
  • Do not compare a digest calculated from a partial AXFR, a cached answer, or an unsigned presentation
  • A correct digest proves content consistency, not that the zone is semantically configured well

What the ZONEMD record does

ZONEMD binds a digest to a zone’s SOA serial. The record identifies the serial, scheme, and hash algorithm, followed by the digest over a canonical representation of the zone. The ZONEMD record itself is excluded from that calculation, which prevents a digest from recursively including its own value. Validators can therefore recalculate the value from a complete zone and compare it with the published answer.

This catches a class of operational faults that ordinary DNS queries miss. A secondary may be answering authoritatively while serving an incomplete transfer or a stale set of records. ZONEMD can expose that difference when the validator has the full zone or a trusted transfer path. It does not judge whether the records are correct for the business; it only checks consistency with the digest publisher’s zone version.

Zone-file and wire format

The RDATA is serial scheme hash algorithm digest. Serial is the SOA serial covered by the digest. Scheme 1 is the Simple ZONEMD scheme, and algorithm 1 is SHA-384 in the initial registry. The digest is hexadecimal in zone-file presentation. A zone can publish more than one record when it supports multiple algorithms or schemes, but all records for a serial must follow the same canonicalization and exclusion rules.

; serial 2026081700, Simple scheme, SHA-384
example.com. 3600 IN ZONEMD 2026081700 1 1 \\
  7a3f...sha384-digest-in-hex...

Common uses

Use ZONEMD where authoritative DNS consistency matters: multi-provider authoritative service, regulated zone operations, or a transfer pipeline that needs an independent drift signal. It pairs naturally with DNSSEC and authenticated AXFR/IXFR; it does not replace either. For a record-level check, the DNS lookup tool can show the published digest. For a domain’s signing posture, inspect DS and DNSKEY records as well.

Troubleshooting

A mismatch is usually a version or completeness problem before it is a cryptographic problem. Compare the ZONEMD serial with the SOA serial, then calculate over the same complete zone view on both servers. AXFR and IXFR differences, hidden provider records, omitted glue, and a calculator that included ZONEMD itself can all produce a false alarm. Check the authoritative server directly; a recursive answer may be cached.

After a legitimate edit, regenerate the digest as part of the publication transaction. Leaving the old serial or digest in place makes every healthy secondary look inconsistent.

dig @ns1.example.net example.com SOA ZONEMD +norecurse +noall +answer
dig @ns2.example.net example.com SOA ZONEMD +norecurse +noall +answer

# Request the complete transfer only from an authorized server.
dig @ns1.example.net example.com AXFR > zone.txt

The defining RFC

ZONEMD is DNS type 63, defined by RFC 8976, which specifies the canonical zone digest, serial handling, schemes, and hash algorithms. RFC 8976 explicitly separates zone integrity from DNSSEC authentication: a deployment should use the controls appropriate to its threat model rather than treating one mechanism as the other. The IANA DNS Parameters registry records the type and algorithm assignments.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types