<?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    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
  <!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>
    <date year="2024"/>
    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup> year="2024" month="October"/>
    <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 SERIAL field from the Start Of 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.</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 in RFC5001.</t> RFC 5001.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="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 be out-of-sync 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 <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 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 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 SERIAL number, such as relational
        databases or other proprietary methods.  In those cases cases, the SOA
        Serial
        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 Private Use ZONEVERSION code
        points allocated by this specification.</t>

      <t>The ZONEVERSION option is OPTIONAL <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&nbsp;14 <xref target="BCP14"/> (<xref target="RFC2119"/>, target="RFC2119"/> <xref target="RFC8174"/>)
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>

      </section>

      <section title="Terminology">

      <section>
	<name>Terminology</name>
        <t>In this document document, "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 to 1.</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 owner name, name
          or any parent of that zone.  For example, if B.C.EXAMPLE and
          EXAMPLE are zones, 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>

    <section anchor="theoption" title="The anchor="theoption">
      <name>The ZONEVERSION Option"> Option</name>

      <t>This document specifies a new EDNS(0) (<xref target="RFC6891"
        section="6.1.2"/>) <xref target="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>

      <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 &lt;TBD&gt;.</t> 19.</t>

        <t>OPTION-LENGTH for the ZONEVERSION option MUST <bcp14>MUST</bcp14> have a value of 0 for queries, queries
          and MUST <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.  For responses responses, 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 refers to.</li>

            <li>An to</li>

            <li>an unsigned 1-octet type number (TYPE) that distinguishes distinguishing the format and meaning of VERSION.</li>

            <li>An VERSION</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-DATA format Format for the ZONEVERSION option</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 value 2, 2 indicates that the zone name that in which this ZONEVERSION refers to is "example.com.".</t>

      <t>The LABELCOUNT number helps to differentiate in

      <t>In the case of a downward referral response, the LABELCOUNT number helps to differentiate between the parent and child zones, where the parent server is authoritative for some portion of the QNAME that differs from above 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 another zone) zone), the number of labels in the QNAME disambiguates such a situation.</t>

      <t>The value of the LABELCOUNT field MUST NOT <bcp14>MUST NOT</bcp14> count the null (root) label that terminates the original QNAME. The value of the LABELCOUNT field MUST <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>

        <section anchor="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 field MUST <bcp14>MUST</bcp14> be represented as the mnemonic value ZONEVERSION.</t>

          <t>The OPTION-LENGTH field MAY <bcp14>MAY</bcp14> be omitted,
            but if present present, it MUST <bcp14>MUST</bcp14> be represented as an unsigned decimal integer.</t>

          <t>The LABELCOUNT value of the OPTION-DATA field MAY <bcp14>MAY</bcp14> be omitted,
            but if present present, it MUST <bcp14>MUST</bcp14> be represented as an unsigned decimal integer.
            The corresponding zone name SHOULD <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 option SHOULD <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 client MAY <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 client SHOULD NOT <bcp14>SHOULD NOT</bcp14> send the ZONEVERSION option to non-authoritative name servers.</t>
        <t>A DNS client MUST NOT <bcp14>MUST NOT</bcp14> include more than one ZONEVERSION option in the OPT RR pseudo-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 server MUST NOT <bcp14>MUST NOT</bcp14> include a ZONEVERSION option in the response.</t>

        <t>A name server MAY <bcp14>MAY</bcp14> include more than one ZONEVERSION option in
           the response if it supports multiple TYPEs. A name server MAY <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 server MUST NOT <bcp14>MUST NOT</bcp14> include more than one ZONEVERSION
        option for a given TYPE and LABELCOUNT.</t>

        <t>Note: the ZONEVERSION option should be included for any response
          satisfying the criteria above, 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 data MUST <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 ZONEVERSION Queries"> Queries</name>

          <t>A name server that understands the ZONEVERSION option MUST <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 Not Transitive"> 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 a subsquent subsequent query that
            it sends onward to another server.  A name server MUST NOT <bcp14>MUST NOT</bcp14>
            send a ZONEVERSION option back to a client which that did not
            request it.</t>

        </section>
      </section>
    </section>

    <section title="The

    <section>
      <name>The SOA-SERIAL ZONEVERSION Type"> 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
        Serial number
        SERIAL number, and the Serial SERIAL field may not be relevant with
        respect to the versioning of zone content.  In those cases cases, a
        name server SHOULD NOT <bcp14>SHOULD NOT</bcp14> include a ZONEVERSION option with type
        SOA-SERIAL in a reply.</t>

      <t>The value for this type is: 0</t> is "0".</t>

      <t>The mnemonic of for this type is: SOA-SERIAL.</t> is "SOA-SERIAL".</t>

      <t>The EDNS(0) OPTION-LENGTH for this type MUST <bcp14>MUST</bcp14> be set to 6 "6" in responses.</t>

      <t>The VERSION value for the SOA-SERIAL type MUST <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>

        <section anchor="typepresentation" title="Type anchor="typepresentation">
	  <name>Type SOA-SERIAL Presentation Format"> Format</name>
          <t>The presentation format of this type content is as follows:</t>
          <t>The
	  <ul empty="true">
          <li>The TYPE field MUST <bcp14>MUST</bcp14> be represented as the mnemonic value "SOA-SERIAL".</t>
          <t>The "SOA-SERIAL".</li>
          <li>The VERSION field MUST <bcp14>MUST</bcp14> be represented as an unsigned decimal integer.</t> integer.</li>
	  </ul>
        </section>
    </section>

    <section anchor="usage" title="Example usage"> anchor="usage">
      <name>Example Usage</name>
      <t>A name server which 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 SERIAL field for
      versioning of said zone should include a ZONEVERSION option in
      its response.  In the response's ZONEVERSION option 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 SOA-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>

          <name>Example usage Usage and dig output</name>
          <artwork Dig 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 +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
]]>
          </artwork>
          </sourcecode>
        </figure>
    </section>
    <section anchor="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="DNS EDNS0 anchor="IANA">
      <name>IANA Considerations</name>
      <section>
	<name>DNS EDNS(0) Option Code Registration"> Registration</name>
        <t>This document defines a new EDNS0 EDNS(0) option,
          entitled ZONEVERSION "ZONEVERSION" (see <xref target="theoption"/>),
          and assigns a with the
          assigned value of &lt;TBD&gt; 19 from the DNS "DNS EDNS0 Option Codes (OPT) Option space:</t> (OPT)" registry:</t>

        <table>
            <name>DNS EDNS0 Option code</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>&lt;TBD&gt;</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">
        <t>The ZONEVERSION option also defines a 8-bit

      <section>
	<name>ZONEVERSION TYPE field,
          for which Values Registry</name>

