rfc9660xml2.original.xml   rfc9660.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-model href="rfc7991bis.rnc"?>
<?rfc toc="yes" ?> <!-- pre-edited by ST 08/07/24 -->
<?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" ?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY RFC3254 PUBLIC "" "https://xml2rfc.ietf.org/public/rfc/bibxml/referen ce.RFC.3254.xml">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:x="http://purl.org/net/xml
2rfc/ext" ipr="trust200902" category="std" docName="draft-ietf-dnsop-zoneversion <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="9660" consensus="true" x
-11" tocInclude="true" symRefs="true" sortRefs="true" version="3" submissionType ml:lang="en" ipr="trust200902" category="std" docName="draft-ietf-dnsop-zonevers
="IETF"> ion-11" tocInclude="true" symRefs="true" sortRefs="true" version="3" submissionT
ype="IETF" updates="" obsoletes="">
<front> <front>
<title abbrev="DNS ZONEVERSION Option">The DNS Zone Version (ZONEVERSION) Op tion</title> <title abbrev="DNS ZONEVERSION Option">The DNS Zone Version (ZONEVERSION) Op tion</title>
<seriesInfo name="RFC" value="9660"/>
<author fullname="Hugo Salgado" initials="H." surname="Salgado"> <author fullname="Hugo Salgado" initials="H." surname="Salgado">
<organization>NIC Chile</organization> <organization>NIC Chile</organization>
<address> <address>
<postal> <postal>
<street>Miraflores 222, piso 14</street> <street>Miraflores 222, piso 14</street>
<city>Santiago</city> <city>Santiago</city>
<code>CP 8320198</code> <code>CP 8320198</code>
<country>CL</country> <country>Chile</country>
</postal> </postal>
<phone>+56 2 29407700</phone> <phone>+56 2 29407700</phone>
<email>hsalgado@nic.cl</email> <email>hsalgado@nic.cl</email>
</address> </address>
</author> </author>
<author fullname="Mauricio Vergara Ereche" initials="M." surname="Vergara"> <author fullname="Mauricio Vergara Ereche" initials="M." surname="Vergara">
<organization>DigitalOcean</organization> <organization>DigitalOcean</organization>
<address> <address>
<postal> <postal>
<street>101 6th Ave</street> <street>101 6th Ave</street>
<city>New York</city> <city>New York</city>
<code>NY 10013</code> <region>NY</region>
<country>US</country> <code>10013</code>
<country>United States of America</country>
</postal> </postal>
<email>mvergara@digitalocean.com</email> <email>mvergara@digitalocean.com</email>
</address> </address>
</author> </author>
<author fullname="Duane Wessels" initials="D." surname="Wessels"> <author fullname="Duane Wessels" initials="D." surname="Wessels">
<organization>Verisign</organization> <organization>Verisign</organization>
<address> <address>
<postal> <postal>
<street>12061 Bluemont Way</street> <street>12061 Bluemont Way</street>
<city>Reston</city> <city>Reston</city>
<region>VA</region> <region>VA</region>
<code>20190</code> <code>20190</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 703 948-3200</phone> <phone>+1 703 948-3200</phone>
<email>dwessels@verisign.com</email> <email>dwessels@verisign.com</email>
<uri>https://verisign.com</uri> <uri>https://verisign.com</uri>
</address> </address>
</author> </author>
<date year="2024"/> <date year="2024" month="October"/>
<area>General</area> <area>OPS</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>dnsop</workgroup>
<keyword>zoneversion</keyword> <keyword>zoneversion</keyword>
<abstract> <abstract>
<t>The DNS ZONEVERSION option is a way for DNS clients to request, <t>The DNS ZONEVERSION option is a way for DNS clients to request,
and for authoritative DNS servers to provide, information and for authoritative DNS servers to provide, information
regarding the version of the zone from which a response is regarding the version of the zone from which a response is
generated. The Serial field from the Start Of Authority (SOA) generated. The SERIAL field from the Start of Authority (SOA)
resource record is a good example of a zone's version, and the resource record (RR) is a good example of a zone's version, and it is th
e
only one defined by this specification. Additional version only one defined by this specification. Additional version
types may be defined by future specifications.</t> types may be defined by future specifications.</t>
<t>Including zone version data in a response simplifies and improves <t>Including zone version data in a response simplifies and improves
the quality of debugging and diagnostics since the version the quality of debugging and diagnostics since the version
and the DNS answer are provided atomically. This can be especially and the DNS answer are provided atomically. This can be especially
useful for zones and DNS providers that leverage IP anycast or useful for zones and DNS providers that leverage IP anycast or
multiple backend systems. It functions similarly to the multiple backend systems. It functions similarly to the
DNS Name Server Identifier (NSID) option described in RFC5001.</t> DNS Name Server Identifier (NSID) option described in RFC 5001.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro">
<name>Introduction</name>
<t>The ZONEVERSION option <t>The ZONEVERSION option
allows DNS queriers to request, and authoritative DNS servers to provide , allows DNS queriers to request, and authoritative DNS servers to provide ,
a a
token representing the version of the zone from which a DNS response was generated. It is similar 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 to the NSID option <xref target="RFC5001"/>, which can be used to convey the identification
of a name server that generates a response.</t> of a name server that generates a response.</t>
<t>The Domain Name System allows data to be loosely coherent <t>The Domain Name System allows data to be loosely coherent
<xref target="RFC3254"/>, because synchronization can never <xref target="RFC3254"/>, because synchronization can never
be instantaneous, and some uses of DNS do not require strong be instantaneous, and some uses of DNS do not require strong
coherency anyway. This means that a record obtained by coherency anyway. This means that a record obtained by
one response could be out-of-sync with other authoritative one response could be out of sync with other authoritative
sources of the same data at the same point in time. This can 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 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. 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 Furthermore, in today's Internet, it is common for high volume and
important DNS zones to utilize IP anycast <xref target="RFC4786" important DNS zones to utilize IP anycast (<xref target="RFC4786" sectio
sectionFormat="of" section="4.9"/> and/or load-balanced backend nFormat="of" section="4.9"/>) and/or load-balanced backend
servers. In general, there is no way to ensure that two separate servers. In general, there is no way to ensure that two separate
queries are delivered to the same server. The ZONEVERSION option both queries are delivered to the same server. The ZONEVERSION option both
simplifies and improves the DNS monitoring and debugging by simplifies and improves DNS monitoring and debugging by
directly associating the data and the version together in a directly associating the data and the version together in a
single response.</t> single response.</t>
<t>The SOA Serial field (<xref target="RFC1034" sectionFormat="of" <t>The SOA SERIAL field (<xref target="RFC1034" sectionFormat="of" section
section="4.3.5"/>) is one example of zone versioning. Its purpose ="4.3.5"/>) is one example of zone versioning. Its purpose
is to facilitate the distribution of zone data between primary is to facilitate the distribution of zone data between primary
and secondary name servers. It is also often useful in DNS and secondary name servers. It is also often useful in DNS
monitoring and debugging. This document specifies the SOA Serial monitoring and debugging. This document specifies the SOA SERIAL
as one type of ZONEVERSION data.</t> as one type of ZONEVERSION data.</t>
<t>Some DNS zones may use other distribution and synchronization <t>Some DNS zones may use other distribution and synchronization
mechanisms not based on the SOA Serial number, such as relational mechanisms that are not based on the SOA SERIAL number, such as relation
databases or other proprietary methods. In those cases the SOA al
Serial field may not be relevant with respect to the versioning 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 of its content. To accommodate these use cases, new ZONEVERSION
types could be defined in future specifications. Alternatively, types could be defined in future specifications. Alternatively,
zone operators may use one of the private use ZONEVERSION code zone operators may use one of the Private Use ZONEVERSION code
points allocated by this specification.</t> points allocated by this specification.</t>
<t>The ZONEVERSION option is OPTIONAL to implement by DNS clients and name servers. <t>The ZONEVERSION option is <bcp14>OPTIONAL</bcp14> to implement by DNS c lients and name servers.
It is designed for use only when a name server provides It is designed for use only when a name server provides
authoritative response data. It is intended only for hop-to-hop authoritative response data. It is intended only for hop-to-hop
communication and is not transitive.</t> communication and is not transitive.</t>
<section title="Requirements Language"> <section>
<t> <name>Requirements Language</name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
<xref target="BCP14"/> (<xref target="RFC2119"/>, <xref target="RFC8174"/>) ",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section title="Terminology"> <section>
<t>In this document "original QNAME" is used to mean what the <name>Terminology</name>
<t>In this document, "original QNAME" is used to mean what the
DNS terminology document <xref target="RFC9499"/> calls "QNAME DNS terminology document <xref target="RFC9499"/> calls "QNAME
(original)":</t> (original)":</t>
<blockquote><t>The name actually sent in the Question section <blockquote>The name actually sent in the Question section
in the original query, which is always echoed in the (final) 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></blockquo te> reply in the Question section when the QR bit is set to 1.</blockquote>
<t>In this document, an "enclosing zone" of a domain name means <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, 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 or any parent of that zone. For example, if B.C.EXAMPLE and
EXAMPLE are zones, but C.EXAMPLE is not, the domain name EXAMPLE are zones but C.EXAMPLE is not, the domain name
A.B.C.EXAMPLE has B.C.EXAMPLE, EXAMPLE, and the root as A.B.C.EXAMPLE has B.C.EXAMPLE, EXAMPLE, and the root as
enclosing zones.</t> enclosing zones.</t>
</section> </section>
</section> </section>
<section anchor="theoption" title="The ZONEVERSION Option"> <section anchor="theoption">
<name>The ZONEVERSION Option</name>
<t>This document specifies a new EDNS(0) (<xref target="RFC6891" <t>This document specifies a new EDNS(0) <xref target="RFC6891"/> option,
section="6.1.2"/>) option, ZONEVERSION, which can be used by DNS ZONEVERSION, which can be used by DNS
clients and servers to provide information regarding the version clients and servers to provide information regarding the version
of the zone from which a response is generated.</t> 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>The ZONEVERSION option is encoded as follows:</t>
<t>OPTION-CODE for the ZONEVERSION option is &lt;TBD&gt;.</t> <t>OPTION-CODE for the ZONEVERSION option is 19.</t>
<t>OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for q <t>OPTION-LENGTH for the ZONEVERSION option <bcp14>MUST</bcp14> have a v
ueries, alue of 0 for queries
and MUST have the value of the length (in octets) of the OPTION-DATA f and <bcp14>MUST</bcp14> have the value of the length (in octets) of th
or responses.</t> e OPTION-DATA for responses.</t>
<t>OPTION-DATA for the ZONEVERSION option is omitted in queries. For re sponses it is composed of three fields:</t> <t>OPTION-DATA for the ZONEVERSION option is omitted in queries. For re sponses, it is composed of three fields:</t>
<ul> <ul>
<li>An unsigned 1-octet Label Count (LABELCOUNT) <li>an unsigned 1-octet Label Count (LABELCOUNT)
indicating the number of labels for the name of the zone that VERS indicating the number of labels for the name of the zone that VERS
ION value refers to.</li> ION value refers to</li>
<li>An unsigned 1-octet type number (TYPE) that distinguishes the fo rmat and meaning of VERSION.</li> <li>an unsigned 1-octet type number (TYPE) distinguishing the format and meaning of VERSION</li>
<li>An opaque octet string conveying the zone version data (VERSION) .</li> <li>an opaque octet string conveying the zone version data (VERSION) </li>
</ul> </ul>
<!-- Some RFCs include the OPTION-CODE and OPTION-LENGTH fields in the protocol
block diagram -->
<figure> <figure>
<name>Diagram with the OPTION-DATA format for ZONEVERSION option</name> <name>Diagram with the OPTION-DATA Format for the ZONEVERSION Option</na me>
<artset> <artset>
<artwork type="ascii-art" name="zoneversion.txt"> <artwork type="ascii-art" name="zoneversion.txt">
<![CDATA[ <![CDATA[
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LABELCOUNT | TYPE | 0: | LABELCOUNT | TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | VERSION | 2: | VERSION |
/ / / /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]> ]]></artwork>
</artwork>
</artset> </artset>
</figure> </figure>
<t> <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. 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 that this ZONE VERSION refers is "example.com.".</t> 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 Z ONEVERSION refers to is "example.com.".</t>
<t>The LABELCOUNT number helps to differentiate in the case of a downward <t>In the case of a downward referral response, the LABELCOUNT number help
referral response, where the parent server is authoritative for some portion of s to differentiate between the parent and child zones, where the parent is autho
the QNAME that differs from a child server that is below the zone cut. ritative for some portion of the QNAME above a zone cut. Also, if the ANSWER se
Also, if the ANSWER section has more than one RR set with different zone ction has more than one RR set with different zones (like a CNAME and a target n
s (like a CNAME and a target name in another zone) the number of labels in the Q ame in another zone), the number of labels in the QNAME disambiguates such a sit
NAME disambiguates such a situation.</t> uation.</t>
<t>The value of the LABELCOUNT field MUST NOT count the null (root) label <t>The value of the LABELCOUNT field <bcp14>MUST NOT</bcp14> count the nul
that terminates the original QNAME. l (root) label that terminates the original QNAME. The value of the LABELCOUNT f
The value of the LABELCOUNT field MUST be less than or equal to the numb ield <bcp14>MUST</bcp14> be less than or equal to the number of labels in the or
er of labels in the original QNAME. iginal QNAME.
The Root zone (".") has a LABELCOUNT field value of 0.</t> The Root zone (".") has a LABELCOUNT field value of 0.</t>
</section> </section>
<section anchor="optionpresentation" title="Presentation Format"> <section anchor="optionpresentation">
<name>Presentation Format</name>
<t>The presentation format of the ZONEVERSION option is as follows:</t > <t>The presentation format of the ZONEVERSION option is as follows:</t >
<t>The OPTION-CODE field MUST be represented as the mnemonic value ZON EVERSION.</t> <t>The OPTION-CODE field <bcp14>MUST</bcp14> be represented as the mne monic value ZONEVERSION.</t>
<t>The OPTION-LENGTH field MAY be omitted, <t>The OPTION-LENGTH field <bcp14>MAY</bcp14> be omitted,
but if present it MUST be represented as an unsigned decimal integer but if present, it <bcp14>MUST</bcp14> be represented as an unsigned
.</t> decimal integer.</t>
<t>The LABELCOUNT value of OPTION-DATA field MAY be omitted, <t>The LABELCOUNT value of the OPTION-DATA field <bcp14>MAY</bcp14> be
but if present it MUST be represented as an unsigned decimal integer omitted,
. but if present, it <bcp14>MUST</bcp14> be represented as an unsigned
The corresponding zone name SHOULD be displayed (i.e., LABELCOUNT la decimal integer.
bels of the original QNAME) The corresponding zone name <bcp14>SHOULD</bcp14> be displayed (i.e.
, LABELCOUNT labels of the original QNAME)
for easier human consumption.</t> for easier human consumption.</t>
<t>The TYPE and VERSION fields of the option SHOULD be represented acc ording to each specific TYPE.</t> <t>The TYPE and VERSION fields of the option <bcp14>SHOULD</bcp14> be represented according to each specific TYPE.</t>
</section> </section>
</section> </section>
<section title="ZONEVERSION Processing"> <section>
<section title="Initiators"> <name>ZONEVERSION Processing</name>
<t>A DNS client MAY signal its support and desire for zone version infor <section>
mation by <name>Initiators</name>
<t>A DNS client <bcp14>MAY</bcp14> signal its support and desire for zon
e version information by
including an empty ZONEVERSION option in the EDNS(0) OPT pseudo-RR of a query to an authoritative 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 zer o.</t> name server. An empty ZONEVERSION option has OPTION-LENGTH set to zer o.</t>
<t>A DNS client SHOULD NOT send the ZONEVERSION option to non-authoritat <t>A DNS client <bcp14>SHOULD NOT</bcp14> send the ZONEVERSION option to
ive name servers.</t> non-authoritative name servers.</t>
<t>A DNS client MUST NOT include more than one ZONEVERSION option in the <t>A DNS client <bcp14>MUST NOT</bcp14> include more than one ZONEVERSIO
OPT RR of a DNS query.</t> N option in the OPT pseudo-RR of a DNS query.</t>
</section> </section>
<section title="Responders"> <section>
<name>Responders</name>
<t>A name server that (a) understands the ZONEVERSION option, (b) rece ives a <t>A name server that (a) understands the ZONEVERSION option, (b) rece ives a
query with the ZONEVERSION option, (c) is query with the ZONEVERSION option, (c) is
authoritative for one or more enclosing zones of the original QNAME, a nd (d) chooses to honor a authoritative for one or more enclosing zones of the original QNAME, a nd (d) chooses to honor a
particular ZONEVERSION request responds by including a TYPE and particular ZONEVERSION request responds by including a TYPE and
corresponding VERSION value in a ZONEVERSION option in an EDNS(0) corresponding VERSION value in a ZONEVERSION option in an EDNS(0)
OPT pseudo-RR in the response message.</t> OPT pseudo-RR in the response message.</t>
<t>Otherwise, <t>Otherwise,
a server MUST NOT include a ZONEVERSION option in the response.</t> a server <bcp14>MUST NOT</bcp14> include a ZONEVERSION option in the r esponse.</t>
<t>A name server MAY include more than one ZONEVERSION option in <t>A name server <bcp14>MAY</bcp14> include more than one ZONEVERSION op
the response if it supports multiple TYPEs. A name server MAY tion in
the response if it supports multiple TYPEs. A name server <bcp14>MAY<
/bcp14>
also include more than one ZONEVERSION option in the response also include more than one ZONEVERSION option in the response
if it is authoritative for more than one enclosing zone of the origin al if it is authoritative for more than one enclosing zone of the origin al
QNAME. A name server MUST NOT include more than one ZONEVERSION QNAME. A name server <bcp14>MUST NOT</bcp14> include more than one ZO
option for a given TYPE and LABELCOUNT.</t> NEVERSION
option for a given TYPE and LABELCOUNT.</t>
<t>Note: the ZONEVERSION option should be included for any response <t>Note: the ZONEVERSION option should be included for any response
satisfying the criteria above, including, but not limited to, the foll owing:</t> satisfying the criteria above including, but not limited to, the follo wing:</t>
<ul> <ul>
<li>Downward referral <li>Downward referral
(see "Referrals" in <xref target="RFC9499" section="4"/>), (see "Referrals" in <xref target="RFC9499" section="4"/>),
even though the response's Authoritative Answer bit is not set. 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.</li> In this case, the ZONEVERSION data <bcp14>MUST</bcp14> correspond to the version of the referring zone.</li>
<li>Name error (NXDOMAIN), even though the response <li>Name error (NXDOMAIN), even though the response
does not include any Answer section RRs.</li> does not include any Answer section RRs.</li>
<li>NODATA (<xref target="RFC9499" section="3"/>), <li>NODATA (<xref target="RFC9499" section="3"/>),
even though the response does not include any Answer even though the response does not include any Answer
section RRs.</li> section RRs.</li>
<li>Server failure (SERVFAIL) when the server is authoritative for the original QNAME.</li> <li>Server failure (SERVFAIL) when the server is authoritative for the original QNAME.</li>
</ul> </ul>
<section title="Responding to Invalid ZONEVERSION Queries"> <section>
<name>Responding to Invalid ZONEVERSION Queries</name>
<t>A name server that understands the ZONEVERSION option MUST <t>A name server that understands the ZONEVERSION option <bcp14>MUST</ bcp14>
return a FORMERR response when:</t> return a FORMERR response when:</t>
<ul> <ul>
<li>The ZONEVERSION OPTION-LENGTH is not zero.</li> <li>The ZONEVERSION OPTION-LENGTH is not zero.</li>
<li>More than one ZONEVERSION option is present.</li> <li>More than one ZONEVERSION option is present.</li>
</ul> </ul>
</section> </section>
<section title="ZONEVERSION Is Not Transitive"> <section>
<name>ZONEVERSION Is Not Transitive</name>
<t>The ZONEVERSION option is not transitive. A name server <t>The ZONEVERSION option is not transitive. A name server
(recursive or otherwise) MUST NOT blindly copy the ZONEVERSION (recursive or otherwise) <bcp14>MUST NOT</bcp14> blindly copy the ZO
option from a query it receives into a subsquent query that NEVERSION
it sends onward to another server. A name server MUST NOT option from a query it receives into a subsequent query that
send a ZONEVERSION option back to a client which did not it sends onward to another server. A name server <bcp14>MUST NOT</b
cp14>
send a ZONEVERSION option back to a client that did not
request it.</t> request it.</t>
</section> </section>
</section> </section>
</section> </section>
<section title="The SOA-SERIAL ZONEVERSION Type"> <section>
<name>The SOA-SERIAL ZONEVERSION 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>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 <t>As mentioned previously, some DNS zones may use alternative
distribution and synchronization mechanisms not based on the SOA distribution and synchronization mechanisms that are not based on the SO
Serial number and the Serial field may not be relevant with A
respect to the versioning of zone content. In those cases a SERIAL number, and the SERIAL field may not be relevant with
name server SHOULD NOT include a ZONEVERSION option with type respect to the versioning of zone content. In those cases, a
name server <bcp14>SHOULD NOT</bcp14> include a ZONEVERSION option with
type
SOA-SERIAL in a reply.</t> SOA-SERIAL in a reply.</t>
<t>The value for this type is: 0</t> <t>The value for this type is "0".</t>
<t>The mnemonic of this type is: SOA-SERIAL.</t> <t>The mnemonic for this type is "SOA-SERIAL".</t>
<t>The EDNS(0) OPTION-LENGTH for this type MUST be set to 6 in responses.< /t> <t>The EDNS(0) OPTION-LENGTH for this type <bcp14>MUST</bcp14> be set to " 6" in responses.</t>
<t>The VERSION value for the SOA-SERIAL type MUST be a copy of the unsigne d 32-bit <t>The VERSION value for the SOA-SERIAL type <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> SERIAL field of the SOA RR, as defined in <xref target="RFC1035" section ="3.3.13"/>.</t>
<section anchor="typepresentation" title="Type SOA-SERIAL Presentation F <section anchor="typepresentation">
ormat"> <name>Type SOA-SERIAL Presentation Format</name>
<t>The presentation format of this type content is as follows:</t> <t>The presentation format of this type content is as follows:</t>
<t>The TYPE field MUST be represented as the mnemonic value "SOA-SERIA <ul empty="true">
L".</t> <li>The TYPE field <bcp14>MUST</bcp14> be represented as the mnemonic
<t>The VERSION field MUST be represented as an unsigned decimal intege value "SOA-SERIAL".</li>
r.</t> <li>The VERSION field <bcp14>MUST</bcp14> be represented as an unsigne
d decimal integer.</li>
</ul>
</section> </section>
</section> </section>
<section anchor="usage" title="Example usage"> <section anchor="usage">
<t>A name server which (a) implements this specification, (b) <name>Example Usage</name>
<t>A name server that (a) implements this specification, (b)
receives a query with the ZONEVERSION option, (c) is authoritative 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 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 versioning of said zone should include a ZONEVERSION option in
its response. In the response's ZONEVERSION option the EDNS(0) OPTION-LEN GTH its response. In the response's ZONEVERSION option, the EDNS(0) OPTION-LE NGTH
would be set to 6 and the OPTION-DATA would consist of the 1-octet LABELCO UNT, would be set to 6 and the OPTION-DATA would consist of the 1-octet LABELCO UNT,
the 1-octet TYPE with value 0, and 4-octet SOA SERIAL value.</t> the 1-octet TYPE with value 0, and the 4-octet SOA-SERIAL value.</t>
<t>The example below demonstrates expected output of a diagnostic tool tha t implements the ZONEVERSION option, displaying a response from a compliant auth oritative DNS server:</t> <t>The example below demonstrates expected output of a diagnostic tool tha t implements the ZONEVERSION option, displaying a response from a compliant auth oritative DNS server:</t>
<figure> <figure>
<name>Example usage and dig output</name>
<artwork type="dns-rr"> <name>Example Usage and Dig Output</name>
<sourcecode type="dns-rr">
<![CDATA[ <![CDATA[
$ dig @ns.example.com www.example.com aaaa +zoneversion +norecurse $ dig @ns.example.com www.example.com aaaa +zoneversion \
+norecurse +nocmd
; <<>> DiG 9.17.14-patched <<>> @ns.example.com www.example.com aaaa +zonevers
ion
; (1 server found)
;; global options: +cmd
;; Got answer: ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION: ;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232 ; EDNS: version: 0, flags:; udp: 1232
; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 (example.com.)") ; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 \
; (example.com.)")
;; QUESTION SECTION: ;; QUESTION SECTION:
;www.example.com. IN AAAA ;www.example.com. IN AAAA
;; ANSWER SECTION: ;; ANSWER SECTION:
www.example.com. 43200 IN AAAA 2001:db8::80 www.example.com. 43200 IN AAAA 2001:db8::80
;; AUTHORITY SECTION: ;; AUTHORITY SECTION:
example.com. 43200 IN NS ns.example.com. example.com. 43200 IN NS ns.example.com.
;; ADDITIONAL SECTION: ;; ADDITIONAL SECTION:
ns.example.com. 43200 IN AAAA 2001:db8::53 ns.example.com. 43200 IN AAAA 2001:db8::53
;; Query time: 15 msec ;; Query time: 15 msec
;; SERVER: 2001:db8::53#53(2001:db8::53) (UDP) ;; SERVER: 2001:db8::53#53(2001:db8::53) (UDP)
;; WHEN: dom jul 30 19:51:04 -04 2023 ;; WHEN: dom jul 30 19:51:04 -04 2023
;; MSG SIZE rcvd: 129 ;; MSG SIZE rcvd: 129
]]> ]]>
</artwork> </sourcecode>
</figure> </figure>
</section> </section>
<section anchor="IANA">
<section anchor="Acknowledgements" title="Acknowledgements"> <name>IANA Considerations</name>
<t>The authors thanks all the comments and support made in the DNSOP maili <section>
ng list, <name>DNS EDNS(0) Option Code Registration</name>
chats and discussions. <t>This document defines a new EDNS(0) option,
Special thanks for the suggestions to generalize the option using a regi entitled "ZONEVERSION" (see <xref target="theoption"/>), with the
stry of types from assigned value of 19 from the "DNS EDNS0 Option Codes (OPT)" registry:
<contact fullname="Petr Špaček" asciiFullname="Petr Spacek"/> and Floria </t>
n Obser,
suggestions for implementation from
<contact fullname="Stéphane Bortzmeyer" asciiFullname="Stephane Bortzmey
er"/>,
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 Option Code Registration">
<t>This document defines a new EDNS0 option,
entitled ZONEVERSION (see <xref target="theoption"/>),
and assigns a value of &lt;TBD&gt; from the DNS EDNS0 Option Codes (OP
T) Option space:</t>
<table> <table>
<name>DNS EDNS0 Option code</name> <name>DNS EDNS0 Option Codes (OPT) Registry</name>
<thead> <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> </thead>
<tbody> <tbody>
<tr><th>&lt;TBD&gt;</th><th>ZONEVERSION</th><th>Standard</th><th>[th <tr><th>19</th>
is document]</th></tr> <th>ZONEVERSION</th><th>Standard</th><th>RFC 9660</th></tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section title="ZONEVERSION Registry"> <section>
<t>The ZONEVERSION option also defines a 8-bit TYPE field, <name>ZONEVERSION TYPE Values Registry</name>
for which IANA is requested to create and maintain a new registry enti
tled <t>
"ZONEVERSION TYPE Values" (abbreviation ZONEVERSION) used by the ZONEV IANA has created and will maintain a new registry called "ZONEVERSION T
ERSION option, YPE Values" in the "Domain Name System (DNS) Parameters" registry group as follo
inside the "Domain Name System (DNS) Parameters" group. ws:</t>
Initial values for the ZONEVERSION TYPE values registry are given belo <table>
w; <name>Registration Procedures for the ZONEVERSION TYPE Values Registry
future assignments in the 1-245 values are to be made through Specific </name>
ation Required review <xref target="BCP26"/>. <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 be
low;
future assignments in the 1-245 values range are to be made through
Specification Required <xref target="RFC8126"/>.
Assignments consist of a TYPE value as an unsigned 8-bit integer recor ded in decimal, Assignments consist of a TYPE value as an unsigned 8-bit integer recor ded in decimal,
a Mnemonic name as an uppercase ASCII string with maximum length of 15 characters, a Mnemonic name as an uppercase ASCII string with a maximum length of 15 characters,
and the required document reference.</t> and the required document reference.</t>
<table> <table>
<name>ZONEVERSION Registry</name> <name>ZONEVERSION TYPE Values Registry</name>
<thead> <thead>
<tr><th>ZONEVERSION TYPE</th><th>Mnemonic</th><th>Reference</th></tr > <tr><th>ZONEVERSION TYPE</th><th>Mnemonic</th><th>Reference</th></tr >
</thead> </thead>
<tbody> <tbody>
<tr><th>0</th><th>SOA-SERIAL</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></th></tr> <tr><th>1-245</th><th>Unassigned</th><th/></tr>
<tr><th>246-254</th><th>Private Use</th><th>[this document]</th></tr <tr><th>246-254</th><th>Reserved for Private Use</th><th>RFC 9660</t
> h></tr>
<tr><th>255</th><th>Reserved for future expansion</th><th>[this docu <tr><th>255</th><th>Reserved</th><th>RFC 9660</th></tr>
ment]</th></tr>
</tbody> </tbody>
</table> </table>
<t>The change control for this registry should be by means of an Standar d action.</t> <t>The change controller for this registry is IETF.</t>
<section title="Expert Review Directives"> <section>
<t>Allocation procedures for new code points in the ZONEVERSION TYPE r <name>Designated Expert Review Directives</name>
egistry require Specification Required review,
and so it requires Expert Reviews as stated in <xref target="BCP26"/
>.</t>
<t>The expert should consider the following points:</t> <t>The allocation procedure for new code points in the "ZONEVERSION TY
PE Values" registry is Specification Required, thus review is required by a desi
gnated expert as stated in <xref target="RFC8126"/>.</t>
<t>When evaluating requests, the expert should consider the following:
</t>
<ul> <ul>
<li>Duplication of code point allocations should be avoided.</li> <li>Duplication of code point allocations should be avoided.</li>
<li>A Presentation Format section should be provided, <li>A Presentation Format section should be provided
with a clear code point mnemonic.</li> with a clear code point mnemonic.</li>
<li>The referenced document and stated use of the new code point s hould be appropriate for the intended use of a ZONEVERSION TYPE assignment. <li>The referenced document and stated use of the new code point s hould be appropriate for the intended use of a ZONEVERSION TYPE assignment.
In particular the reference should state clear instructions for In particular, the reference should state clear instructions for
implementers about the syntax and semantic of the data. implementers about the syntax and semantic of the data.
Also the Length of the Data must have proper limits.</li> Also, the length of the data must have proper limits.</li>
</ul> </ul>
<t>The expert reviewing the request MUST approve or disapprove the req uest within 10 business days from when she or he received the expert review requ est.</t> <t>The expert reviewing the request <bcp14>MUST</bcp14> respond within 10 business days.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security">
<t>The EDNS extension data it's not covered by RRSIG records, <name>Security Considerations</name>
so there's no way to verify its authenticity nor integrity using DNSSEC <t>The EDNS extension data is not covered by RRSIG records,
and could theoretically be tampered by a person-in-the-middle if the tra so there's no way to verify its authenticity nor integrity using DNSSEC,
nsport is made by insecure means. and it could theoretically be tampered with by a person in the middle if
Caution should be taken to use the EDNS ZONEVERSION data for any means b the transport is made by insecure means.
esides troubleshooting and debugging.</t> Caution should be taken to use the EDNS ZONEVERSION data for any means bes
ides troubleshooting and debugging.</t>
<t>If there's a need to certify the ZONEVERSION trustworthiness, <t>If there's a need to certify the trustworthiness of ZONEVERSION,
it will be necessary to use an encrypted and authenticated DNS transport , it will be necessary to use an encrypted and authenticated DNS transport ,
TSIG <xref target="RFC8945"/>, or SIG(0) <xref target="RFC2931"/>.</t> a transaction signature (TSIG) <xref target="RFC8945"/>, or SIG(0) <xref target="RFC2931"/>.</t>
<t>If there's a need to authenticate data origin for the ZONEVERSION value <t>If there's a need to authenticate the data origin for the ZONEVERSION v
, alue,
an answer with the SOA-SERIAL type as defined above could be compared to an answer with the SOA-SERIAL type as defined above could be compared to
a separate regular SOA query with DO flag, a separate regular SOA query with a DO flag,
whose answer shall be DNSSEC signed, whose answer shall be DNSSEC signed.
with the cautions about Anycast and others as already stated in <xref ta Since these are separate queries, the caveats about loose coherency alre
rget="intro" format="title"/>.</t> ady stated in
the <xref target="intro" format="title"/> (<xref target="intro"/>) would
apply.</t>
<t>With the SOA-SERIAL type defined above, there's no risk on disclosure o f private information, <t>With the SOA-SERIAL type defined above, there's no risk on disclosure o f private information,
as the SERIAL of the SOA record is already publicly available.</t> as the SERIAL of the SOA record is already publicly available.</t>
<t>Please note that the ZONEVERSION option can not be used for checking th e correctness of an entire zone in a server. <t>Please note that the ZONEVERSION option cannot be used for checking the correctness of an entire zone in a server.
For such cases, For such cases,
the <xref target="RFC8976">ZONEMD record</xref> might be better suited a the ZONEMD record <xref target="RFC8976"/> might be better suited for su
t such a task. ch a task.
ZONEVERSION can help identify and correlate a certain specific answer wi ZONEVERSION can help identify and correlate a specific answer with a ver
th a version of a zone, sion of a zone,
but it has no special integrity or verification function besides a norma l field value inside a zone, but it has no special integrity or verification function besides a norma l field value inside a zone,
as stated above.</t> as stated above.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.00 <name>Normative References</name>
14.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.RFC.21
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.00 19.xml"/>
26.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.103 4.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.103 4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.103 5.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.103 5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.689 1.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.689 1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.RFC.81
26.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.RFC.8
174.xml"/>
</references> </references>
<references title="Informative References"> <references>
&RFC3254; <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.325
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.478 6.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.478 6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.500 1.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.500 1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.293 1.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.293 1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.894 5.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.894 5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.897 6.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.897 6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.949 9.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.949 9.xml"/>
<reference anchor="ImplRef" target="https://github.com/huguei/rrserial"> <reference anchor="ImplRef" target="https://github.com/huguei/rrserial">
<front> <front>
<title>Zoneversion Implementations</title> <title>Zoneversion Implementations</title>
<author fullname="Hugo Salgado" initials="H." surname="Salgado"> <author>
<organization/> <organization/>
</author> </author>
<date year="2023"/> <date month="August" year="2023"/>
</front> </front>
<refcontent>commit f5f68a0</refcontent>
</reference> </reference>
</references> </references>
<section anchor="implementationcons" title="Implementation Considerations"> <section anchor="implementationcons">
<name>Implementation Considerations</name>
<t>With very few <t>With very few
exceptions, EDNS options which elicit an EDNS option in the response exceptions, EDNS(0) option values in a response
are independent of the queried name. This is not the case of ZONEVERSION, so 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 its implementation may be more or less difficult, depending on how EDNS(0)
options are handled in the name server. options are handled in the name server.
</t> </t>
</section> </section>
<section anchor="implementation" title="Implementation References"> <section anchor="implementation">
<t>There's a patched NSD server version 4.7.0 with support for ZONEVERSION <name>Implementation References</name>
with an experimental opcode, <t>There is a patched NSD server (version 4.7.0) with support for ZONEVERS
with live test servers installed for compliance tests. Also there is a cli ION as well as live test servers installed for compliance tests. Also, there is
ent command "dig" with added zoneversion support, along with test libraries in P a client command "dig" with added zoneversion support, along with test libraries
erl, Python and Go. More information in the working document <xref target="ImplR in Perl, Python, and Go. See <xref target="ImplRef"/> for more information.</t>
ef"/>.</t> </section>
<section anchor="Acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The authors are thankful for all the support and comments made in the D
NSOP Working Group mailing list,
chats, and discussions.
A special thanks for suggestions to generalize the option using a regist
ry of types from
<contact fullname="Petr Špaček"/> and <contact fullname="Florian Obser"/
>,
suggestions for implementation from
<contact fullname="Stéphane Bortzmeyer"/>,
clarifications on security from <contact fullname="George Michaelson"/>,
zone name disambiguation from <contact fullname="Joe Abley"/> and <conta
ct fullname="Brian Dickson"/>,
and reviews from <contact fullname="Tim Wicinski"/> and <contact fullnam
e="Peter Thomassen"/>.</t>
</section> </section>
<!-- Change Log
v11 2024-07-19 DW SOA-SERIAL SHOULD NOT be included when the SOA serial field
is not relevant
v10 2024-07-05 DW Responding to Invalid ZONEVERSION Queries
v10 2024-07-05 DW Use and define "enclosing zone"
v09 2024-07-01 HS Accept some comments from Paul Wouters and Éric Vyncke Disc
uss 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 Ca
ll review.
v06 2024-05-14 DW Accept suggestions 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 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 for zone name disambiguation, typos an
d minor edits.
v02 2022-04-21 HS Upgraded from RRSERIAL to ZONEVERSION, to be versioning-agn
ostic.
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 and enhancements 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
</back> </back>
</rfc> </rfc>
 End of changes. 108 change blocks. 
283 lines changed or deleted 302 lines changed or added

This html diff was produced by rfcdiff 1.48.