The DNS Zone Version (ZONEVERSION) Option NIC Chile
Miraflores 222, piso 14 Santiago CP 8320198 Chile +56 2 29407700 hsalgado@nic.cl
DigitalOcean
101 6th Ave New York NY 10013 United States of America mvergara@digitalocean.com
Verisign
12061 Bluemont Way Reston VA 20190 United States of America +1 703 948-3200 dwessels@verisign.com https://verisign.com
OPS dnsop zoneversion The DNS ZONEVERSION option is a way for DNS clients to request, and for authoritative DNS servers to provide, information regarding the version of the zone from which a response is generated. The SERIAL field from the Start of Authority (SOA) resource record (RR) is a good example of a zone's version, and it is the only one defined by this specification. Additional version types may be defined by future specifications. Including zone version data in a response simplifies and improves the quality of debugging and diagnostics since the version and the DNS answer are provided atomically. This can be especially useful for zones and DNS providers that leverage IP anycast or multiple backend systems. It functions similarly to the DNS Name Server Identifier (NSID) option described in RFC 5001.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
    • .  Requirements Language
    • .  Terminology
  • .  The ZONEVERSION Option
    • .  Wire Format
    • .  Presentation Format
  • .  ZONEVERSION Processing
    • .  Initiators
    • .  Responders
      • .  Responding to Invalid ZONEVERSION Queries
      • .  ZONEVERSION Is Not Transitive
  • .  The SOA-SERIAL ZONEVERSION Type
    • .  Type SOA-SERIAL Presentation Format
  • .  Example Usage
  • .  IANA Considerations
    • .  DNS EDNS(0) Option Code Registration
    • .  ZONEVERSION TYPE Values Registry
      • .  Designated Expert Review Directives
  • .  Security Considerations
  • .  Normative References
  • .  Informative References
  • .  Implementation Considerations
  • .  Implementation References
  • Acknowledgements
  • Authors' Addresses
Introduction The ZONEVERSION option allows DNS queriers to request, and authoritative DNS servers to provide, a token representing the version of the zone from which a DNS response was generated. It is similar to the NSID option , which can be used to convey the identification of a name server that generates a response. The Domain Name System allows data to be loosely coherent , because synchronization can never be instantaneous, and some uses of DNS do not require strong coherency anyway. This means that a record obtained by one response could be out of sync with other authoritative sources of the same data at the same point in time. This can make it difficult to debug some problems when there is a need to couple the data with the version of the zone it came from. Furthermore, in today's Internet, it is common for high volume and important DNS zones to utilize IP anycast () and/or load-balanced backend servers. In general, there is no way to ensure that two separate queries are delivered to the same server. The ZONEVERSION option both simplifies and improves DNS monitoring and debugging by directly associating the data and the version together in a single response. The SOA SERIAL field () is one example of zone versioning. Its purpose is to facilitate the distribution of zone data between primary and secondary name servers. It is also often useful in DNS monitoring and debugging. This document specifies the SOA SERIAL as one type of ZONEVERSION data. Some DNS zones may use other distribution and synchronization mechanisms that are not based on the SOA SERIAL number, such as relational databases or other proprietary methods. In those cases, the SOA SERIAL field may not be relevant with respect to the versioning of its content. To accommodate these use cases, new ZONEVERSION types could be defined in future specifications. Alternatively, zone operators may use one of the Private Use ZONEVERSION code points allocated by this specification. The ZONEVERSION option is OPTIONAL to implement by DNS clients and name servers. It is designed for use only when a name server provides authoritative response data. It is intended only for hop-to-hop communication and is not transitive.
Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Terminology In this document, "original QNAME" is used to mean what the DNS terminology document calls "QNAME (original)":
The name actually sent in the Question section in the original query, which is always echoed in the (final) reply in the Question section when the QR bit is set to 1.
In this document, an "enclosing zone" of a domain name means a zone in which the domain name is present as an owner name or any parent of that zone. For example, if B.C.EXAMPLE and EXAMPLE are zones but C.EXAMPLE is not, the domain name A.B.C.EXAMPLE has B.C.EXAMPLE, EXAMPLE, and the root as enclosing zones.
The ZONEVERSION Option This document specifies a new EDNS(0) option, ZONEVERSION, which can be used by DNS clients and servers to provide information regarding the version of the zone from which a response is generated.
Wire Format The ZONEVERSION option is encoded as follows: OPTION-CODE for the ZONEVERSION option is 19. 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. OPTION-DATA for the ZONEVERSION option is omitted in queries. For responses, it is composed of three fields:
  • an unsigned 1-octet Label Count (LABELCOUNT) indicating the number of labels for the name of the zone that VERSION value refers to
  • an unsigned 1-octet type number (TYPE) distinguishing the format and meaning of VERSION
  • an opaque octet string conveying the zone version data (VERSION)
