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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-zoneversion-10 (we had previously reviewed -06 of this document as well). If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the DNS EDNS0 Option Codes (OPT) registry in the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

a single new option code will be registered as follows:

Value: [ TBD-at-Registration ]
Name: ZONEVERSION
Status: Standard
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, a new registry is to be created called the ZONEVERSION Type registry. The new registry will be located on the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

The new registry will be managed via Specification Required as defined in RFC8126.

There are initial registrations in the new registry as follows:

ZONEVERSION TYPE Mnemonic Reference
---------------------+----------+-----------
0 SOA-SERIAL [ RFC-to-be ]
1-245 Unassigned
246-254 Private Use [ RFC-to-be ]
255 Reserved for future expansion [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-07-16):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-zoneversion@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'The DNS Zone Version
(ZONEVERSION) Option'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-07-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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
  field from the Start Of Authority (SOA) resource record is a good
  example of a zone's version, and 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 [RFC5001].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/



No IPR declarations have been submitted directly on this I-D.

The following Last Call announcement was sent out (ends 2024-07-16):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-zoneversion@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'The DNS Zone Version
(ZONEVERSION) Option'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-07-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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
  field from the Start Of Authority (SOA) resource record is a good
  example of a zone's version, and 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 [RFC5001].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/



No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
Thanks to John Levine for his ARTART review.

I support John's, Paul's, and Eric's DISCUSS positions.

Why the SHOULD NOT in Section 3.1?  If a client decides to include that option when talking to a non-authoritative server, what can happen?  Or put another way, why leave the client an out here?  Is there a legitimate reason to allow this?

I have a similar question about each of the SHOULDs in Section 3.2.  Why are we offering a choice here?  Why might I decide to deviate in each case?

[Ballot comment]
### Section 7.2

"assignments in the 1-245 values are to be made through Specification Required Review"

I assume you mean "Specification Required review" (lowercase "review"). Sorry, I realize this is a very picky point, but by capitalizing "review" you make it appear as though you are referring to a policy named "Specification Required Review", which isn't a policy defined in RFC 8126.

[Ballot discuss]
Thanks for this document, it seems useful and I found it well-written. I have one blocking concern about the choice of Informational vs. PS, and one minor nit.

### DISCUSS

I agree with other reviewers that this appears to be most appropriately Proposed Standard and not Informational. Regrettably, the shepherd writeup doesn't explain the reason for this choice, so I am balloting DISCUSS. We could resolve this by changing the track, or by helping me understand why Informational is the right choice.

[Ballot comment]
### Section 7.2

"assignments in the 1-245 values are to be made through Specification Required Review"

I assume you mean "Specification Required review" (lowercase "review"). Sorry, I realize this is a very picky point, but by capitalizing "review" you make it appear as though you are a policy called "Specification Required Review", which isn't a policy defined in RFC 8126.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-zoneversion-08

Thank you for the work put into this document. The value for troubleshooting is clear and I would have ballot a YES (once my trivial DISCUSS is resolved) if this I-D was standard track rather than informational.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tim Wicinski for the shepherd's short write-up including the WG consensus even if the justification of the intended status could provide more information (informational seems a low bar, why not PS for such an important change).

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Wrong BCP 14

Easy to fix: the BCP 14 template is the old one.

[Ballot comment]

# COMMENTS (non-blocking)

## Intended status

While the IANA "DNS EDNS0 Option Codes (OPT)" registry does not require a standard track document, many other entries are PS, e.g., RFC 7828 for the edns-tcp-keepalive option. Why not aiming for this status? Especially when using normative BCP 14 language.

## Abstract

s/since the version and the data are provided atomically/since the version and the DNS answer are provided atomically/ ? Data being relatively vague.

## Section 1

Suggest repeating the RFC 5001 reference.

s/such as relational databases/such as replicated databases/ ?

`To accomodate these use cases, new ZONEVERSION types should be defined in future specifications` perhaps s/should/could/ ?

## Section 3.2

In `A name server MUST ignore invalid ZONEVERSION options` what is an "invalid" ZONEVERSION in this context? Related to this point, what should a server do when receiving the option with a non-zero length ?

## Section 7.1

Should https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11 be added ?

# NITS (non-blocking / cosmetic)

## Section 1

s/authoritative DNS severs to provide/authoritative DNS se*R*vers to provide/

s/distrubtion/distribution/

It seems that the I-D would benefit from a automated corrector pass ;-) I will stop doing this role

## Section 2.1

