wdiff rfc9660.original rfc9660.txt



Internet Engineering Task Force (IETF)                        H. Salgado
Internet-Draft
Request for Comments: 9660                                     NIC Chile
Intended status:
Category: Standards Track                                     M. Vergara
Expires: 24 January 2025
ISSN: 2070-1721                                             DigitalOcean
                                                              D. Wessels
                                                                Verisign
                                                            23 July
                                                            October 2024

               The DNS Zone Version (ZONEVERSION) Option
                    draft-ietf-dnsop-zoneversion-11

Abstract

   The DNS ZONEVERSION option is a way for DNS clients to request, and
   for authoritative DNS servers to provide, information regarding the
   version of the zone from which a response is generated.  The Serial SERIAL
   field from the Start Of of Authority (SOA) resource record (RR) is a
   good example of a zone's version, and it is the only one defined by
   this specification.  Additional version types may be defined by
   future specifications.

   Including zone version data in a response simplifies and improves the
   quality of debugging and diagnostics since the version and the DNS
   answer are provided atomically.  This can be especially useful for
   zones and DNS providers that leverage IP anycast or multiple backend
   systems.  It functions similarly to the DNS Name Server Identifier
   (NSID) option described in RFC5001. RFC 5001.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 January 2025.
   https://www.rfc-editor.org/info/rfc9660.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info)
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The ZONEVERSION Option  . . . . . . . . . . . . . . . . . . .   4
     2.1.  Wire Format . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Presentation Format . . . . . . . . . . . . . . . . . . .   5
   3.  ZONEVERSION Processing  . . . . . . . . . . . . . . . . . . .   6
     3.1.  Initiators  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Responders  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.1.  Responding to Invalid ZONEVERSION Queries . . . . . .   7
       3.2.2.  ZONEVERSION Is Not Transitive . . . . . . . . . . . .   7
   4.  The SOA-SERIAL ZONEVERSION Type . . . . . . . . . . . . . . .   7
     4.1.  Type SOA-SERIAL Presentation Format . . . . . . . . . . .   8
   5.  Example usage . . . . . . . . . . . . . . . . . . . . . . . .   8 Usage
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.1.
     6.1.  DNS EDNS0 EDNS(0) Option Code Registration  . . . . . . . . . . .  10
     7.2.
     6.2.  ZONEVERSION TYPE Values Registry  . . . . . . . . . . . . . . . . . .  10
       7.2.1.
       6.2.1.  Designated Expert Review Directives  . . . . . . . . . . . . . .  11
   8.
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   10.
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Implementation Considerations  . . . . . . . . . . .  13
   Appendix B.  Implementation References  . . . . . . . . . . . . .  14
   Acknowledgements
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The ZONEVERSION option allows DNS queriers to request, and
   authoritative DNS servers to provide, a token representing the
   version of the zone from which a DNS response was generated.  It is
   similar to the NSID option [RFC5001], which can be used to convey the
   identification of a name server that generates a response.

   The Domain Name System allows data to be loosely coherent [RFC3254],
   because synchronization can never be instantaneous, and some uses of
   DNS do not require strong coherency anyway.  This means that a record
   obtained by one response could be out-of-sync out of sync with other
   authoritative sources of the same data at the same point in time.
   This can make it difficult to debug some problems when there is a
   need to couple the data with the version of the zone it came from.
   Furthermore, in today's Internet, it is common for high volume and
   important DNS zones to utilize IP anycast Section (Section 4.9 of [RFC4786] [RFC4786])
   and/or load-balanced backend servers.  In general, there is no way to
   ensure that two separate queries are delivered to the same server.
   The ZONEVERSION option both simplifies and improves the DNS monitoring
   and debugging by directly associating the data and the version
   together in a single response.

   The SOA Serial SERIAL field (Section 4.3.5 of [RFC1034]) is one example of
   zone versioning.  Its purpose is to facilitate the distribution of
   zone data between primary and secondary name servers.  It is also
   often useful in DNS monitoring and debugging.  This document
   specifies the SOA Serial SERIAL as one type of ZONEVERSION data.

   Some DNS zones may use other distribution and synchronization
   mechanisms that are not based on the SOA Serial SERIAL number, such as
   relational databases or other proprietary methods.  In those cases cases,
   the SOA
   Serial SERIAL field may not be relevant with respect to the
   versioning of its content.  To accommodate these use cases, new
   ZONEVERSION types could be defined in future specifications.
   Alternatively, zone operators may use one of the private use Private Use
   ZONEVERSION code points allocated by this specification.

   The ZONEVERSION option is OPTIONAL to implement by DNS clients and
   name servers.  It is designed for use only when a name server
   provides authoritative response data.  It is intended only for hop-
   to-hop communication and is not transitive.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [BCP14] (RFC2119, RFC8174)
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Terminology

   In this document document, "original QNAME" is used to mean what the DNS
   terminology document [RFC9499] calls "QNAME (original)":

   |  The name actually sent in the Question section in the original
   |  query, which is always echoed in the (final) reply in the Question
   |  section when the QR bit is set to 1.

   In this document, an "enclosing zone" of a domain name means a zone
   in which the domain name is present as an owner name, name or any parent of
   that zone.  For example, if B.C.EXAMPLE and EXAMPLE are zones, zones but
   C.EXAMPLE is not, the domain name A.B.C.EXAMPLE has B.C.EXAMPLE,
   EXAMPLE, and the root as enclosing zones.

