Summary

  • DNS ZONEVERSION attaches a zone-version token to the same authoritative response it describes, avoiding the timing gap of a separate SOA query.
  • The token is evidence for one answer from one observed server and vantage; it is not a checksum of the zone, a fleet-convergence certificate or authenticated data unless the exchange has separate integrity protection.

Two operators query the same anycast address for the same name. Both responses say NOERROR. One contains the new address; the other still contains the old one. Each also carries a ZONEVERSION option. The first reports SOA serial 4,120. The second reports 4,119.

The numbers do not make the diagnosis. The important property is that each number travelled in the answer it describes. If the operators had queried the SOA separately a few seconds later, both follow-up queries might have landed on the updated site. They would have preserved two current serials while losing the version that actually generated the stale answer.

This is an illustrative control-room case, not a reported outage and not an assertion about any vendor's support. It shows why RFC 9660 exists: diagnostics need a version token that is temporally coupled to the response under examination.

It also shows the limit. The older token does not prove why the response differs. The newer token does not prove the new zone is correct. Neither single observation proves what the rest of the authoritative fleet serves. A useful token becomes an operational verdict only when its custody and comparison set remain visible.

The diagnostic request is deliberately small

ZONEVERSION is an EDNS option. A requester places option code 19 in the OPT pseudo-record with an OPTION-LENGTH of zero. There is no version guess and no desired state in the query. The request asks, in effect: if you are able and willing, identify the version of the zone used to generate this response.

The strict shape is valuable. A nonzero option length or more than one ZONEVERSION option makes the request invalid for this mechanism. An implementing authoritative server returns FORMERR. That response is evidence about the probe, not evidence that the zone is corrupt. Before escalating a mismatch, the operator should be able to reproduce the exact query bytes and demonstrate that the diagnostic itself was well formed.

The server is not compelled to answer the diagnostic. It must understand the option, have received a valid request, be authoritative for a relevant enclosing zone and choose to honor the request. Absence of ZONEVERSION therefore means “this exchange did not provide answer/version correlation.” It does not mean “the response came from no zone,” “the server is stale,” or even “the implementation never supports RFC 9660.”

The option is also hop by hop. A forwarder cannot blindly copy a request to another server and then paste the returned value into its own response. The value describes the zone version used by the server that generated the answer carrying it. Once an intermediary changes that relationship, the token no longer says what the reader thinks it says.

LABELCOUNT keeps the version attached to the right authority

A ZONEVERSION response begins with three ideas: a one-octet LABELCOUNT, a one-octet TYPE and a VERSION value defined by that type. LABELCOUNT identifies the enclosing zone by counting labels from the right-hand side of the original QNAME. Zero means the root.

That dependence on the original question matters. For host.branch.example, a count of two identifies branch.example; a count of one identifies example. The count cannot exceed the number of labels in the QNAME. An incident record that extracts only “serial 4120” but discards the QNAME and label count has thrown away the scope of the number.

The mechanism can describe more than a simple positive answer. A parent server can return its version with a downward referral because the parent zone generated the delegation response. An authoritative negative response can identify the zone that produced NXDOMAIN or NODATA. Some SERVFAIL responses can carry the option when the server can still identify the relevant authoritative zone. A response may include more than one enclosing zone or more than one version type, but no more than one value for the same TYPE and LABELCOUNT pair.

This is why operational dashboards should not flatten ZONEVERSION to one integer column. The durable key is at least original QNAME, derived enclosing zone, TYPE and VERSION, tied to the raw response and observed responder.

SOA-SERIAL is useful because it is familiar—and dangerous when flattened

RFC 9660 defines TYPE 0, SOA-SERIAL, as the first public version type. Its VERSION is the four-octet unsigned SERIAL copied from the relevant zone's SOA. With the label-count and type octets, the response option length is six.

That makes deployment conceptually simple: operators already use SOA serials to reason about zone generations. It does not make the number globally unique, chronologically obvious or a content digest.

A serial is scoped to its zone. Two unrelated zones can use the same value without any relationship. Within one zone, RFC 1982 defines 32-bit circular arithmetic, so a numerically smaller serial can be newer after wraparound. Some pairs are too far apart for the standard to define an ordering. A monitoring system that compares serials with an ordinary integer > operator can turn a valid rollover into a false rollback alarm.

Even a correctly ordered serial does not hash the data. Two servers can expose different content under the same serial because of an operational error. Two answers can legitimately differ for policy or query context while carrying the same version. Therefore the evidence must retain and compare the answer RRsets, authority data, flags and DNSSEC outcome as well as the token.

RFC 8976's ZONEMD addresses a different question: whether complete zone contents match an expected digest under its validation rules. ZONEVERSION says which version identifier the responder associates with this answer. It cannot substitute for whole-zone validation, and ZONEMD cannot retroactively attach a generation to a particular earlier response. The tools are complementary precisely because their claims are different.

Anycast turns “the server” into a measurement problem

An anycast address is one routing destination that can lead probes to different service instances. A single successful query therefore proves only what one path reached at one moment. It cannot enumerate the sites a reader may reach or show that a rollout has crossed every boundary.

A defensible comparison begins with the authoritative inventory: NS names, unicast addresses where available, anycast prefixes, expected serving cohorts and materially distinct measurement vantages. Each direct query should disable recursion and record source and destination addresses, transport, timestamp, QNAME, RCODE, AA state, answer bytes, TTLs, option bytes and validation outcome. Repeating the same query over time distinguishes a persistent cohort mismatch from one transient or misdirected observation.

NSID can add another clue. RFC 5001 lets a server return an operator-defined identifier that may reveal the responding instance. Its interpretation and uniqueness are local choices, however. An NSID string is not self-authenticating and should not replace the actual endpoint, route and vantage evidence.

Suppose three vantages repeatedly see serial 4,120 and identical answer bytes, while a fourth repeatedly sees 4,119 and the old address. That is strong evidence of a scoped serving difference. It is still not proof of its cause. The fourth path may reach a lagging secondary, an uncompleted signer generation, an excluded rollout cohort or a different policy view. The next evidence comes from transfer journals, signer output, loaded-zone generation and routing-to-site mapping—not from adding confidence words to the token.

The option itself is outside DNSSEC's signature

DNSSEC can authenticate signed RRsets in the answer and establish whether they validate under the configured chain of trust. It does not put the ZONEVERSION EDNS bytes under an RRSIG. On an insecure path, an intermediary can alter or remove the diagnostic token even while the signed answer data continues to validate.

That distinction should appear in incident language. “The answer RRset validated” and “the answer/version tuple had protected custody” are separate statements. Where the diagnostic conclusion matters, operators can use an authenticated and encrypted transport, TSIG or SIG(0), then retain the endpoint or key identity and the actual validation result. Those mechanisms protect the exchange under their trust assumptions. They do not certify that the reported version is operationally desirable or that the zone is complete.

OPT itself is not zone data. ZONEVERSION must not be cached, transferred or stored as if it were an ordinary RR. A cache can retain an answer according to its TTL, but it cannot detach yesterday's option and present it as provenance for today's reconstructed response.

Sources