s/1 octet Label Count/1-octet Label Count/ ?

[Ballot comment]
idnits reports:

  ** The abstract seems to contain references ([RFC5001]), which it
    shouldn't.  Please replace those with straight textual mentions of the
    documents in question.

  -- Obsolete informational reference (is this intentional?): RFC 8499
    (Obsoleted by RFC 9499)

[Ballot discuss]
Just a few hopefully minor issues to talk about.

In section 3.2, why is NXDOMAIN not listed? When asking for "foobar.nohats.ca",
couldn't it be useful to get the zone version, if the nameserver is
authoritative for "nohats.ca" and has no delegation for "foobar.nohats.ca." ?

What should an authoritative nameserver return as zone version if it is
configured as authoritative nameserver but can't get the zone version (eg
because "no permission to read file")  One way would be to allow it to return
a zero length for ANY type and define that as an error condition.

It seems DNAMEs could lead to involving two or more zones the nameserver is
authoritative for. How should this be handled? Only use the first DNAME's
zone's version?

The type leaves no room for proprietary (or somehow encrypted) zone versions,
as the DE advise states:

        In particular the reference should state clear instructions for
        implementers about the syntax and semantic of the data

If you did not mean to exclude encrypted zone version data, perhaps clarify
the advise to the DE? Or are those deployments meant to use the
"local/experimental" use, in which case calling it "private use" might be
better?

Have you considered leaving a small initial space for "RFC Required" policy?
Eg 0-15 ?  With only 253 types available, I'd feel happier with that,
especially if this supports proprietary types.

Should implementers be warned not to blindly copy this EDNS(0)
options from the query of a DNS client onwards? Doing this could cause
amplification attacks if some server uses a non-SOA-SERIAL type with a
long length.

[Ballot comment]
      A name server SHOULD include zone version information for

Can this be rephrased as:

        When asked for a zone version, a responding name server SHOULD
        include zone version information for [...]

Just to avoid implementers from reading this and adding it when the DNS
client did not ask for it.


        The OPTION-LENGTH for this type MUST be set to 6 in responses.

Maybe say:

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

I was initially confused and assumed it was talking about what this document
calls VERSION, so alternatively instead of saying what the OPTION-LENGTH is,
perhaps say:

        The VERSION length for SOA-SERIAL MUST be four octets, resulting in
        the OPTION-LENGTH for this EDNS(0) type option to be set to 6.


My OCD triggers on these unbalanced parentices:

        ; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 (example.com.)")

(note it seemed to render badly in my browser, but copy&paste seemed to fix it again?)

The example dig command should have +norecurse :)

Why does the example contain an AUTHORITY SECTION for an AA answer
with data? Seems .com does that but other nameservers I tested do
not (eg nohats.ca or .nl). This makes it a bit unclear if the setting
of zoneversion requires that the Authority Section is included. Maybe
a clarifying note can be added? I assume this related to query minimalization?

[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-zoneversion-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S1.1

* Why is Informational the right track for something that defines a new RR?

  The use of 2119 (without 8174) without any further text noting its lack
  of relevance for an Informational document might imply that this should
  be on some other track?

  Seems like it should be PS (or Exp)?

  I debated whether or not this was DISCUSS-worthy... perhaps others will
  feel differently.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-zoneversion-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the DNS EDNS0 Option Codes (OPT) registry in the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

a single new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Name: ZONEVERSION
Status: Standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

Second, a new registry is to be created called the ZONEVERSION TYPE Values registry. The new registry will be located on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

The registry will be managed as follows:

Values 0-245: Specification Required
Values 246-254: Reserved for Local/Experimental Use - [ RFC-to-be ]
Value 255: Reserved for future expansion - [ RFC-to-be ]

There is a single initial registration in the new registry as follows:

ZONEVERSION TYPE: 0
Mnemonic: SOA-SERIAL
Reference: [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-06-11):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-zoneversion@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'The DNS Zone Version
(ZONEVERSION) Option'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-06-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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
  field from the Start Of Authority (SOA) resource record is a good
  example of a zone's version, and 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 and diagnostics since the version and the
  data 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 [RFC5001].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/



No IPR declarations have been submitted directly on this I-D.

(1) RFC is Informational, and this is the correct RFC type.

Technical Summary:

  The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS
  authoritative server to add an EDNS option in the answer of such
  query with a token field representing the version of the zone which
  contains the answered Resource Record ("RR"), such as the Start Of
  Authority ("SOA") serial field in zones when this number corresponds
  to the zone version.

Working Group Summary:

WG worked and collaborated on resolving any and all issues. There was working group Consensus.

Document Quality:

Document is of good quality. There are several implementations that have been
in use for some time now.

Personnel:

Document Shepherd: Tim Wicinski

Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
After the AD review, the authors added another author to address
editorial suggestions.
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11)  All Nits have been addressed

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18) There is one IANA registry created: "ZONEVERSION" registry, and the IANA
considerations describe the different methods to update the registry.