2.  The ZONEVERSION Option

   This document specifies a new EDNS(0) (Section 6.1.2 of [RFC6891]) [RFC6891] option, ZONEVERSION,
   which can be used by DNS clients and servers to provide information
   regarding the version of the zone from which a response is generated.

2.1.  Wire Format

   The ZONEVERSION option is encoded as follows:

   OPTION-CODE for the ZONEVERSION option is <TBD>. 19.

   OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for
   queries,
   queries and MUST have the value of the length (in octets) of the
   OPTION-DATA for responses.

   OPTION-DATA for the ZONEVERSION option is omitted in queries.  For
   responses
   responses, it is composed of three fields:

   *  An  an unsigned 1-octet Label Count (LABELCOUNT) indicating the number
      of labels for the name of the zone that VERSION value refers to. to

   *  An  an unsigned 1-octet type number (TYPE) that distinguishes distinguishing the format
      and meaning of VERSION. VERSION

   *  An  an opaque octet string conveying the zone version data (VERSION). (VERSION)

                   +0 (MSB)                       +1 (LSB)
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |           LABELCOUNT          |            TYPE               |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   2: |                            VERSION                            |
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

     Figure 1: Diagram with the OPTION-DATA format Format for the ZONEVERSION option
                                   Option

   The LABELCOUNT field indicates the name of the zone that the
   ZONEVERSION option refers to, by means of taking the last LABELCOUNT
   labels of the original QNAME.  For example, an answer with QNAME
   "a.b.c.example.com" and a ZONEVERSION option with a LABELCOUNT of
   value 2, 2 indicates that the zone name that in which this ZONEVERSION refers
   to is "example.com.".

   The LABELCOUNT number helps to differentiate in

   In the case of a downward referral response, the LABELCOUNT number
   helps to differentiate between the parent and child zones, where the
   parent server is authoritative for some portion of the QNAME that differs from above a child server that
   is below the zone
   cut.  Also, if the ANSWER section has more than one RR set with
   different zones (like a CNAME and a target name in another zone) zone), the
   number of labels in the QNAME disambiguates such a situation.

   The value of the LABELCOUNT field MUST NOT count the null (root)
   label that terminates the original QNAME.  The value of the
   LABELCOUNT field MUST be less than or equal to the number of labels
   in the original QNAME.  The Root zone (".") has a LABELCOUNT field
   value of 0.

2.2.  Presentation Format

   The presentation format of the ZONEVERSION option is as follows:

   The OPTION-CODE field MUST be represented as the mnemonic value
   ZONEVERSION.

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

   The LABELCOUNT value of the OPTION-DATA field MAY be omitted, but if
   present
   present, it MUST be represented as an unsigned decimal integer.  The
   corresponding zone name SHOULD be displayed (i.e., LABELCOUNT labels
   of the original QNAME) for easier human consumption.

   The TYPE and VERSION fields of the option SHOULD be represented
   according to each specific TYPE.

3.  ZONEVERSION Processing

3.1.  Initiators

   A DNS client MAY signal its support and desire for zone version
   information by including an empty ZONEVERSION option in the EDNS(0)
   OPT pseudo-RR of a query to an authoritative name server.  An empty
   ZONEVERSION option has OPTION-LENGTH set to zero.

   A DNS client SHOULD NOT send the ZONEVERSION option to non-
   authoritative name servers.

   A DNS client MUST NOT include more than one ZONEVERSION option in the
   OPT RR pseudo-RR of a DNS query.

