rfc9660.original   rfc9660.txt 
Internet Engineering Task Force H. Salgado Internet Engineering Task Force (IETF) H. Salgado
Internet-Draft NIC Chile Request for Comments: 9660 NIC Chile
Intended status: Standards Track M. Vergara Category: Standards Track M. Vergara
Expires: 24 January 2025 DigitalOcean ISSN: 2070-1721 DigitalOcean
D. Wessels D. Wessels
Verisign Verisign
23 July 2024 October 2024
The DNS Zone Version (ZONEVERSION) Option The DNS Zone Version (ZONEVERSION) Option
draft-ietf-dnsop-zoneversion-11
Abstract Abstract
The DNS ZONEVERSION option is a way for DNS clients to request, and The DNS ZONEVERSION option is a way for DNS clients to request, and
for authoritative DNS servers to provide, information regarding the for authoritative DNS servers to provide, information regarding the
version of the zone from which a response is generated. The Serial version of the zone from which a response is generated. The SERIAL
field from the Start Of Authority (SOA) resource record is a good field from the Start of Authority (SOA) resource record (RR) is a
example of a zone's version, and the only one defined by this good example of a zone's version, and it is the only one defined by
specification. Additional version types may be defined by future this specification. Additional version types may be defined by
specifications. future specifications.
Including zone version data in a response simplifies and improves the Including zone version data in a response simplifies and improves the
quality of debugging and diagnostics since the version and the DNS quality of debugging and diagnostics since the version and the DNS
answer are provided atomically. This can be especially useful for answer are provided atomically. This can be especially useful for
zones and DNS providers that leverage IP anycast or multiple backend zones and DNS providers that leverage IP anycast or multiple backend
systems. It functions similarly to the DNS Name Server Identifier systems. It functions similarly to the DNS Name Server Identifier
(NSID) option described in RFC5001. (NSID) option described in RFC 5001.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 January 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9660.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology
2. The ZONEVERSION Option . . . . . . . . . . . . . . . . . . . 4 2. The ZONEVERSION Option
2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Wire Format
2.2. Presentation Format . . . . . . . . . . . . . . . . . . . 5 2.2. Presentation Format
3. ZONEVERSION Processing . . . . . . . . . . . . . . . . . . . 6 3. ZONEVERSION Processing
3.1. Initiators . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Initiators
3.2. Responders . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Responders
3.2.1. Responding to Invalid ZONEVERSION Queries . . . . . . 7 3.2.1. Responding to Invalid ZONEVERSION Queries
3.2.2. ZONEVERSION Is Not Transitive . . . . . . . . . . . . 7 3.2.2. ZONEVERSION Is Not Transitive
4. The SOA-SERIAL ZONEVERSION Type . . . . . . . . . . . . . . . 7 4. The SOA-SERIAL ZONEVERSION Type
4.1. Type SOA-SERIAL Presentation Format . . . . . . . . . . . 8 4.1. Type SOA-SERIAL Presentation Format
5. Example usage . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Example Usage
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. DNS EDNS(0) Option Code Registration
7.1. DNS EDNS0 Option Code Registration . . . . . . . . . . . 10 6.2. ZONEVERSION TYPE Values Registry
7.2. ZONEVERSION Registry . . . . . . . . . . . . . . . . . . 10 6.2.1. Designated Expert Review Directives
7.2.1. Expert Review Directives . . . . . . . . . . . . . . 11 7. Security Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Normative References
9. Normative References . . . . . . . . . . . . . . . . . . . . 12 9. Informative References
10. Informative References . . . . . . . . . . . . . . . . . . . 12 Appendix A. Implementation Considerations
Appendix A. Implementation Considerations . . . . . . . . . . . 13 Appendix B. Implementation References
Appendix B. Implementation References . . . . . . . . . . . . . 14 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction 1. Introduction
The ZONEVERSION option allows DNS queriers to request, and The ZONEVERSION option allows DNS queriers to request, and
authoritative DNS servers to provide, a token representing the authoritative DNS servers to provide, a token representing the
version of the zone from which a DNS response was generated. It is version of the zone from which a DNS response was generated. It is
similar to the NSID option [RFC5001], which can be used to convey the similar to the NSID option [RFC5001], which can be used to convey the
identification of a name server that generates a response. identification of a name server that generates a response.
The Domain Name System allows data to be loosely coherent [RFC3254], The Domain Name System allows data to be loosely coherent [RFC3254],
because synchronization can never be instantaneous, and some uses of because synchronization can never be instantaneous, and some uses of
DNS do not require strong coherency anyway. This means that a record DNS do not require strong coherency anyway. This means that a record
obtained by one response could be out-of-sync with other obtained by one response could be out of sync with other
authoritative sources of the same data at the same point in time. 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 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. 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 Furthermore, in today's Internet, it is common for high volume and
important DNS zones to utilize IP anycast Section 4.9 of [RFC4786] important DNS zones to utilize IP anycast (Section 4.9 of [RFC4786])
and/or load-balanced backend servers. In general, there is no way to and/or load-balanced backend servers. In general, there is no way to
ensure that two separate queries are delivered to the same server. ensure that two separate queries are delivered to the same server.
The ZONEVERSION option both simplifies and improves the DNS The ZONEVERSION option both simplifies and improves DNS monitoring
monitoring and debugging by directly associating the data and the and debugging by directly associating the data and the version
version together in a single response. together in a single response.
The SOA Serial field (Section 4.3.5 of [RFC1034]) is one example of The SOA SERIAL field (Section 4.3.5 of [RFC1034]) is one example of
zone versioning. Its purpose is to facilitate the distribution of zone versioning. Its purpose is to facilitate the distribution of
zone data between primary and secondary name servers. It is also zone data between primary and secondary name servers. It is also
often useful in DNS monitoring and debugging. This document often useful in DNS monitoring and debugging. This document
specifies the SOA Serial as one type of ZONEVERSION data. specifies the SOA SERIAL as one type of ZONEVERSION data.
Some DNS zones may use other distribution and synchronization 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
databases or other proprietary methods. In those cases the SOA relational databases or other proprietary methods. In those cases,
Serial field may not be relevant with respect to the versioning of the SOA SERIAL field may not be relevant with respect to the
its content. To accommodate these use cases, new ZONEVERSION types versioning of its content. To accommodate these use cases, new
could be defined in future specifications. Alternatively, zone ZONEVERSION types could be defined in future specifications.
operators may use one of the private use ZONEVERSION code points Alternatively, zone operators may use one of the Private Use
allocated by this specification. ZONEVERSION code points allocated by this specification.
The ZONEVERSION option is OPTIONAL to implement by DNS clients and The ZONEVERSION option is OPTIONAL to implement by DNS clients and
name servers. It is designed for use only when a name server name servers. It is designed for use only when a name server
provides authoritative response data. It is intended only for hop- provides authoritative response data. It is intended only for hop-
to-hop communication and is not transitive. to-hop communication and is not transitive.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[BCP14] (RFC2119, RFC8174) when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terminology 1.2. Terminology
In this document "original QNAME" is used to mean what the DNS In this document, "original QNAME" is used to mean what the DNS
terminology document [RFC9499] calls "QNAME (original)": terminology document [RFC9499] calls "QNAME (original)":
| The name actually sent in the Question section in the original | The name actually sent in the Question section in the original
| query, which is always echoed in the (final) reply in the Question | query, which is always echoed in the (final) reply in the Question
| section when the QR bit is set to 1. | section when the QR bit is set to 1.
In this document, an "enclosing zone" of a domain name means a zone In this document, an "enclosing zone" of a domain name means a zone
in which the domain name is present as an owner name, or any parent in which the domain name is present as an owner name or any parent of
of that zone. For example, if B.C.EXAMPLE and EXAMPLE are zones, but that zone. For example, if B.C.EXAMPLE and EXAMPLE are zones but
C.EXAMPLE is not, the domain name A.B.C.EXAMPLE has B.C.EXAMPLE, C.EXAMPLE is not, the domain name A.B.C.EXAMPLE has B.C.EXAMPLE,
EXAMPLE, and the root as enclosing zones. EXAMPLE, and the root as enclosing zones.
2. The ZONEVERSION Option 2. The ZONEVERSION Option
This document specifies a new EDNS(0) (Section 6.1.2 of [RFC6891]) This document specifies a new EDNS(0) [RFC6891] option, ZONEVERSION,
option, ZONEVERSION, which can be used by DNS clients and servers to which can be used by DNS clients and servers to provide information
provide information regarding the version of the zone from which a regarding the version of the zone from which a response is generated.
response is generated.
2.1. Wire Format 2.1. Wire Format
The ZONEVERSION option is encoded as follows: The ZONEVERSION option is encoded as follows:
OPTION-CODE for the ZONEVERSION option is <TBD>. OPTION-CODE for the ZONEVERSION option is 19.
OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for
queries, and MUST have the value of the length (in octets) of the queries and MUST have the value of the length (in octets) of the
OPTION-DATA for responses. OPTION-DATA for responses.
OPTION-DATA for the ZONEVERSION option is omitted in queries. For OPTION-DATA for the ZONEVERSION option is omitted in queries. For
responses it is composed of three fields: responses, it is composed of three fields:
* An unsigned 1-octet Label Count (LABELCOUNT) indicating the number * an unsigned 1-octet Label Count (LABELCOUNT) indicating the number
of labels for the name of the zone that VERSION value refers to. of labels for the name of the zone that VERSION value refers to
* An unsigned 1-octet type number (TYPE) that distinguishes the * an unsigned 1-octet type number (TYPE) distinguishing the format
format and meaning of VERSION. and meaning of VERSION
* An opaque octet string conveying the zone version data (VERSION). * an opaque octet string conveying the zone version data (VERSION)
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LABELCOUNT | TYPE | 0: | LABELCOUNT | TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | VERSION | 2: | VERSION |
/ / / /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: Diagram with the OPTION-DATA format for ZONEVERSION option Figure 1: Diagram with the OPTION-DATA Format for the ZONEVERSION
Option
The LABELCOUNT field indicates the name of the zone that the The LABELCOUNT field indicates the name of the zone that the
ZONEVERSION option refers to, by means of taking the last LABELCOUNT ZONEVERSION option refers to, by means of taking the last LABELCOUNT
labels of the original QNAME. For example, an answer with QNAME labels of the original QNAME. For example, an answer with QNAME
"a.b.c.example.com" and a ZONEVERSION option with a LABELCOUNT of "a.b.c.example.com" and a ZONEVERSION option with a LABELCOUNT of
value 2, indicates that the zone name that this ZONEVERSION refers is value 2 indicates that the zone name in which this ZONEVERSION refers
"example.com.". to is "example.com.".
The LABELCOUNT number helps to differentiate in the case of a In the case of a downward referral response, the LABELCOUNT number
downward referral response, where the parent server is authoritative helps to differentiate between the parent and child zones, where the
for some portion of the QNAME that differs from a child server that parent is authoritative for some portion of the QNAME above a zone
is below the zone cut. Also, if the ANSWER section has more than one cut. Also, if the ANSWER section has more than one RR set with
RR set with different zones (like a CNAME and a target name in different zones (like a CNAME and a target name in another zone), the
another zone) the number of labels in the QNAME disambiguates such a number of labels in the QNAME disambiguates such a situation.
situation.
The value of the LABELCOUNT field MUST NOT count the null (root) The value of the LABELCOUNT field MUST NOT count the null (root)
label that terminates the original QNAME. The value of the label that terminates the original QNAME. The value of the
LABELCOUNT field MUST be less than or equal to the number of labels LABELCOUNT field MUST be less than or equal to the number of labels
in the original QNAME. The Root zone (".") has a LABELCOUNT field in the original QNAME. The Root zone (".") has a LABELCOUNT field
value of 0. value of 0.
2.2. Presentation Format 2.2. Presentation Format
The presentation format of the ZONEVERSION option is as follows: The presentation format of the ZONEVERSION option is as follows:
The OPTION-CODE field MUST be represented as the mnemonic value The OPTION-CODE field MUST be represented as the mnemonic value
ZONEVERSION. ZONEVERSION.
The OPTION-LENGTH field MAY be omitted, but if present it MUST be The OPTION-LENGTH field MAY be omitted, but if present, it MUST be
represented as an unsigned decimal integer. represented as an unsigned decimal integer.
The LABELCOUNT value of OPTION-DATA field MAY be omitted, but if The LABELCOUNT value of the OPTION-DATA field MAY be omitted, but if
present it MUST be represented as an unsigned decimal integer. The present, it MUST be represented as an unsigned decimal integer. The
corresponding zone name SHOULD be displayed (i.e., LABELCOUNT labels corresponding zone name SHOULD be displayed (i.e., LABELCOUNT labels
of the original QNAME) for easier human consumption. of the original QNAME) for easier human consumption.
The TYPE and VERSION fields of the option SHOULD be represented The TYPE and VERSION fields of the option SHOULD be represented
according to each specific TYPE. according to each specific TYPE.
3. ZONEVERSION Processing 3. ZONEVERSION Processing
3.1. Initiators 3.1. Initiators
A DNS client MAY signal its support and desire for zone version A DNS client MAY signal its support and desire for zone version
information by including an empty ZONEVERSION option in the EDNS(0) information by including an empty ZONEVERSION option in the EDNS(0)
OPT pseudo-RR of a query to an authoritative name server. An empty OPT pseudo-RR of a query to an authoritative name server. An empty
ZONEVERSION option has OPTION-LENGTH set to zero. ZONEVERSION option has OPTION-LENGTH set to zero.
A DNS client SHOULD NOT send the ZONEVERSION option to non- A DNS client SHOULD NOT send the ZONEVERSION option to non-
authoritative name servers. authoritative name servers.
A DNS client MUST NOT include more than one ZONEVERSION option in the A DNS client MUST NOT include more than one ZONEVERSION option in the
OPT RR of a DNS query. OPT pseudo-RR of a DNS query.
3.2. Responders 3.2. Responders
A name server that (a) understands the ZONEVERSION option, (b) A name server that (a) understands the ZONEVERSION option, (b)
receives a query with the ZONEVERSION option, (c) is authoritative receives a query with the ZONEVERSION option, (c) is authoritative
for one or more enclosing zones of the original QNAME, and (d) for one or more enclosing zones of the original QNAME, and (d)
chooses to honor a particular ZONEVERSION request responds by chooses to honor a particular ZONEVERSION request responds by
including a TYPE and corresponding VERSION value in a ZONEVERSION including a TYPE and corresponding VERSION value in a ZONEVERSION
option in an EDNS(0) OPT pseudo-RR in the response message. option in an EDNS(0) OPT pseudo-RR in the response message.
skipping to change at page 6, line 43 skipping to change at line 263
response. response.
A name server MAY include more than one ZONEVERSION option in the A name server MAY include more than one ZONEVERSION option in the
response if it supports multiple TYPEs. A name server MAY also response if it supports multiple TYPEs. A name server MAY also
include more than one ZONEVERSION option in the response if it is include more than one ZONEVERSION option in the response if it is
authoritative for more than one enclosing zone of the original QNAME. authoritative for more than one enclosing zone of the original QNAME.
A name server MUST NOT include more than one ZONEVERSION option for a A name server MUST NOT include more than one ZONEVERSION option for a
given TYPE and LABELCOUNT. given TYPE and LABELCOUNT.
Note: the ZONEVERSION option should be included for any response Note: the ZONEVERSION option should be included for any response
satisfying the criteria above, including, but not limited to, the satisfying the criteria above including, but not limited to, the
following: following:
* Downward referral (see "Referrals" in Section 4 of [RFC9499]), * Downward referral (see "Referrals" in Section 4 of [RFC9499]),
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 In this case, the ZONEVERSION data MUST correspond to the version
of the referring zone. of the referring zone.
* Name error (NXDOMAIN), even though the response does not include * Name error (NXDOMAIN), even though the response does not include
any Answer section RRs. any Answer section RRs.
skipping to change at page 7, line 24 skipping to change at line 293
FORMERR response when: FORMERR response when:
* The ZONEVERSION OPTION-LENGTH is not zero. * The ZONEVERSION OPTION-LENGTH is not zero.
* More than one ZONEVERSION option is present. * More than one ZONEVERSION option is present.
3.2.2. ZONEVERSION Is Not Transitive 3.2.2. ZONEVERSION Is Not Transitive
The ZONEVERSION option is not transitive. A name server (recursive The ZONEVERSION option is not transitive. A name server (recursive
or otherwise) MUST NOT blindly copy the ZONEVERSION option from a or otherwise) MUST NOT blindly copy the ZONEVERSION option from a
query it receives into a subsquent query that it sends onward to query it receives into a subsequent query that it sends onward to
another server. A name server MUST NOT send a ZONEVERSION option another server. A name server MUST NOT send a ZONEVERSION option
back to a client which did not request it. back to a client that did not request it.
4. The SOA-SERIAL ZONEVERSION Type 4. The SOA-SERIAL ZONEVERSION Type
The first and only ZONEVERSION option TYPE defined in this document 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) is a zone's serial number as found in the Start of Authority (SOA)
RR. RR.
As mentioned previously, some DNS zones may use alternative 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
Serial number and the Serial field may not be relevant with respect SOA SERIAL number, and the SERIAL field may not be relevant with
to the versioning of zone content. In those cases a name server respect to the versioning of zone content. In those cases, a name
SHOULD NOT include a ZONEVERSION option with type SOA-SERIAL in a server SHOULD NOT include a ZONEVERSION option with type SOA-SERIAL
reply. in a reply.
The value for this type is: 0 The value for this type is "0".
The mnemonic of this type is: SOA-SERIAL. The mnemonic for this type is "SOA-SERIAL".
The EDNS(0) OPTION-LENGTH for this type MUST be set to 6 in The EDNS(0) OPTION-LENGTH for this type MUST be set to "6" in
responses. responses.
The VERSION value for the SOA-SERIAL type MUST be a copy of the The VERSION value for the SOA-SERIAL type MUST be a copy of the
unsigned 32-bit SERIAL field of the SOA RR, as defined in unsigned 32-bit SERIAL field of the SOA RR, as defined in
Section 3.3.13 of [RFC1035]. Section 3.3.13 of [RFC1035].
4.1. Type SOA-SERIAL Presentation Format 4.1. Type SOA-SERIAL Presentation Format
The presentation format of this type content is as follows: The presentation format of this type content is as follows:
The TYPE field MUST be represented as the mnemonic value "SOA- The TYPE field MUST be represented as the mnemonic value "SOA-
SERIAL". SERIAL".
The VERSION field MUST be represented as an unsigned decimal integer. The VERSION field MUST be represented as an unsigned decimal
integer.
5. Example usage 5. Example Usage
A name server which (a) implements this specification, (b) receives a A name server that (a) implements this specification, (b) receives a
query with the ZONEVERSION option, (c) is authoritative for the zone query with the ZONEVERSION option, (c) is authoritative for the zone
of the original QNAME, and (d) utilizes the SOA serial field for of the original QNAME, and (d) utilizes the SOA SERIAL field for
versioning of said zone should include a ZONEVERSION option in its versioning of said zone should include a ZONEVERSION option in its
response. In the response's ZONEVERSION option the EDNS(0) OPTION- response. In the response's ZONEVERSION option, the EDNS(0) OPTION-
LENGTH would be set to 6 and the OPTION-DATA would consist of the 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 4-octet SOA 1-octet LABELCOUNT, the 1-octet TYPE with value 0, and the 4-octet
SERIAL value. SOA-SERIAL value.
The example below demonstrates expected output of a diagnostic tool The example below demonstrates expected output of a diagnostic tool
that implements the ZONEVERSION option, displaying a response from a that implements the ZONEVERSION option, displaying a response from a
compliant authoritative DNS server: compliant authoritative DNS server:
$ 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 +zoneversion ;; Got answer:
; (1 server found) ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
;; global options: +cmd ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
;; 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 \
;; QUESTION SECTION: ; (example.com.)")
;www.example.com. IN AAAA ;; QUESTION SECTION:
;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
Figure 2: Example usage and dig output Figure 2: Example Usage and Dig Output
6. Acknowledgements 6. IANA Considerations
The authors thanks all the comments and support made in the DNSOP 6.1. DNS EDNS(0) Option Code Registration
mailing list, chats and discussions. Special thanks for the
suggestions to generalize the option using a registry of types from
Petr Špaček and Florian Obser, suggestions for implementation from
Stéphane Bortzmeyer, security clarifications from George Michaelson,
zone name disambiguation from Joe Abley and Brian Dickson, and
reviews from Tim Wicinski and Peter Thomassen.
7. IANA Considerations This document defines a new EDNS(0) option, entitled "ZONEVERSION"
7.1. DNS EDNS0 Option Code Registration (see Section 2), with the assigned value of 19 from the "DNS EDNS0
Option Codes (OPT)" registry:
This document defines a new EDNS0 option, entitled ZONEVERSION (see +=======+=============+==========+===========+
Section 2), and assigns a value of <TBD> from the DNS EDNS0 Option | Value | Name | Status | Reference |
Codes (OPT) Option space: +=======+=============+==========+===========+
| 19 | ZONEVERSION | Standard | RFC 9660 |
+=======+=============+==========+===========+
+=======+=============+==========+=================+ Table 1: DNS EDNS0 Option Codes (OPT) Registry
| Value | Name | Status | Reference |
+=======+=============+==========+=================+
| <TBD> | ZONEVERSION | Standard | [this document] |
+=======+=============+==========+=================+
Table 1: DNS EDNS0 Option code 6.2. ZONEVERSION TYPE Values Registry
7.2. ZONEVERSION Registry IANA has created and will maintain a new registry called "ZONEVERSION
TYPE Values" in the "Domain Name System (DNS) Parameters" registry
group as follows:
The ZONEVERSION option also defines a 8-bit TYPE field, for which +=========+=========================+
IANA is requested to create and maintain a new registry entitled | Range | Registration Procedures |
"ZONEVERSION TYPE Values" (abbreviation ZONEVERSION) used by the +=========+=========================+
ZONEVERSION option, inside the "Domain Name System (DNS) Parameters" | 0-245 | Specification Required |
group. Initial values for the ZONEVERSION TYPE values registry are +=========+=========================+
given below; future assignments in the 1-245 values are to be made | 246-254 | Private Use |
through Specification Required review [BCP26]. Assignments consist +=========+=========================+
of a TYPE value as an unsigned 8-bit integer recorded in decimal, a | 255 | Reserved |
Mnemonic name as an uppercase ASCII string with maximum length of 15 +=========+=========================+
characters, and the required document reference.
+==================+==================+=================+ Table 2: Registration Procedures
| ZONEVERSION TYPE | Mnemonic | Reference | for the ZONEVERSION TYPE Values
+==================+==================+=================+ Registry
| 0 | SOA-SERIAL | [this document] |
+==================+==================+=================+
| 1-245 | Unassigned | |
+==================+==================+=================+
| 246-254 | Private Use | [this document] |
+==================+==================+=================+
| 255 | Reserved for | [this document] |
| | future expansion | |
+==================+==================+=================+
Table 2: ZONEVERSION Registry 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]. 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.
The change control for this registry should be by means of an +==================+==========================+===========+
Standard action. | ZONEVERSION TYPE | Mnemonic | Reference |
+==================+==========================+===========+
| 0 | SOA-SERIAL | RFC 9660 |
+==================+==========================+===========+
| 1-245 | Unassigned | |
+==================+==========================+===========+
| 246-254 | Reserved for Private Use | RFC 9660 |
+==================+==========================+===========+
| 255 | Reserved | RFC 9660 |
+==================+==========================+===========+
7.2.1. Expert Review Directives Table 3: ZONEVERSION TYPE Values Registry
Allocation procedures for new code points in the ZONEVERSION TYPE The change controller for this registry is IETF.
registry require Specification Required review, and so it requires
Expert Reviews as stated in [BCP26].
The expert should consider the following points: 6.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:
* Duplication of code point allocations should be avoided. * Duplication of code point allocations should be avoided.
* A Presentation Format section should be provided, with a clear * A Presentation Format section should be provided with a clear code
code point mnemonic. point mnemonic.
* The referenced document and stated use of the new code point * The referenced document and stated use of the new code point
should be appropriate for the intended use of a ZONEVERSION TYPE should be appropriate for the intended use of a ZONEVERSION TYPE
assignment. In particular the reference should state clear assignment. In particular, the reference should state clear
instructions for implementers about the syntax and semantic of the instructions for implementers about the syntax and semantic of the
data. Also the Length of the Data must have proper limits. data. Also, the length of the data must have proper limits.
The expert reviewing the request MUST approve or disapprove the The expert reviewing the request MUST respond within 10 business
request within 10 business days from when she or he received the days.
expert review request.
8. Security Considerations 7. Security Considerations
The EDNS extension data it's not covered by RRSIG records, so there's The EDNS extension data is not covered by RRSIG records, so there's
no way to verify its authenticity nor integrity using DNSSEC and no way to verify its authenticity nor integrity using DNSSEC, and it
could theoretically be tampered by a person-in-the-middle if the could theoretically be tampered with by a person in the middle if the
transport is made by insecure means. Caution should be taken to use transport is made by insecure means. Caution should be taken to use
the EDNS ZONEVERSION data for any means besides troubleshooting and the EDNS ZONEVERSION data for any means besides troubleshooting and
debugging. debugging.
If there's a need to certify the ZONEVERSION trustworthiness, it will If there's a need to certify the trustworthiness of ZONEVERSION, it
be necessary to use an encrypted and authenticated DNS transport, will be necessary to use an encrypted and authenticated DNS
TSIG [RFC8945], or SIG(0) [RFC2931]. transport, a transaction signature (TSIG) [RFC8945], or SIG(0)
[RFC2931].
If there's a need to authenticate data origin for the ZONEVERSION 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 value, an answer with the SOA-SERIAL type as defined above could be
compared to a separate regular SOA query with DO flag, whose answer compared to a separate regular SOA query with a DO flag, whose answer
shall be DNSSEC signed, with the cautions about Anycast and others as shall be DNSSEC signed. Since these are separate queries, the
already stated in Introduction. caveats about loose coherency already stated in the Introduction
(Section 1) would apply.
With the SOA-SERIAL type defined above, there's no risk on disclosure 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 of private information, as the SERIAL of the SOA record is already
publicly available. publicly available.
Please note that the ZONEVERSION option can not be used for checking Please note that the ZONEVERSION option cannot be used for checking
the correctness of an entire zone in a server. For such cases, the the correctness of an entire zone in a server. For such cases, the
ZONEMD record [RFC8976] might be better suited at such a task. ZONEMD record [RFC8976] might be better suited for such a task.
ZONEVERSION can help identify and correlate a certain specific answer ZONEVERSION can help identify and correlate a specific answer with a
with a version of a zone, but it has no special integrity or version of a zone, but it has no special integrity or verification
verification function besides a normal field value inside a zone, as function besides a normal field value inside a zone, as stated above.
stated above.
9. Normative References
[BCP14] Best Current Practice 14,
<https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:
Cotton, M., Leiba, B., and T. Narten, "Guidelines for 8. Normative References
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013, DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>. <https://www.rfc-editor.org/info/rfc6891>.
10. Informative References [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[ImplRef] Salgado, H., "Zoneversion Implementations", 2023, [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
<https://github.com/huguei/rrserial>. 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9. Informative References
[ImplRef] "Zoneversion Implementations", commit f5f68a0, August
2023, <https://github.com/huguei/rrserial>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>. 2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC3254] Alvestrand, H., "Definitions for talking about [RFC3254] Alvestrand, H., "Definitions for talking about
directories", RFC 3254, DOI 10.17487/RFC3254, April 2002, directories", RFC 3254, DOI 10.17487/RFC3254, April 2002,
<https://www.rfc-editor.org/info/rfc3254>. <https://www.rfc-editor.org/info/rfc3254>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
skipping to change at page 13, line 41 skipping to change at line 556
Hardaker, "Message Digest for DNS Zones", RFC 8976, Hardaker, "Message Digest for DNS Zones", RFC 8976,
DOI 10.17487/RFC8976, February 2021, DOI 10.17487/RFC8976, February 2021,
<https://www.rfc-editor.org/info/rfc8976>. <https://www.rfc-editor.org/info/rfc8976>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024, RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>. <https://www.rfc-editor.org/info/rfc9499>.
Appendix A. Implementation Considerations Appendix A. Implementation Considerations
With very few exceptions, EDNS options which elicit an EDNS option in With very few exceptions, EDNS(0) option values in a response are
the response are independent of the queried name. This is not the independent of the queried name. This is not the case for
case of ZONEVERSION, so its implementation may be more or less ZONEVERSION, so its implementation may be more or less difficult,
difficult depending on how EDNS options are handled in the name depending on how EDNS(0) options are handled in the name server.
server.
Appendix B. Implementation References Appendix B. Implementation References
There's a patched NSD server version 4.7.0 with support for There is a patched NSD server (version 4.7.0) with support for
ZONEVERSION with an experimental opcode, with live test servers ZONEVERSION as well as live test servers installed for compliance
installed for compliance tests. Also there is a client command "dig" tests. Also, there is a client command "dig" with added zoneversion
with added zoneversion support, along with test libraries in Perl, support, along with test libraries in Perl, Python, and Go. See
Python and Go. More information in the working document [ImplRef]. [ImplRef] for more information.
Acknowledgements
The authors are thankful for all the support and comments made in the
DNSOP Working Group mailing list, chats, and discussions. A special
thanks for suggestions to generalize the option using a registry of
types from Petr Špaček and Florian Obser, suggestions for
implementation from Stéphane Bortzmeyer, clarifications on security
from George Michaelson, zone name disambiguation from Joe Abley and
Brian Dickson, and reviews from Tim Wicinski and Peter Thomassen.
Authors' Addresses Authors' Addresses
Hugo Salgado Hugo Salgado
NIC Chile NIC Chile
Miraflores 222, piso 14 Miraflores 222, piso 14
CP 8320198 Santiago CP 8320198 Santiago
Chile Chile
Phone: +56 2 29407700 Phone: +56 2 29407700
Email: hsalgado@nic.cl Email: hsalgado@nic.cl
Mauricio Vergara Ereche Mauricio Vergara Ereche
DigitalOcean DigitalOcean
101 6th Ave 101 6th Ave
New York, NY 10013 New York, NY 10013
United States of America United States of America
Email: mvergara@digitalocean.com Email: mvergara@digitalocean.com
Duane Wessels Duane Wessels
Verisign Verisign
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States of America United States of America
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: dwessels@verisign.com Email: dwessels@verisign.com
 End of changes. 86 change blocks. 
254 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.48.