Diagram with the OPTION-DATA Format for the ZONEVERSION Option +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | LABELCOUNT | TYPE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | VERSION | / / +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The LABELCOUNT field indicates the name of the zone that the ZONEVERSION option refers to, by means of taking the last LABELCOUNT labels of the original QNAME. For example, an answer with QNAME "a.b.c.example.com" and a ZONEVERSION option with a LABELCOUNT of value 2 indicates that the zone name in which this ZONEVERSION refers to is "example.com.". In the case of a downward referral response, the LABELCOUNT number helps to differentiate between the parent and child zones, where the parent is authoritative for some portion of the QNAME above a zone cut. Also, if the ANSWER section has more than one RR set with different zones (like a CNAME and a target name in another zone), the number of labels in the QNAME disambiguates such a situation. The value of the LABELCOUNT field MUST NOT count the null (root) label that terminates the original QNAME. The value of the LABELCOUNT field MUST be less than or equal to the number of labels in the original QNAME. The Root zone (".") has a LABELCOUNT field value of 0.
Presentation Format The presentation format of the ZONEVERSION option is as follows: The OPTION-CODE field MUST be represented as the mnemonic value ZONEVERSION. The OPTION-LENGTH field MAY be omitted, but if present, it MUST be represented as an unsigned decimal integer. The LABELCOUNT value of the OPTION-DATA field MAY be omitted, but if present, it MUST be represented as an unsigned decimal integer. The corresponding zone name SHOULD be displayed (i.e., LABELCOUNT labels of the original QNAME) for easier human consumption. The TYPE and VERSION fields of the option SHOULD be represented according to each specific TYPE.
ZONEVERSION Processing
Initiators A DNS client MAY signal its support and desire for zone version information by including an empty ZONEVERSION option in the EDNS(0) OPT pseudo-RR of a query to an authoritative name server. An empty ZONEVERSION option has OPTION-LENGTH set to zero. A DNS client SHOULD NOT send the ZONEVERSION option to non-authoritative name servers. A DNS client MUST NOT include more than one ZONEVERSION option in the OPT pseudo-RR of a DNS query.
Responders A name server that (a) understands the ZONEVERSION option, (b) receives a query with the ZONEVERSION option, (c) is authoritative for one or more enclosing zones of the original QNAME, and (d) chooses to honor a particular ZONEVERSION request responds by including a TYPE and corresponding VERSION value in a ZONEVERSION option in an EDNS(0) OPT pseudo-RR in the response message. Otherwise, a server MUST NOT include a ZONEVERSION option in the response. A name server MAY include more than one ZONEVERSION option in the response if it supports multiple TYPEs. A name server MAY also include more than one ZONEVERSION option in the response if it is authoritative for more than one enclosing zone of the original QNAME. A name server MUST NOT include more than one ZONEVERSION option for a given TYPE and LABELCOUNT. Note: the ZONEVERSION option should be included for any response satisfying the criteria above including, but not limited to, the following:
  • Downward referral (see "Referrals" in ), even though the response's Authoritative Answer bit is not set. In this case, the ZONEVERSION data MUST correspond to the version of the referring zone.
  • Name error (NXDOMAIN), even though the response does not include any Answer section RRs.
  • NODATA (), even though the response does not include any Answer section RRs.
  • Server failure (SERVFAIL) when the server is authoritative for the original QNAME.