3.2.  Responders

   A name server that (a) understands the ZONEVERSION option, (b)
   receives a query with the ZONEVERSION option, (c) is authoritative
   for one or more enclosing zones of the original QNAME, and (d)
   chooses to honor a particular ZONEVERSION request responds by
   including a TYPE and corresponding VERSION value in a ZONEVERSION
   option in an EDNS(0) OPT pseudo-RR in the response message.

   Otherwise, a server MUST NOT include a ZONEVERSION option in the
   response.

   A name server MAY include more than one ZONEVERSION option in the
   response if it supports multiple TYPEs.  A name server MAY also
   include more than one ZONEVERSION option in the response if it is
   authoritative for more than one enclosing zone of the original QNAME.
   A name server MUST NOT include more than one ZONEVERSION option for a
   given TYPE and LABELCOUNT.

   Note: the ZONEVERSION option should be included for any response
   satisfying the criteria above, above including, but not limited to, the
   following:

   *  Downward referral (see "Referrals" in Section 4 of [RFC9499]),
      even though the response's Authoritative Answer bit is not set.
      In this case, the ZONEVERSION data MUST correspond to the version
      of the referring zone.

   *  Name error (NXDOMAIN), even though the response does not include
      any Answer section RRs.

   *  NODATA (Section 3 of [RFC9499]), even though the response does not
      include any Answer section RRs.

   *  Server failure (SERVFAIL) when the server is authoritative for the
      original QNAME.

3.2.1.  Responding to Invalid ZONEVERSION Queries

   A name server that understands the ZONEVERSION option MUST return a
   FORMERR response when:

   *  The ZONEVERSION OPTION-LENGTH is not zero.

   *  More than one ZONEVERSION option is present.

3.2.2.  ZONEVERSION Is Not Transitive

   The ZONEVERSION option is not transitive.  A name server (recursive
   or otherwise) MUST NOT blindly copy the ZONEVERSION option from a
   query it receives into a subsquent subsequent query that it sends onward to
   another server.  A name server MUST NOT send a ZONEVERSION option
   back to a client which that did not request it.

4.  The SOA-SERIAL ZONEVERSION Type

   The first and only ZONEVERSION option TYPE defined in this document
   is a zone's serial number as found in the Start of Authority (SOA)
   RR.

   As mentioned previously, some DNS zones may use alternative
   distribution and synchronization mechanisms that are not based on the
   SOA
   Serial number SERIAL number, and the Serial SERIAL field may not be relevant with
   respect to the versioning of zone content.  In those cases cases, a name
   server SHOULD NOT include a ZONEVERSION option with type SOA-SERIAL
   in a reply.

   The value for this type is: 0 is "0".

   The mnemonic of for this type is: SOA-SERIAL. is "SOA-SERIAL".

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

   The VERSION value for the SOA-SERIAL type MUST be a copy of the
   unsigned 32-bit SERIAL field of the SOA RR, as defined in
   Section 3.3.13 of [RFC1035].

4.1.  Type SOA-SERIAL Presentation Format

   The presentation format of this type content is as follows:

      The TYPE field MUST be represented as the mnemonic value "SOA-
      SERIAL".

      The VERSION field MUST be represented as an unsigned decimal
      integer.

5.  Example usage Usage

   A name server which that (a) implements this specification, (b) receives a
   query with the ZONEVERSION option, (c) is authoritative for the zone
   of the original QNAME, and (d) utilizes the SOA serial SERIAL field for
   versioning of said zone should include a ZONEVERSION option in its
   response.  In the response's ZONEVERSION option option, the EDNS(0) OPTION-
   LENGTH would be set to 6 and the OPTION-DATA would consist of the
   1-octet LABELCOUNT, the 1-octet TYPE with value 0, and the 4-octet SOA
   SERIAL
   SOA-SERIAL value.

   The example below demonstrates expected output of a diagnostic tool
   that implements the ZONEVERSION option, displaying a response from a
   compliant authoritative DNS server:

     $ dig @ns.example.com www.example.com aaaa +zoneversion \
     +norecurse

  ; <<>> DiG 9.17.14-patched <<>> @ns.example.com www.example.com aaaa +zoneversion
  ; (1 server found)
  ;; global options: +cmd +nocmd

     ;; Got answer:
     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
     ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

     ;; OPT PSEUDOSECTION:
     ; EDNS: version: 0, flags:; udp: 1232
     ; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 \
     ; (example.com.)")
     ;; QUESTION SECTION:
     ;www.example.com.    IN  AAAA

     ;; ANSWER SECTION:
     www.example.com.  43200  IN  AAAA  2001:db8::80

     ;; AUTHORITY SECTION:
     example.com.    43200  IN  NS  ns.example.com.

     ;; ADDITIONAL SECTION:
     ns.example.com.    43200  IN  AAAA  2001:db8::53

     ;; Query time: 15 msec
     ;; SERVER: 2001:db8::53#53(2001:db8::53) (UDP)
     ;; WHEN: dom jul 30 19:51:04 -04 2023
     ;; MSG SIZE  rcvd: 129

                   Figure 2: Example usage Usage and dig output Dig Output