<t>
	  IANA is requested to create has created and will maintain a new registry entitled called "ZONEVERSION TYPE Values" (abbreviation ZONEVERSION) used by the ZONEVERSION option,
          inside in the "Domain Name System (DNS) Parameters" group.
          Initial values 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</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 Required review <xref target="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>246-254</th><th>Private Use</th><th>[this document]</th></tr>
            <tr><th>255</th><th>Reserved for future expansion</th><th>[this document]</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>Reserved for Private Use</th><th>RFC 9660</th></tr>
            <tr><th>255</th><th>Reserved</th><th>RFC 9660</th></tr>
          </tbody>
        </table>

        <t>The change control controller for this registry should be by means of an Standard action.</t>

        <section title="Expert is IETF.</t>

        <section>
	  <name>Designated Expert Review Directives">
          <t>Allocation procedures Directives</name>

          <t>The allocation procedure for new code points in the ZONEVERSION "ZONEVERSION TYPE Values" registry require is Specification Required review,
            and so it requires Expert Reviews Required, thus review is required by a designated expert as stated in <xref target="BCP26"/>.</t>

          <t>The target="RFC8126"/>.</t>

          <t>When evaluating requests, the expert should consider the following points:</t> following:</t>
            <ul>
              <li>Duplication of code point allocations should be avoided.</li>
              <li>A Presentation Format section should be provided, 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.
                In particular particular, the reference should state clear instructions for implementers about the syntax and semantic of the data.
                Also
                Also, the Length length of the Data data must have proper limits.</li>
            </ul>

          <t>The expert reviewing the request MUST approve or disapprove the request <bcp14>MUST</bcp14> respond within 10 business days from when she or he received the expert review request.</t> days.</t>
        </section>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations"> anchor="Security">
      <name>Security Considerations</name>
      <t>The EDNS extension data it's is not covered by RRSIG records,
        so there's no way to verify its authenticity nor integrity using DNSSEC DNSSEC,
        and it could theoretically be tampered with by a person-in-the-middle 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.</t>

      <t>If there's a need to certify the ZONEVERSION trustworthiness, trustworthiness of ZONEVERSION,
        it will be necessary to use an encrypted and authenticated DNS transport,
        TSIG
        a transaction signature (TSIG) <xref target="RFC8945"/>, or SIG(0) <xref target="RFC2931"/>.</t>

      <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 signed.
        Since these are separate queries, the cautions caveats about Anycast and others as loose coherency already stated in
        the <xref target="intro" format="title"/>.</t> format="title"/> (<xref target="intro"/>) would apply.</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 option can not cannot be used for checking the correctness of an entire zone in a server.
        For such cases,
        the ZONEMD record <xref target="RFC8976">ZONEMD record</xref> target="RFC8976"/> might be better suited at for such a task.
        ZONEVERSION can help identify and correlate a certain 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.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0014.xml"/>
    <references>
      <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0026.xml"/> href="https://bib.ietf.org/public/rfc/bibxml9/reference.RFC.2119.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>
    <section anchor="implementationcons" title="Implementation Considerations"> anchor="implementationcons">
      <name>Implementation Considerations</name>
      <t>With very few
