DNSSEC Trust Anchor Publication for the Root Zone
draft-ietf-dnsop-rfc7958bis-06

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

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

IANA understands that, upon approval of this document, there is a single action which we must complete.

IANA understands that each time IANA produces a new trust anchor, it will publish that trust anchor using the format described in this document (upon its approval).

IANA may decide to delay the publication of a new trust anchor for operational reasons, for instance having a newly-created key in multiple facilities.

When a trust anchor that was previously published is no longer suitable for use, IANA will update the trust anchor document accordingly by setting a validUntil date for that trust anchor. The validUntil attribute that is added can be a date in the past or in the future, depending on IANA's operational choices.

IANA will continue to ensure that the IANA policies and procedures for how the cryptographic keys for the DNS root zone are managed (also known as "DNSSEC Practice Statements" or "DPSs") will be updated at https://www.iana.org/dnssec/procedures.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action 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-08-08):

From: The IESG
To: IETF-Announce
CC: benno@NLnetLabs.nl, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-rfc7958bis@ietf.org, suzworldwide@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNSSEC Trust Anchor Publication for the Root Zone) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNSSEC Trust Anchor
Publication for the Root Zone'
  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-08-08. 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 root zone of the Domain Name System (DNS) is cryptographically
  signed using DNS Security Extensions (DNSSEC).

  In order to obtain secure answers from the root zone of the DNS using
  DNSSEC, a client must configure a suitable trust anchor.  This
  document describes the format and publication mechanisms IANA uses to
  distribute the DNSSEC trust anchors.

  This document obsoletes RFC 7958.




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



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

Shepherd Write up 7958bis

(1)Publication of this document is requested as Informational. This is appropriate primarily because it describes guidelines and procedures that IANA follows for the publication of trust anchors for bootstrapping DNSSEC validation of signed zones, but doesn’t specify behavior for DNS software or operators. IANA makes the trust anchor available by a variety of mechanisms, as a helpful optimization for operators validating DNSSEC. There would be operational disruption if IANA procedures were changed without notice, but those procedures don’t create a standard.

The document obsoletes RFC 7958, which was published on the independent stream; it was submitted to the WG to get more rigorous review.

(2)Technical Summary:

The root zone of the Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC).

In order to obtain secure answers from the root or signed child zones of the DNS using DNSSEC, a client must configure a suitable trust anchor.  This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors.

Working Group Summary:

There was some concern expressed at the time of adoption that the document should go to the Independent Stream, since it documents established practices, deployed by IANA at their discretion. It wasn’t clear to everyone what added value would come from taking it through WG adoption and consensus. However, documenting established practices in Informational RFCs is nothing new for DNSOP, and consensus tends to be that clear, understandable documentation of such fixed “facts of life” helps real-world interoperability of the DNS. 

Document Quality:

The mechanisms described in this document are in daily use for distributing the DNSSEC root zone trust anchor for DNS operators across the Internet. 7958bis reflects experience gained since RFC 7958, published in 2016, including dropping distribution mechanisms that turned out to be less useful. In addition, 7958 was published on the Independent Stream, but 7958bis has been a WG document. It's clearly written, understandable, and technically accurate.

Personnel:

Who is the Document Shepherd? Suzanne Woolf
Warren Kumari is the Responsible Area Director


(3)The document has passed WGLC and looks ready to publish. It has been reviewed for both accuracy of technical detail, and clarity. The technical matters discussed are straightforward, the original draft was well-written, and the authors have been responsive to WG suggestions for edits.

(4) No concerns on reviews.

(5) No broader review needed.

(6) The “IANA Considerations” section of this document uses normative language to describe IANA procedures, which may be a little unusual in an Informational document. However, as written it conveys some attributes of IANA procedures on trust anchor publication that operators can rely on (“MUST”) and some others that may require more flexibility from a client trying to keep their root zone trust anchors up to date(“MAY”).

(7) No IPR to disclose.

(8) No IPR

(9) WG Consensus is solid. There were no objections at Last Call to advancing the document.

(10) No threats of appeal

(11) All nits addressed

(12) No formal review needed

(13) all references have been identified as either normative or informative

(14) All normative references are clear.

(15) There are no downward normative references

(16) This document will obsolete RFC 7958 and it is mentioned in the abstract, title page and introduction.

(17) See above on the IANA Considerations and the use of reserved words. There are no new protocol extensions, registries, or assigned values specified.

(18) There are no new IANA registries.

(19) N/A

(20) No Yang Needed

Shepherd Write up 7958bis

(1)Publication of this document is requested as Informational. This is appropriate primarily because it describes guidelines and procedures that IANA follows for the publication of trust anchors for bootstrapping DNSSEC validation of signed zones, but doesn’t specify behavior for DNS software or operators. IANA makes the trust anchor available by a variety of mechanisms, as a helpful optimization for operators validating DNSSEC. There would be operational disruption if IANA procedures were changed without notice, but those procedures don’t create a standard.

The document obsoletes RFC 7958, which was published on the independent stream; it was submitted to the WG to get more rigorous review.

(2)Technical Summary:

The root zone of the Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC).

In order to obtain secure answers from the root or signed child zones of the DNS using DNSSEC, a client must configure a suitable trust anchor.  This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors.

Working Group Summary:

There was some concern expressed at the time of adoption that the document should go to the Independent Stream, since it documents established practices, deployed by IANA at their discretion. It wasn’t clear to everyone what added value would come from taking it through WG adoption and consensus. However, documenting established practices in Informational RFCs is nothing new for DNSOP, and consensus tends to be that clear, understandable documentation of such fixed “facts of life” helps real-world interoperability of the DNS. 

Document Quality:

The mechanisms described in this document are in daily use for distributing the DNSSEC root zone trust anchor for DNS operators across the Internet. 7958bis reflects experience gained since RFC 7958, published in 2016, including dropping distribution mechanisms that turned out to be less useful. In addition, 7958 was published on the Independent Stream, but 7958bis has been a WG document. It's clearly written, understandable, and technically accurate.

Personnel:

Who is the Document Shepherd? Suzanne Woolf
Warren Kumari is the Responsible Area Director


(3)The document has passed WGLC and looks ready to publish. It has been reviewed for both accuracy of technical detail, and clarity. The technical matters discussed are straightforward, the original draft was well-written, and the authors have been responsive to WG suggestions for edits.

(4) No concerns on reviews.

(5) No broader review needed.

(6) The “IANA Considerations” section of this document uses normative language to describe IANA procedures, which may be a little unusual in an Informational document. However, as written it conveys some attributes of IANA procedures on trust anchor publication that operators can rely on (“MUST”) and some others that may require more flexibility from a client trying to keep their root zone trust anchors up to date(“MAY”).

(7) No IPR to disclose.

(8) No IPR

(9) WG Consensus is solid. There were no objections at Last Call to advancing the document.

(10) No threats of appeal

(11) All nits addressed

(12) No formal review needed

(13) all references have been identified as either normative or informative

(14) All normative references are clear.

(15) There are no downward normative references

(16) This document will obsolete RFC 7958 and it is mentioned in the abstract, title page and introduction.

(17) See above on the IANA Considerations and the use of reserved words. There are no new protocol extensions, registries, or assigned values specified.

(18) There are no new IANA registries.

(19) N/A

(20) No Yang Needed