<?xml version='1.0'encoding='utf-8'?> <?xml-model href="rfc7991bis.rnc"?> <?rfc toc="yes" ?> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes" ?> <?rfc compact="yes"?> <?rfc subcompact="no" ?> <?rfc linkmailto="no" ?> <?rfc editing="no" ?> <?rfc comments="yes" ?> <?rfc inline="yes"?> <?rfc rfcedstyle="yes"?> <?rfc-ext allow-markup-in-artwork="yes" ?> <?rfc-ext include-index="no" ?>encoding='UTF-8'?> <!-- pre-edited by ST 08/07/24 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"><!ENTITY RFC3254 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3254.xml">]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"xmlns:x="http://purl.org/net/xml2rfc/ext"number="9660" consensus="true" xml:lang="en" ipr="trust200902" category="std" docName="draft-ietf-dnsop-zoneversion-11" tocInclude="true" symRefs="true" sortRefs="true" version="3"submissionType="IETF">submissionType="IETF" updates="" obsoletes=""> <front> <title abbrev="DNS ZONEVERSION Option">The DNS Zone Version (ZONEVERSION) Option</title> <seriesInfo name="RFC" value="9660"/> <author fullname="Hugo Salgado" initials="H." surname="Salgado"> <organization>NIC Chile</organization> <address> <postal> <street>Miraflores 222, piso 14</street> <city>Santiago</city> <code>CP 8320198</code><country>CL</country><country>Chile</country> </postal> <phone>+56 2 29407700</phone> <email>hsalgado@nic.cl</email> </address> </author> <author fullname="Mauricio Vergara Ereche" initials="M." surname="Vergara"> <organization>DigitalOcean</organization> <address> <postal> <street>101 6th Ave</street> <city>New York</city><code>NY 10013</code> <country>US</country><region>NY</region> <code>10013</code> <country>United States of America</country> </postal> <email>mvergara@digitalocean.com</email> </address> </author> <author fullname="Duane Wessels" initials="D." surname="Wessels"> <organization>Verisign</organization> <address> <postal> <street>12061 Bluemont Way</street> <city>Reston</city> <region>VA</region> <code>20190</code><country>US</country><country>United States of America</country> </postal> <phone>+1 703 948-3200</phone> <email>dwessels@verisign.com</email> <uri>https://verisign.com</uri> </address> </author> <dateyear="2024"/> <area>General</area> <workgroup>Internet Engineering Task Force</workgroup>year="2024" month="September"/> <area>OPS</area> <workgroup>dnsop</workgroup> <keyword>zoneversion</keyword> <abstract> <t>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 StartOfof 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.</t> <t>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 inRFC5001.</t>RFC 5001.</t> </abstract> </front> <middle> <sectionanchor="intro" title="Introduction">anchor="intro"> <name>Introduction</name> <t>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 <xref target="RFC5001"/>, which can be used to convey the identification of a name server that generates a response.</t> <t>The Domain Name System allows data to be loosely coherent <xref target="RFC3254"/>, 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 beout-of-syncout 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<xref(<xref target="RFC4786" sectionFormat="of"section="4.9"/>section="4.9"/>) 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 the DNS monitoring and debugging by directly associating the data and the version together in a single response.</t> <t>The SOA Serial field (<xref target="RFC1034" sectionFormat="of" section="4.3.5"/>) 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.</t> <t>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 thosecasescases, 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 theprivate usePrivate Use ZONEVERSION code points allocated by this specification.</t> <t>The ZONEVERSION option isOPTIONAL<bcp14>OPTIONAL</bcp14> 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.</t><section title="Requirements Language"><section> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="BCP14"/> (<xref target="RFC2119"/>,target="RFC2119"/> <xreftarget="RFC8174"/>)target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section><section title="Terminology"><section> <name>Terminology</name> <t>In thisdocumentdocument, "original QNAME" is used to mean what the DNS terminology document <xref target="RFC9499"/> calls "QNAME (original)":</t><blockquote><t>The<blockquote>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 to1.</t></blockquote>1.</blockquote> <t>In this document, an "enclosing zone" of a domain name means a zone in which the domain name is present as an ownername,name or any parent of that zone. For example, if B.C.EXAMPLE and EXAMPLE arezones,zones but C.EXAMPLE is not, the domain name A.B.C.EXAMPLE has B.C.EXAMPLE, EXAMPLE, and the root as enclosing zones.</t> </section> </section> <sectionanchor="theoption" title="Theanchor="theoption"> <name>The ZONEVERSIONOption">Option</name> <!--[rfced] Section 2. Please confirm if Section 6.1.2 of RFC 6891 is the correct reference as we do not see "EDNS(0)" specifically mentioned in Section 6.1.2. Original: This document specifies a new EDNS(0) (Section 6.1.2 of [RFC6891]) 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. --> <t>This document specifies a new EDNS(0) (<xref target="RFC6891" section="6.1.2"/>) 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.</t><section title="Wire Format"><section> <name>Wire Format</name> <t>The ZONEVERSION option is encoded as follows:</t> <t>OPTION-CODE for the ZONEVERSION option is<TBD>.</t>19.</t> <t>OPTION-LENGTH for the ZONEVERSION optionMUST<bcp14>MUST</bcp14> have a value of 0 forqueries,queries andMUST<bcp14>MUST</bcp14> have the value of the length (in octets) of the OPTION-DATA for responses.</t> <t>OPTION-DATA for the ZONEVERSION option is omitted in queries. Forresponsesresponses, it is composed of three fields:</t> <ul><li>An<li>an unsigned 1-octet Label Count (LABELCOUNT) indicating the number of labels for the name of the zone that VERSION value refersto.</li> <li>Anto</li> <li>an unsigned 1-octet type number (TYPE)that distinguishesdistinguishing the format and meaning ofVERSION.</li> <li>AnVERSION</li> <li>an opaque octet string conveying the zone version data(VERSION).</li>(VERSION)</li> </ul><!-- Some RFCs include the OPTION-CODE and OPTION-LENGTH fields in the protocol block diagram --><figure> <name>Diagram with the OPTION-DATAformatFormat for the ZONEVERSIONoption</name>Option</name> <artset> <artwork type="ascii-art" name="zoneversion.txt"> <![CDATA[ +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | LABELCOUNT | TYPE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | VERSION | / / +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+]]> </artwork>]]></artwork> </artset> </figure> <t> 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 value2,2 indicates that the zone namethatin which this ZONEVERSION refers to is "example.com.".</t> <!--[rfced] Section 2.1. Please clarify what the LABELCOUNT number is differentiating - is it the type of servers or the parent and child servers specifically? Original: The LABELCOUNT number helps to differentiate in the case of a downward referral response, where the parent server is authoritative for some portion of the QNAME that differs from a child server that is below the zone cut. Perhaps: In the case of a downward referral response, the LABELCOUNT number helps to differentiate between the parent and child servers, where the parent server is authoritative for some portion of the QNAME and the child server is below the zone cut. --> <t>The LABELCOUNT number helps to differentiate in the case of a downward referral response, where the parent server is authoritative for some portion of the QNAME that differs from a child server that is below the zone cut. Also, if the ANSWER section has more than one RR set with different zones (like a CNAME and a target name in anotherzone)zone), the number of labels in the QNAME disambiguates such a situation.</t> <t>The value of the LABELCOUNT fieldMUST NOT<bcp14>MUST NOT</bcp14> count the null (root) label that terminates the original QNAME. The value of the LABELCOUNT fieldMUST<bcp14>MUST</bcp14> be less than or equal to the number of labels in the original QNAME. The Root zone (".") has a LABELCOUNT field value of 0.</t> </section> <sectionanchor="optionpresentation" title="Presentation Format">anchor="optionpresentation"> <name>Presentation Format</name> <t>The presentation format of the ZONEVERSION option is as follows:</t> <t>The OPTION-CODE fieldMUST<bcp14>MUST</bcp14> be represented as the mnemonic value ZONEVERSION.</t> <t>The OPTION-LENGTH fieldMAY<bcp14>MAY</bcp14> be omitted, but ifpresentpresent, itMUST<bcp14>MUST</bcp14> be represented as an unsigned decimal integer.</t> <t>The LABELCOUNT value of OPTION-DATA fieldMAY<bcp14>MAY</bcp14> be omitted, but ifpresentpresent, itMUST<bcp14>MUST</bcp14> be represented as an unsigned decimal integer. The corresponding zone nameSHOULD<bcp14>SHOULD</bcp14> be displayed (i.e., LABELCOUNT labels of the original QNAME) for easier human consumption.</t> <t>The TYPE and VERSION fields of the optionSHOULD<bcp14>SHOULD</bcp14> be represented according to each specific TYPE.</t> </section> </section><section title="ZONEVERSION Processing"> <section title="Initiators"><section> <name>ZONEVERSION Processing</name> <section> <name>Initiators</name> <t>A DNS clientMAY<bcp14>MAY</bcp14> 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.</t> <t>A DNS clientSHOULD NOT<bcp14>SHOULD NOT</bcp14> send the ZONEVERSION option to non-authoritative name servers.</t> <t>A DNS clientMUST NOT<bcp14>MUST NOT</bcp14> include more than one ZONEVERSION option in the OPT RR of a DNS query.</t> </section><section title="Responders"><section> <name>Responders</name> <t>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.</t> <t>Otherwise, a serverMUST NOT<bcp14>MUST NOT</bcp14> include a ZONEVERSION option in the response.</t> <t>A name serverMAY<bcp14>MAY</bcp14> include more than one ZONEVERSION option in the response if it supports multiple TYPEs. A name serverMAY<bcp14>MAY</bcp14> 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 serverMUST NOT<bcp14>MUST NOT</bcp14> include more than one ZONEVERSION option for a given TYPE and LABELCOUNT.</t> <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> <t>Note: the ZONEVERSION option should be included for any response satisfying the criteriaabove,above including, but not limited to, the following:</t> <ul> <li>Downward referral (see "Referrals" in <xref target="RFC9499" section="4"/>), even though the response's Authoritative Answer bit is not set. In this case, the ZONEVERSION dataMUST<bcp14>MUST</bcp14> correspond to the version of the referring zone.</li> <li>Name error (NXDOMAIN), even though the response does not include any Answer section RRs.</li> <li>NODATA (<xref target="RFC9499" section="3"/>), even though the response does not include any Answer section RRs.</li> <li>Server failure (SERVFAIL) when the server is authoritative for the original QNAME.</li> </ul><section title="Responding<section> <name>Responding to Invalid ZONEVERSIONQueries">Queries</name> <t>A name server that understands the ZONEVERSION optionMUST<bcp14>MUST</bcp14> return a FORMERR response when:</t> <ul> <li>The ZONEVERSION OPTION-LENGTH is not zero.</li> <li>More than one ZONEVERSION option is present.</li> </ul> </section><section title="ZONEVERSION<section> <name>ZONEVERSION Is NotTransitive">Transitive</name> <t>The ZONEVERSION option is not transitive. A name server (recursive or otherwise)MUST NOT<bcp14>MUST NOT</bcp14> blindly copy the ZONEVERSION option from a query it receives into asubsquentsubsequent query that it sends onward to another server. A name serverMUST NOT<bcp14>MUST NOT</bcp14> send a ZONEVERSION option back to a clientwhichthat did not request it.</t> </section> </section> </section><section title="The<section> <name>The SOA-SERIAL ZONEVERSIONType">Type</name> <t>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.</t> <t>As mentioned previously, some DNS zones may use alternative distribution and synchronization mechanisms that are not based on the SOA Serialnumbernumber, and the Serial field may not be relevant with respect to the versioning of zone content. In thosecasescases, a name serverSHOULD NOT<bcp14>SHOULD NOT</bcp14> include a ZONEVERSION option with type SOA-SERIAL in a reply.</t> <t>The value for this typeis: 0</t>is "0".</t> <t>The mnemonicoffor this typeis: SOA-SERIAL.</t>is "SOA-SERIAL".</t> <t>The EDNS(0) OPTION-LENGTH for this typeMUST<bcp14>MUST</bcp14> be set to6"6" in responses.</t> <t>The VERSION value for the SOA-SERIAL typeMUST<bcp14>MUST</bcp14> be a copy of the unsigned 32-bit SERIAL field of the SOA RR, as defined in <xref target="RFC1035" section="3.3.13"/>.</t> <sectionanchor="typepresentation" title="Typeanchor="typepresentation"> <name>Type SOA-SERIAL PresentationFormat">Format</name> <t>The presentation format of this type content is as follows:</t><t>The<ul empty="true"> <li>The TYPE fieldMUST<bcp14>MUST</bcp14> be represented as the mnemonic value"SOA-SERIAL".</t> <t>The"SOA-SERIAL".</li> <li>The VERSION fieldMUST<bcp14>MUST</bcp14> be represented as an unsigned decimalinteger.</t>integer.</li> </ul> </section> </section> <sectionanchor="usage" title="Example usage">anchor="usage"> <name>Example Usage</name> <t>A name serverwhichthat (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 SOAserialSerial field for versioning of said zone should include a ZONEVERSION option in its response. In the response's ZONEVERSIONoptionoption, 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-octetSOA SERIALSOA-SERIAL value.</t> <t>The example below demonstrates expected output of a diagnostic tool that implements the ZONEVERSION option, displaying a response from a compliant authoritative DNS server:</t> <figure> <!--[rfced] Figure 2 (Section 5) a) We updated <artwork> to <sourcecode> and left the "type" attribute set to "dns-rr". Please review and let us know if this is correct or if any further changes are needed. Note that the list of preferred values for "type" are listed here: https://www.rfc-editor.org/materials/sourcecode-types.txt. b) The following lines exceed the 72-character limit. Please let us know how you would like to break/wrap the lines. Original: ; <<>> DiG 9.17.14-patched <<>> @ns.example.com www.example.com aaaa +zoneversion (14 characters over) ; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 (example.com.)") (7 characters over) --> <name>ExampleusageUsage anddig output</name> <artworkDig Output</name> <sourcecode type="dns-rr"> <![CDATA[ $ dig @ns.example.com www.example.com aaaa +zoneversion +norecurse ; <<>> DiG 9.17.14-patched <<>> @ns.example.com www.example.com aaaa +zoneversion ; (1 server found) ;; global options: +cmd ;; 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 ]]></artwork></sourcecode> </figure> </section> <sectionanchor="Acknowledgements" title="Acknowledgements"> <t>The authors thanks all the comments and support made in the DNSOP mailing list, chats and discussions. Special thanks for the suggestions to generalize the option using a registry of types from <contact fullname="Petr Špaček" asciiFullname="Petr Spacek"/> and Florian Obser, suggestions for implementation from <contact fullname="Stéphane Bortzmeyer" asciiFullname="Stephane Bortzmeyer"/>, security clarifications from George Michaelson, zone name disambiguation from Joe Abley and Brian Dickson, and reviews from Tim Wicinski and Peter Thomassen.</t> </section> <section anchor="IANA" title="IANA Considerations"> <section title="DNSanchor="IANA"> <name>IANA Considerations</name> <section> <name>DNS EDNS0 Option CodeRegistration">Registration</name> <t>This document defines a new EDNS0 option, entitledZONEVERSION"ZONEVERSION" (see <xref target="theoption"/>),and assigns awith the assigned value of<TBD>19 from theDNS"DNS EDNS0 Option Codes(OPT) Option space:</t>(OPT)" registry:</t> <table> <name>DNS EDNS0 Optioncode</name>Codes (OPT) Registry</name> <thead><tr><th>Value</th><th>Name</th><th>Status</th><th>Reference</th></tr><tr><th>Value</th> <th>Name</th><th>Status</th><th>Reference</th></tr> </thead> <tbody><tr><th><TBD></th><th>ZONEVERSION</th><th>Standard</th><th>[this document]</th></tr><tr><th>19</th> <th>ZONEVERSION</th><th>Standard</th><th>RFC 9660</th></tr> </tbody> </table> </section><section title="ZONEVERSION Registry"><section> <name>ZONEVERSION TYPE Values Registry</name> <!-- [rfced] We have included some specific questions about the IANA text below. In addition to responding to those questions, please review all of the IANA-related updates carefully and let us know if any further updates are needed. a) Section 7.2. In Tables 2 and 3, for the range "255", should Registration Procedures and Mnemonic, respectively, be "Reserved" instead of "Reserved for future expansion" per RFC 8126 (see the "ZONEVERSION TYPE Values" registry at https://www.iana.org/assignments/dns-parameters)? Current: + - - - - - - - - - - - - - - - - - - + 255 | Reserved for future expansion Perhaps: + - - - - - - - - - - - - - - - - - - + 255 | Reserved b) Section 7.2. As "Standards Action" is a registration policy, should the change controller be updated to "IETF" instead (per https://www.iana.org/help/protocol-registration#issues) as shown below? Original: The change control for this registry should be by means of an Standard action. Perhaps: The change controller for this registry is IETF. c) Sections 7.2 and 7.2.1. FYI: As BCP 26 is only comprised of RFC 8126, we cited RFC 8126 instead of BCP 26 as shown below. Please let us know of any objections. Current: 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 [RFC8126]. Allocation procedures for new code points in the "ZONEVERSION TYPE Values" registry require Specification Required review, and so it requires Expert Reviews as stated in [RFC8126]. d) Section 7.2.1. Per RFC 8126, "Specification Required" and "Expert Review" are separate polices that both require review by a "designated expert". Is the intension to say that the Specification Required policy requires review by a "designated expert" as shown below? Original: 7.2.1 Expert Review Directives Allocation procedures for new code points in the ZONEVERSION TYPE registry require Specification Required review, and so it requires Expert Reviews as stated in [BCP26]. The expert should consider the following points: The expert reviewing the request MUST approve or disapprove the request within 10 business days from when she or he received the expert review request. Perhaps: 7.2.1 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 [RFC8126]. When evaluating requests, the expert should consider the following: The expert reviewing the request MUST respond within 10 business days. --> <!-- <t>The ZONEVERSION option also definesaan 8-bit TYPE field, for which IANA is requested to create and maintain a new registry entitled "ZONEVERSION TYPE Values" (abbreviation ZONEVERSION) used by the ZONEVERSION option, inside the "Domain Name System (DNS) Parameters" group.Initial values</t> --> <t> IANA has created and will maintain a new registry called "ZONEVERSION TYPE Values" in the "Domain Name System (DNS) Parameters" registry group as follows:</t> <table> <name>Registration Procedures for the ZONEVERSION TYPE Values Registry</name> <thead> <tr><th>Range</th><th>Registration Procedures</th></tr> </thead> <tbody> <tr><th>0-245</th><th>Specification Required</th></tr> <tr><th>246-254</th><th>Private Use</th></tr> <tr><th>255</th><th>Reserved for future expansion</th></tr> </tbody> </table> <t> 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 Requiredreview<xreftarget="BCP26"/>.target="RFC8126"/>. 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.</t> <table> <name>ZONEVERSION TYPE Values Registry</name> <thead> <tr><th>ZONEVERSION TYPE</th><th>Mnemonic</th><th>Reference</th></tr> </thead> <tbody><tr><th>0</th><th>SOA-SERIAL</th><th>[this document]</th></tr> <tr><th>1-245</th><th>Unassigned</th><th></th></tr><tr><th>0</th><th>SOA-SERIAL</th><th>RFC 9660</th></tr> <tr><th>1-245</th><th>Unassigned</th><th/></tr> <tr><th>246-254</th><th>PrivateUse</th><th>[this document]</th></tr>Use</th><th>RFC 9660</th></tr> <tr><th>255</th><th>Reserved for futureexpansion</th><th>[this document]</th></tr>expansion</th><th>RFC 9660</th></tr> </tbody> </table> <t>The change control for this registry should be by means of an Standard action.</t><section title="Expert<section> <name>Expert ReviewDirectives">Directives</name> <t>Allocation procedures for new code points in theZONEVERSION"ZONEVERSION TYPE Values" registry require Specification Required review, and so it requires Expert Reviews as stated in <xreftarget="BCP26"/>.</t>target="RFC8126"/>.</t> <t>The expert should consider the following points:</t> <ul> <li>Duplication of code point allocations should be avoided.</li> <li>A Presentation Format section should beprovided,provided with a clear code point mnemonic.</li> <li>The referenced document and stated use of the new code point should be appropriate for the intended use of a ZONEVERSION TYPE assignment. Inparticularparticular, the reference should state clear instructions for implementers about the syntax and semantic of the data.AlsoAlso, theLengthlength of theDatadata must have proper limits.</li> </ul> <t>The expert reviewing the requestMUST<bcp14>MUST</bcp14> approve or disapprove the request within 10 business days from whenshe or he received the expert review request.</t>it was received.</t> </section> </section> </section> <sectionanchor="Security" title="Security Considerations">anchor="Security"> <name>Security Considerations</name> <t>The EDNS extension datait'sis not covered by RRSIG records, so there's no way to verify its authenticity nor integrity usingDNSSECDNSSEC, and it could theoretically be tampered with by aperson-in-the-middleperson 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.</t><t>If<!--[rfced] Should "TSIG" be expanded as "transaction signature" per RFC 8945, or is "TSIG" an RR, in which case it does not need to be expanded? Original: If there's a need to certify the ZONEVERSION trustworthiness, it will be necessary to use an encrypted and authenticated DNS transport, TSIG [RFC8945], or SIG(0) [RFC2931]. Perhaps: 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) [RFC8945], or SIG(0) [RFC2931]. --> <t>If there's a need to certify the trustworthiness of ZONEVERSION, it will be necessary to use an encrypted and authenticated DNS transport, TSIG <xref target="RFC8945"/>, or SIG(0) <xref target="RFC2931"/>.</t><t>If<!--[rfced] Please clarify what "others" is referring to. Is it only backend servers or are there additional items? Would it be clearer to perhaps update as "multiple backend systems" as shown below? Current: 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, with the cautions aboutAnycastanycast and others as already stated in the Introduction (Section 1). Perhaps: 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, with cautions about anycast and multiple backend systems as already stated in the Introduction (Section 1). --> <t>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, with cautions about anycast and others as already stated in the <xref target="intro"format="title"/>.</t>format="title"/> (<xref target="intro"/>).</t> <t>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.</t> <t>Please note that the ZONEVERSION optioncan notcannot be used for checking the correctness of an entire zone in a server. For such cases, the ZONEMD record <xreftarget="RFC8976">ZONEMD record</xref>target="RFC8976"/> might be better suitedatfor such a task. ZONEVERSION can help identify and correlate acertainspecific 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.</t> </section> </middle> <back><references title="Normative References"><references> <name>Normative References</name> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0014.xml"/>href="https://bib.ietf.org/public/rfc/bibxml9/reference.RFC.2119.xml"/> <!-- <xi:includehref="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0026.xml"/>href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0026.xml"/>--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.RFC.8174.xml"/> </references><references title="Informative References"> &RFC3254;<references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3254.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4786.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5001.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8945.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8976.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/> <reference anchor="ImplRef" target="https://github.com/huguei/rrserial"> <front> <title>Zoneversion Implementations</title><author fullname="Hugo Salgado" initials="H." surname="Salgado"><author> <organization/> </author> <date month="August" year="2023"/> </front> <refcontent>commit f5f68a0</refcontent> </reference> </references> <sectionanchor="implementationcons" title="Implementation Considerations">anchor="implementationcons"> <name>Implementation Considerations</name> <t>With very few exceptions, EDNS optionswhichthat elicit an EDNS option in the response are independent of the queried name. This is not the caseoffor ZONEVERSION, so its implementation may be more or lessdifficultdifficult, depending on how EDNS options are handled in the name server. </t> </section> <sectionanchor="implementation" title="Implementation References"> <t>There'sanchor="implementation"> <name>Implementation References</name> <t>There is a patched NSD serverversion 4.7.0(version 4.7.0) with support for ZONEVERSION with an experimentalopcode, withopcode as well as live test servers installed for compliance tests.AlsoAlso, there is a client command "dig" with added zoneversion support, along with test libraries in Perl,PythonPython, and Go.More information in the working documentSee <xreftarget="ImplRef"/>.</t>target="ImplRef"/> for more information.</t> </section><!-- Change Log v11 2024-07-19 DW SOA-SERIAL SHOULD NOT be included when<section anchor="Acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>The authors are thankful for all theSOA serial field is not relevant v10 2024-07-05 DW Responding to Invalid ZONEVERSION Queries v10 2024-07-05 DW Usesupport anddefine "enclosing zone" v09 2024-07-01 HS Accept somecommentsfrom Paul Woutersmade in the DNSOP Working Group mailing list, chats, andÉric Vyncke Discuss ballot position. v09 2024-07-01 DW Informational -> Proposed Standard v08 2024-06-11 DW Accept suggestion from John Levine Artart review. v07 2024-06-07 HS Editorial comments from Shawn M Emery during SECDIR Last Call review. v06 2024-05-14 DW Acceptdiscussions. A special thanks for suggestionsfrom D. Eastlake during WGLC. v05 2023-12-15 DW Rewrites for clarity. v05 2023-10-28 HS Minor edits from Tim Wicinski and AD clarification. v04 2023-08-03 MV Clarification on LABELCOUNT, typos and formatting. v04 2023-08-03 HS Changed nameto generalize the option using a registry ofFLAG fields, removed flag length, typostypes from <contact fullname="Petr Špaček"/> andminor edits. v03 2023-07-30 HS Added a label number<contact fullname="Florian Obser"/>, suggestions for implementation from <contact fullname="Stéphane Bortzmeyer"/>, clarifications on security from <contact fullname="George Michaelson"/>, zone namedisambiguation, typosdisambiguation from <contact fullname="Joe Abley"/> andminor edits. v02 2022-04-21 HS Upgraded<contact fullname="Brian Dickson"/>, and reviews fromRRSERIAL to ZONEVERSION,<contact fullname="Tim Wicinski"/> and <contact fullname="Peter Thomassen"/>.</t> </section> <!-- [rfced] Terminology a) Throughout the text, the following terminology appears to beversioning-agnostic. v01 2022-04-06 HS No changes, just for revive it after it expired v00 2021-06-11 HS No changes, just new filename as requested by DNSOP chairs for WG adoption v01 2021-06-01 HS Substantial changesused inconsistently. Please review these occurrences andenhancements from DNSOP discussion v00 2021-05-07 HS New filename as requested by WG chair,let us know if/how they may be made consistent. - EDNS(0) option vs. EDNS0 option vs. EDNS option - EDNS(0) OPT pseudo-RR vs. OPT RR [Note: are these terms the same or different?] - Serial field vs. SERIAL field [Note: are these terms different? Note that RFC 1034 uses "SERIAL field".] b) We notice inconsistencies with the following terms. We updated the text tocallreflect the form on the right foradoption v01 2020-01-27 HS No changes, just to avoid expiration v00 2017-04-27 HS Initial versionconsistency. Please let us know of any objections. - Anycast -> anycast (per RFCs 4786 and 5001) - Data -> data - Length -> length - private use -> Private Use (per RFC 8126) - serial field -> Serial field - serial number -> Serial number - SOA SERIAL -> SOA-SERIAL --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>