Responding to Invalid ZONEVERSION Queries A name server that understands the ZONEVERSION option MUST return a FORMERR response when:
  • The ZONEVERSION OPTION-LENGTH is not zero.
  • More than one ZONEVERSION option is present.
ZONEVERSION Is Not Transitive The ZONEVERSION option is not transitive. A name server (recursive or otherwise) MUST NOT blindly copy the ZONEVERSION option from a query it receives into a subsequent query that it sends onward to another server. A name server MUST NOT send a ZONEVERSION option back to a client that did not request it.
The SOA-SERIAL ZONEVERSION Type The first and only ZONEVERSION option TYPE defined in this document is a zone's serial number as found in the Start of Authority (SOA) RR. As mentioned previously, some DNS zones may use alternative distribution and synchronization mechanisms that are not based on the SOA SERIAL number, and the SERIAL field may not be relevant with respect to the versioning of zone content. In those cases, a name server SHOULD NOT include a ZONEVERSION option with type SOA-SERIAL in a reply. The value for this type is "0". The mnemonic for this type is "SOA-SERIAL". The EDNS(0) OPTION-LENGTH for this type MUST be set to "6" in responses. 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 .
Type SOA-SERIAL Presentation Format The presentation format of this type content is as follows:
  • The TYPE field MUST be represented as the mnemonic value "SOA-SERIAL".
  • The VERSION field MUST be represented as an unsigned decimal integer.
Example Usage A name server that (a) implements this specification, (b) receives a query with the ZONEVERSION option, (c) is authoritative for the zone of the original QNAME, and (d) utilizes the SOA SERIAL field for versioning of said zone should include a ZONEVERSION option in its response. In the response's ZONEVERSION option, the EDNS(0) OPTION-LENGTH would be set to 6 and the OPTION-DATA would consist of the 1-octet LABELCOUNT, the 1-octet TYPE with value 0, and the 4-octet SOA-SERIAL value. The example below demonstrates expected output of a diagnostic tool that implements the ZONEVERSION option, displaying a response from a compliant authoritative DNS server:
Example Usage and Dig Output $ dig @ns.example.com www.example.com aaaa +zoneversion \ +norecurse +nocmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 \ ; (example.com.)") ;; QUESTION SECTION: ;www.example.com. IN AAAA ;; ANSWER SECTION: www.example.com. 43200 IN AAAA 2001:db8::80 ;; AUTHORITY SECTION: example.com. 43200 IN NS ns.example.com. ;; ADDITIONAL SECTION: ns.example.com. 43200 IN AAAA 2001:db8::53 ;; Query time: 15 msec ;; SERVER: 2001:db8::53#53(2001:db8::53) (UDP) ;; WHEN: dom jul 30 19:51:04 -04 2023 ;; MSG SIZE rcvd: 129
IANA Considerations
DNS EDNS(0) Option Code Registration This document defines a new EDNS(0) option, entitled "ZONEVERSION" (see ), with the assigned value of 19 from the "DNS EDNS0 Option Codes (OPT)" registry: DNS EDNS0 Option Codes (OPT) Registry
Value Name Status Reference
19 ZONEVERSION Standard RFC 9660
ZONEVERSION TYPE Values Registry IANA has created and will maintain a new registry called "ZONEVERSION TYPE Values" in the "Domain Name System (DNS) Parameters" registry group as follows: Registration Procedures for the ZONEVERSION TYPE Values Registry
Range Registration Procedures
0-245 Specification Required
246-254 Private Use
255 Reserved
Initial values for the "ZONEVERSION TYPE Values" registry are given below; future assignments in the 1-245 values range are to be made through Specification Required . Assignments consist of a TYPE value as an unsigned 8-bit integer recorded in decimal, a Mnemonic name as an uppercase ASCII string with a maximum length of 15 characters, and the required document reference. ZONEVERSION TYPE Values Registry
ZONEVERSION TYPE Mnemonic Reference
0 SOA-SERIAL RFC 9660
1-245 Unassigned
246-254 Reserved for Private Use RFC 9660
255 Reserved RFC 9660
The change controller for this registry is IETF.
Designated Expert Review Directives The allocation procedure for new code points in the "ZONEVERSION TYPE Values" registry is Specification Required, thus review is required by a designated expert as stated in . When evaluating requests, the expert should consider the following:
  • Duplication of code point allocations should be avoided.
  • A Presentation Format section should be provided with a clear code point mnemonic.
  • The referenced document and stated use of the new code point should be appropriate for the intended use of a ZONEVERSION TYPE assignment. In particular, the reference should state clear instructions for implementers about the syntax and semantic of the data. Also, the length of the data must have proper limits.