exceptions, EDNS options which elicit an EDNS EDNS(0) option values in the a response
are independent of the queried name. This is not the case of for ZONEVERSION, so
its implementation may be more or less difficult difficult, depending on how EDNS EDNS(0)
options are handled in the name server.
      </t>
    </section>
    <section anchor="implementation" title="Implementation References">
      <t>There's anchor="implementation">
      <name>Implementation References</name>
      <t>There is a patched NSD server version 4.7.0 (version 4.7.0) with support for ZONEVERSION with an experimental opcode,
      with as well as live test servers installed for compliance tests. Also Also, there is a client command "dig" with added zoneversion support, along with test libraries in Perl, Python Python, and Go. More information in the working document See <xref target="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 the SOA serial field is not relevant
v10 2024-07-05  DW   Responding to Invalid ZONEVERSION Queries
v10 2024-07-05  DW   Use support and define "enclosing zone"
v09 2024-07-01  HS   Accept some comments from Paul Wouters made 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   Accept discussions.
        A special thanks for suggestions to generalize the option using a registry of types from 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
        <contact fullname="Petr Špaček"/> and formatting.
v04 2023-08-03  HS   Changed name of FLAG fields, removed flag length, typos and minor 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 name disambiguation, typos and minor edits.
v02 2022-04-21  HS   Upgraded disambiguation from RRSERIAL to ZONEVERSION, to be versioning-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 changes <contact fullname="Joe Abley"/> and enhancements <contact fullname="Brian Dickson"/>,
        and reviews from DNSOP discussion
v00 2021-05-07  HS   New filename as requested by WG chair, to call for adoption
v01 2020-01-27  HS   No changes, just to avoid expiration
v00 2017-04-27  HS   Initial version

--> <contact fullname="Tim Wicinski"/> and <contact fullname="Peter Thomassen"/>.</t>
    </section>

</back>
</rfc>