The DNS Zone Version (ZONEVERSION) Option
Extracted elements (24)
The LABELCOUNT field was introduced to disambiguate which enclosing zone a ZONEVERSION value refers to, since a single QNAME may be subject to multiple zones (e.g., parent and child at a zone cut, or CNAME chains crossing zone boundaries). This allows a single response to carry multiple ZONEVERSION options for different zones.
The ZONEVERSION option is defined as a registry of TYPE values rather than a single fixed format to accommodate zones that use distribution and synchronization mechanisms other than SOA SERIAL (e.g., relational databases or proprietary methods). Private Use code points (246–254) are also allocated for zone operators with non-standard versioning.
ZONEVERSION is intentionally non-transitive and hop-to-hop only, modeled after NSID (RFC 5001). This prevents recursive resolvers from accidentally propagating zone version data from upstream authoritative servers back to end clients without those clients requesting it.
ZONEVERSION was designed to atomically pair a DNS answer with the version of the zone that produced it, simplifying debugging and diagnostics. This is especially useful when zones use IP anycast or multiple backend servers where two queries may reach different servers, making it impossible to ensure version consistency across separate queries.
Unlike most EDNS(0) option values in a response, ZONEVERSION values are dependent on the queried name (the LABELCOUNT references labels of QNAME). This makes implementation more complex in name servers where EDNS(0) options are handled independently of query name processing.
ZONEVERSION SHOULD be included in downward referral responses (even though the AA bit is not set), NXDOMAIN responses, NODATA responses, and SERVFAIL responses when the server is authoritative for the QNAME. For referrals, the ZONEVERSION data MUST correspond to the referring zone's version.
A DNS client SHOULD NOT send the ZONEVERSION option to non-authoritative name servers, and MUST NOT include more than one ZONEVERSION option in the OPT pseudo-RR of a DNS query.
A name server MUST NOT include more than one ZONEVERSION option for a given TYPE and LABELCOUNT combination, though it MAY include multiple ZONEVERSION options for different TYPEs or different enclosing zones.
A name server that understands ZONEVERSION MUST return a FORMERR response when the ZONEVERSION OPTION-LENGTH is not zero in a query, or when more than one ZONEVERSION option is present in a query.
A name server that understands ZONEVERSION, receives a query with it, is authoritative for one or more enclosing zones of the original QNAME, and chooses to honor the request responds with a ZONEVERSION option in the response OPT RR. Otherwise, the server MUST NOT include a ZONEVERSION option.
In the presentation format, the OPTION-CODE MUST be represented as the mnemonic 'ZONEVERSION', and the LABELCOUNT's corresponding zone name SHOULD be displayed (i.e., the last LABELCOUNT labels of the original QNAME) for easier human consumption.
OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for queries and MUST have the value of the length (in octets) of the OPTION-DATA for responses.
The LABELCOUNT field value MUST NOT count the null (root) label that terminates the original QNAME, and MUST be less than or equal to the number of labels in the original QNAME. The Root zone has a LABELCOUNT of 0.
The VERSION value for the SOA-SERIAL type MUST be a copy of the unsigned 32-bit SERIAL field of the SOA RR as defined in RFC 1035 Section 3.3.13. If a zone does not use SOA SERIAL for versioning, the name server SHOULD NOT include a ZONEVERSION option with type SOA-SERIAL.
The ZONEVERSION option is not transitive. A name server MUST NOT blindly copy the ZONEVERSION option from a received query into a subsequent outbound query, and MUST NOT send a ZONEVERSION option back to a client that did not request it.
The LABELCOUNT field encodes the zone name by reference: taking the last LABELCOUNT labels of the original QNAME yields the zone name. For example, QNAME 'a.b.c.example.com' with LABELCOUNT=2 indicates the zone 'example.com.'
The SOA-SERIAL ZONEVERSION type (TYPE value 0, mnemonic 'SOA-SERIAL') carries the zone's SOA SERIAL number. The EDNS(0) OPTION-LENGTH for this type MUST be set to 6 in responses (2 octets for LABELCOUNT+TYPE, 4 octets for the 32-bit SERIAL).
ZONEVERSION is a new EDNS(0) option (OPTION-CODE 19) that DNS clients include in queries to request zone version information, and that authoritative servers include in responses to provide it. It is designed for hop-to-hop use only and is OPTIONAL to implement.
IANA created the 'ZONEVERSION TYPE Values' registry under 'Domain Name System (DNS) Parameters'. Range 0–245 requires Specification Required, 246–254 is Private Use, 255 is Reserved. Initial entry: TYPE 0 = SOA-SERIAL. Future assignments in 1–245 use Specification Required procedure.
IANA registered ZONEVERSION as a new DNS EDNS(0) option with code value 19 in the 'DNS EDNS0 Option Codes (OPT)' registry, with status 'Standard' referencing RFC 9660.
EDNS extension data is not covered by RRSIG records, so the authenticity and integrity of ZONEVERSION data cannot be verified using DNSSEC. It could theoretically be tampered with by an on-path attacker when DNS transport is unencrypted. ZONEVERSION should be used only for troubleshooting and debugging.
To certify the trustworthiness of ZONEVERSION data, an encrypted and authenticated DNS transport, TSIG (RFC 8945), or SIG(0) (RFC 2931) must be used. Authenticating the SOA-SERIAL value requires comparing it against a separate DNSSEC-signed SOA query, subject to loose coherency caveats.
ZONEVERSION cannot be used to check the correctness of an entire zone; ZONEMD (RFC 8976) is better suited for zone integrity verification. ZONEVERSION only correlates a specific answer with a zone version and provides no special integrity function beyond a normal field value.
The ZONEVERSION OPTION-DATA for responses consists of three fields: a 1-octet unsigned LABELCOUNT indicating how many trailing labels of the original QNAME form the zone name, a 1-octet unsigned TYPE distinguishing the version format, and a variable-length opaque VERSION octet string. The query OPTION-DATA is omitted entirely.