The expert reviewing the request MUST respond within 10 business days.
Security Considerations The EDNS extension data is not covered by RRSIG records, so there's no way to verify its authenticity nor integrity using DNSSEC, and it could theoretically be tampered with by a person in the middle if the transport is made by insecure means. Caution should be taken to use the EDNS ZONEVERSION data for any means besides troubleshooting and debugging. If there's a need to certify the trustworthiness of ZONEVERSION, it will be necessary to use an encrypted and authenticated DNS transport, a transaction signature (TSIG) , or SIG(0) . If there's a need to authenticate the data origin for the ZONEVERSION value, an answer with the SOA-SERIAL type as defined above could be compared to a separate regular SOA query with a DO flag, whose answer shall be DNSSEC signed. Since these are separate queries, the caveats about loose coherency already stated in the () would apply. With the SOA-SERIAL type defined above, there's no risk on disclosure of private information, as the SERIAL of the SOA record is already publicly available. Please note that the ZONEVERSION option cannot be used for checking the correctness of an entire zone in a server. For such cases, the ZONEMD record might be better suited for such a task. ZONEVERSION can help identify and correlate a specific answer with a version of a zone, but it has no special integrity or verification function besides a normal field value inside a zone, as stated above.
Normative References Domain names - concepts and facilities This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. Domain names - implementation and specification This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Extension Mechanisms for DNS (EDNS(0)) The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Zoneversion Implementations commit f5f68a0 DNS Request and Transaction Signatures ( SIG(0)s ) This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK] Definitions for talking about directories When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, "directories". This memo provides information for the Internet community. Operation of Anycast Services As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. DNS Name Server Identifier (NSID) Option With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. [STANDARDS-TRACK] Secret Key Transaction Authentication for DNS (TSIG) This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. Message Digest for DNS Zones This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. DNS Terminology The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.
Implementation Considerations With very few exceptions, EDNS(0) option values in a response are independent of the queried name. This is not the case for ZONEVERSION, so its implementation may be more or less difficult, depending on how EDNS(0) options are handled in the name server.
Implementation References There is a patched NSD server (version 4.7.0) with support for ZONEVERSION as well as live test servers installed for compliance tests. Also, there is a client command "dig" with added zoneversion support, along with test libraries in Perl, Python, and Go. See for more information.
Acknowledgements The authors are thankful for all the support and comments made in the DNSOP Working Group mailing list, chats, and discussions. A special thanks for suggestions to generalize the option using a registry of types from and , suggestions for implementation from , clarifications on security from , zone name disambiguation from and , and reviews from and .
Authors' Addresses NIC Chile
Miraflores 222, piso 14 Santiago CP 8320198 Chile +56 2 29407700 hsalgado@nic.cl
DigitalOcean
101 6th Ave New York NY 10013 United States of America mvergara@digitalocean.com
Verisign
12061 Bluemont Way Reston VA 20190 United States of America +1 703 948-3200 dwessels@verisign.com https://verisign.com