6.  Acknowledgements

   The authors thanks all the comments and support made in the DNSOP
   mailing list, chats and discussions.  Special thanks for the
   suggestions to generalize the option using a registry of types from
   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

7.1.

6.1.  DNS EDNS0 EDNS(0) Option Code Registration

   This document defines a new EDNS0 EDNS(0) option, entitled ZONEVERSION "ZONEVERSION"
   (see Section 2), and assigns a with the assigned value of <TBD> 19 from the DNS "DNS EDNS0
   Option Codes (OPT) Option space:

           +=======+=============+==========+=================+ (OPT)" registry:

              +=======+=============+==========+===========+
              | Value | Name        | Status   | Reference |
           +=======+=============+==========+=================+
              +=======+=============+==========+===========+
              | <TBD> 19    | ZONEVERSION | Standard | [this document] RFC 9660  |
           +=======+=============+==========+=================+
              +=======+=============+==========+===========+

              Table 1: DNS EDNS0 Option code

7.2.  ZONEVERSION Codes (OPT) Registry

   The

6.2.  ZONEVERSION option also defines a 8-bit TYPE field, for which Values Registry

   IANA is requested to create has created and will maintain a new registry entitled called "ZONEVERSION
   TYPE Values" (abbreviation ZONEVERSION) used by the
   ZONEVERSION option, inside in the "Domain Name System (DNS) Parameters"
   group.  Initial values registry
   group as follows:

                   +=========+=========================+
                   | Range   | Registration Procedures |
                   +=========+=========================+
                   | 0-245   | Specification Required  |
                   +=========+=========================+
                   | 246-254 | Private Use             |
                   +=========+=========================+
                   | 255     | Reserved                |
                   +=========+=========================+

                      Table 2: Registration Procedures
                      for the ZONEVERSION TYPE Values
                                  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 review [BCP26]. [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.

         +==================+==================+=================+

        +==================+==========================+===========+
        | ZONEVERSION TYPE | Mnemonic                 | Reference |
         +==================+==================+=================+
        +==================+==========================+===========+
        | 0                | SOA-SERIAL               | [this document] RFC 9660  |
         +==================+==================+=================+
        +==================+==========================+===========+
        | 1-245            | Unassigned               |           |
         +==================+==================+=================+
        +==================+==========================+===========+
        | 246-254          | Reserved for Private Use | [this document] RFC 9660  |
         +==================+==================+=================+
        +==================+==========================+===========+
        | 255              | Reserved for     | [this document] |
         |                  | future expansion                 | RFC 9660  |
         +==================+==================+=================+
        +==================+==========================+===========+

                 Table 2: 3: ZONEVERSION TYPE Values Registry

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

7.2.1. is IETF.

6.2.1.  Designated Expert Review Directives

   Allocation procedures

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

   The [RFC8126].

   When evaluating requests, the expert should consider the following points: following:

   *  Duplication of code point allocations should be avoided.

   *  A Presentation Format section should be provided, provided with a clear code
      point mnemonic.

   *  The referenced document and stated use of the new code point
      should be appropriate for the intended use of a ZONEVERSION TYPE
      assignment.  In particular particular, the reference should state clear
      instructions for implementers about the syntax and semantic of the
      data.  Also  Also, the Length length of the Data data must have proper limits.

   The expert reviewing the request MUST approve or disapprove the
   request respond within 10 business days from when she or he received the
   expert review request.

8.
   days.

7.  Security Considerations

   The EDNS extension data it's is not covered by RRSIG records, so there's
   no way to verify its authenticity nor integrity using DNSSEC DNSSEC, and it
   could theoretically be tampered with by a person-in-the-middle person in the middle if the
   transport is made by insecure means.  Caution should be taken to use
   the EDNS ZONEVERSION data for any means besides troubleshooting and
   debugging.

   If there's a need to certify the ZONEVERSION trustworthiness, trustworthiness of ZONEVERSION, it
   will be necessary to use an encrypted and authenticated DNS
   transport,
   TSIG a transaction signature (TSIG) [RFC8945], or SIG(0)
   [RFC2931].

   If there's a need to authenticate the data origin for the ZONEVERSION
   value, an answer with the SOA-SERIAL type as defined above could be
   compared to a separate regular SOA query with a DO flag, whose answer
   shall be DNSSEC signed, with signed.  Since these are separate queries, the cautions
   caveats about Anycast and others as loose coherency already stated in Introduction. the Introduction
   (Section 1) would apply.

   With the SOA-SERIAL type defined above, there's no risk on disclosure
   of private information, as the SERIAL of the SOA record is already
   publicly available.

   Please note that the ZONEVERSION option can not cannot be used for checking
   the correctness of an entire zone in a server.  For such cases, the
   ZONEMD record [RFC8976] might be better suited at for such a task.
   ZONEVERSION can help identify and correlate a certain specific answer with a
   version of a zone, but it has no special integrity or verification
   function besides a normal field value inside a zone, as stated above.

9.

8.  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
              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",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/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
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/info/rfc6891>.

10.

   [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>.

   [RFC8174]  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>.

9.  Informative References

   [ImplRef]  Salgado, H.,  "Zoneversion Implementations", commit f5f68a0, August
              2023, <https://github.com/huguei/rrserial>.

   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
              ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
              2000, <https://www.rfc-editor.org/info/rfc2931>.

   [RFC3254]  Alvestrand, H., "Definitions for talking about
              directories", RFC 3254, DOI 10.17487/RFC3254, April 2002,
              <https://www.rfc-editor.org/info/rfc3254>.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
              December 2006, <https://www.rfc-editor.org/info/rfc4786>.

   [RFC5001]  Austein, R., "DNS Name Server Identifier (NSID) Option",
              RFC 5001, DOI 10.17487/RFC5001, August 2007,
              <https://www.rfc-editor.org/info/rfc5001>.

   [RFC8945]  Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
              Gudmundsson, O., and B. Wellington, "Secret Key
              Transaction Authentication for DNS (TSIG)", STD 93,
              RFC 8945, DOI 10.17487/RFC8945, November 2020,
              <https://www.rfc-editor.org/info/rfc8945>.

   [RFC8976]  Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
              Hardaker, "Message Digest for DNS Zones", RFC 8976,
              DOI 10.17487/RFC8976, February 2021,
              <https://www.rfc-editor.org/info/rfc8976>.

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/info/rfc9499>.

Appendix A.  Implementation Considerations

   With very few exceptions, EDNS options which elicit an EDNS EDNS(0) option values in
   the a response are
   independent of the queried name.  This is not the case of for
   ZONEVERSION, so its implementation may be more or less
   difficult difficult,
   depending on how EDNS EDNS(0) options are handled in the name server.

Appendix B.  Implementation References

   There's

   There is a patched NSD server version 4.7.0 (version 4.7.0) with support for
   ZONEVERSION with an experimental opcode, with as well as live test servers installed for compliance
   tests.  Also  Also, there is a client command "dig" with added zoneversion
   support, along with test libraries in Perl,
   Python Python, and Go.  More information  See
   [ImplRef] for more information.

Acknowledgements

   The authors are thankful for all the support and comments made in the working document [ImplRef].
   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

   Hugo Salgado
   NIC Chile
   Miraflores 222, piso 14
   CP 8320198 Santiago
   Chile
   Phone: +56 2 29407700
   Email: hsalgado@nic.cl

   Mauricio Vergara Ereche
   DigitalOcean
   101 6th Ave
   New York, NY 10013
   United States of America
   Email: mvergara@digitalocean.com

   Duane Wessels
   Verisign
   12061 Bluemont Way
   Reston, VA 20190
   United States of America
   Phone: +1 703 948-3200
   Email: dwessels@verisign.com
   URI:   https://verisign.com