(19) N/A

(20) No Yang Necessary

(1) RFC is Informational, and this is the correct RFC type.

Technical Summary:

  The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS
  authoritative server to add an EDNS option in the answer of such
  query with a token field representing the version of the zone which
  contains the answered Resource Record ("RR"), such as the Start Of
  Authority ("SOA") serial field in zones when this number corresponds
  to the zone version.

Working Group Summary:

WG worked and collaborated on resolving any and all issues. No rough consensus.

Document Quality:

Document is of good quality. There are several implementations that have been
in use for some time now.

Personnel:

Document Shepherd:

Responsible Area Director:

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
After the AD review, the authors added another author to address
editorial suggestions.
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11)  All Nits have been addressed

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18) There is one IANA registry created: "ZONEVERSION" registry, and the IANA
considerations describe the different methods to update the registry.

(19) N/A

(20) No Yang Necessary

(1) RFC is Informational, and this is the correct RFC type.

Technical Summary:

  The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS
  authoritative server to add an EDNS option in the answer of such
  query with a token field representing the version of the zone which
  contains the answered Resource Record ("RR"), such as the Start Of
  Authority ("SOA") serial field in zones when this number corresponds
  to the zone version.

Working Group Summary:

WG worked and collaborated on resolving any and all issues. No rough consensus.

Document Quality:

Document is of good quality. There are several implementations that have been
in use for some time now.

Personnel:

Document Shepherd:

Responsible Area Director:

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
After the AD review, the authors added another author to address
editorial suggestions.
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11)  All Nits have been addressed

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18) There is one IANA registry created: "ZONEVERSION" registry, and the IANA
considerations describe the different methods to update the registry.

(19) N/A

(20) No Yang Necessary

Document was sent back to WG: https://mailarchive.ietf.org/arch/msg/dnsop/Mdl09rdnHBAKO-xCoX8XzBXM9lQ/

I was keeping it in PubReq, but it has now been long enough that I'm updating the DT to note that it is with the WG.

(1) RFC is Informational, and this is the correct RFC type.


Technical Summary:

  The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS
  authoritative server to add an EDNS option in the answer of such
  query with a token field representing the version of the zone which
  contains the answered Resource Record ("RR"), such as the Start Of
  Authority ("SOA") serial field in zones when this number corresponds
  to the zone version.


Working Group Summary:

WG worked and collaborated on resolving any and all issues. No rough consensus.

Document Quality:

Document is of good quality. There are several implementations that have been in use for some time now.

Personnel:

Document Shepherd:

Responsible Area Director:

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11) The following editorial nits were pointed out to the authors, who will update their document after hearing from the AD.

Section 2:

s/distingishes/distinguishes/

s/disambiguate such situation/disambiguates such a situation/

Section 8:

s/suited at such task/suited at such a task/


(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18) There is one IANA registry created: "ZONEVERSION" registry, and the IANA considerations describe the different methods to update the registry.

(19) N/A

(20) No Yang Necessary

(1) RFC is Informational, and this is the correct RFC type.


Technical Summary:

  The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS
  authoritative server to add an EDNS option in the answer of such
  query with a token field representing the version of the zone which
  contains the answered Resource Record ("RR"), such as the Start Of
  Authority ("SOA") serial field in zones when this number corresponds
  to the zone version.


Working Group Summary:

WG worked and collaborated on resolving any and all issues. No rough consensus.

Document Quality:

Document is of good quality. There are several implementations that have been in use for some time now.

Personnel:

Document Shepherd:

Responsible Area Director:

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11) The following editorial nits were pointed out to the authors, who will update their document after hearing from the AD.

Section 2:

s/distingishes/distinguishes/

s/disambiguate such situation/disambiguates such a situation/

Section 8:

s/suited at such task/suited at such a task/


(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18) There is one IANA registry created: "ZONEVERSION" registry, and the IANA considerations describe the different methods to update the registry.

(19) N/A

(20) No Yang Necessary