DNS Security Extensions (DNSSEC)
RFC 9364

Received changes through RFC Editor sync (created alias RFC 9364, changed abstract to 'This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others.  One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC.  This document does not update any of those RFCs.  A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice.  A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.', changed pages to 10, changed standardization level to Best Current Practice, changed state to RFC, added RFC published event at 2023-02-14, changed IESG state to RFC Published, created alias BCP 237)

[Ballot comment]
# GEN AD review of draft-ietf-dnsop-dnssec-bcp-05

CC @larseggert

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/TNMpPSf36E8i5Nt96FoRSlbjPFA).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC2535]` to `RFC2535`, which was obsoleted by `RFC4033`,
`RFC4034`, and `RFC4035` (this may be on purpose).

Reference `[RFC2065]` to `RFC2065`, which was obsoleted by `RFC2535` (this may
be on purpose).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
After IESG discussion, I'm updating my comment:

I support Lars' DISCUSS.  What's curious here is that this seems to be trying to elevate the status of DNSSEC without actually doing that.  It feels like the wrong way to go about it.  But maybe there are some precedents here I don't know about.  I'm happy to be guided if there's history I'm missing.

[Ballot comment]
I support Lars' DISCUSS.  What's curious here is that this seems to be trying to elevate the status of DNSSEC without actually doing that.  It feels like the wrong way to go about it.  But maybe there are some precedents here I don't know about.  I'm happy to be guided if there's history I'm missing.

[Ballot discuss]
# GEN AD review of draft-ietf-dnsop-dnssec-bcp-05

CC @larseggert

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/TNMpPSf36E8i5Nt96FoRSlbjPFA).

## Discuss

### "Abstract", paragraph 1
```
    This document describes the DNS security extensions (commonly called
    "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of
    others.  One purpose is to introduce all of the RFCs in one place so
    that the reader can understand the many aspects of DNSSEC.  This
    document does not update any of those RFCs.  Another purpose is to
    move DNSSEC to Best Current Practice status.
```
I don't understand what "move DNSSEC to Best Current Practice status" means in
terms of the standards track. I'm all for advancing the RFC set that makes up
DNSSEC along the standards track, but BCP it not part of that track. Publishing
a BCP that normatively references some DNSSEC RFCs isn't doing anything in terms
of moving them forward.

### Section 1.1, paragraph 2
```
    The DNSSEC set of protocols is the best current practice for adding
    origin authentication of data in the DNS.  To date, no standards-
    track RFCs offer any other method for such origin authentication of
    data in the DNS.
```
Just because no other standards track RFCs compete with DNSSEC does not mean it
is a BCP. A BCP is something else, i.e. "The BCP subseries of the RFC series is
designed to be a way to standardize practices and the results of community
deliberations." [RFC2026]

### Section 1.1, paragraph 1
```
    However, this low level of implementation does not affect whether
    DNSSEC is a best current practice; it just indicates that the value
    of deploying DNSSEC is often considered lower than the cost.
```
Protocols aren't BCPs. HTTP isn't the "best current practice" for transporting
HTML either.

[Ballot comment]
## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC2535]` to `RFC2535`, which was obsoleted by `RFC4033`,
`RFC4034`, and `RFC4035` (this may be on purpose).

Reference `[RFC2065]` to `RFC2065`, which was obsoleted by `RFC2535` (this may
be on purpose).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Old DISCUSS (resolved by Paul H in github, pending revised ID)


Since draft-ietf-dnsop-rfc5933-bis is in IETF Last Call now, I think it is worth waiting on and updating this text:

  The GOST signing algorithm [RFC5933] was also adopted, but
  has seen very limited use, likely because it is a national algorithm
  specific to a very small number of countries.

To add a reference that RFCXXX updates the GOST algorithms for DNSSEC (but that it is uncertain at this point whether it will be widely adopted)

I could be convinced for this document to not wait, but then I do think this paragraph should state that it is NOT RECOMMENDED to implement RFC5933 since the underlying GOST algorithms have been deprecated by its issuer.



  One purpose is to introduce all of the RFCs in one place so
  that the reader can understand the many aspects of DNSSEC.  This
  document does not update any of those RFCs.  Another purpose is to
  move DNSSEC to Best Current Practice status.

I think another purpose not mentioned, which for me was a main motivator for this document, is to provide a single RFC reference for other documents that want to point to "DNSSEC" using a single reference instead of referring to the 3 core components (in an incomplete way)

  More than 15 years after the DNSSEC specification was published, it
  is still not widely deployed.  Recent estimates are that fewer than
  10% of the domain names used for web sites are signed, and only
  around a third of queries to recursive resolvers are validated.

What is the value of this paragraph? You wouldn't want to have a single IPv6 reference
RFC say this either :)

This document will be "the reference RFC" for a long time. It should not have
dated/outdated statistics in it.

  However, this low level of implementation does not affect whether
  DNSSEC is a best current practice

I don't think the level of implementation is low. It is actually quite high. Practically all
DNS software implements it. I think you meant deployment ?



NITS:

  which algorithms recursive resolver operators should or should not
  validate.

change to:

  which algorithms recursive resolver operations should or should not
  use for validation

(the algorithms themselves are not validated)

[Ballot comment]
I'm not sure how I feel about this being a BCP.  If it's more of an index to other DNSSEC standards documents, shouldn't it be Informational?  If the core documents are Standards Track, doesn't that mean DNSSEC is a (proposed) standard, not a BCP?  Can it be both?  If we ever promote the core documents to full standard, what becomes of this document's status?

Maybe there are some precedents here I don't know about.  I'm happy to be guided if there's history I'm missing.

[Ballot comment]
Thanks for working on this specification. I think a BCP would be helpful.

I have two minor comments -

- Section 1: if we can elaborate on "modern DNSSEC" that would be more useful to understand the characteristic of the modern DNSSEC rather just calling it modern.
- Section 1.2: it says - "reading the RFCs should also include looking for the related errata", may be it better to clarify if we mean all the erratas with all the states or just verified ones.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dnssec-bcp-05
CC @evyncke

Thank you for the work put into this document. It is short and contains a lot of useful information.

Please find below some non-blocking COMMENT points .

Special thanks to Tim Wicinski for the shepherd's detailed write-up including WG consensus and justification of the intended status.

Please note that Nicolai Leymann is the DNS directorate reviewer (at my request) and the review status is 'ready':
https://datatracker.ietf.org/doc/review-ietf-dnsop-dnssec-bcp-05-dnsdir-telechat-leymann-2022-10-14/

Please note that Sheng Jiang is the Internet directorate reviewer (at my request) and the review status is 'ready':
https://datatracker.ietf.org/doc/review-ietf-dnsop-dnssec-bcp-05-intdir-telechat-jiang-2022-10-16/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### BCP Status ?

In the light of Geoff Huston's https://stats.labs.apnic.net/dnssec?s=Validating&d=Auto&w=30 , promoting DNSSEC to BCP seems to be wishful thinking (alas :-( ...). No need to reply or to restart a debate.

An informational document would probably be better suited.

### Section 2

`"DNSSEC" means the protocol initially defined in [RFC4033], [RFC4034], and [RFC4035].` The use of 'initially' is weird for a third generation, suggest to remove it.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]

Since draft-ietf-dnsop-rfc5933-bis is in IETF Last Call now, I think it is worth waiting on and updating this text:

  The GOST signing algorithm [RFC5933] was also adopted, but
  has seen very limited use, likely because it is a national algorithm
  specific to a very small number of countries.

To add a reference that RFCXXX updates the GOST algorithms for DNSSEC (but that it is uncertain at this point whether it will be widely adopted)

I could be convinced for this document to not wait, but then I do think this paragraph should state that it is NOT RECOMMENDED to implement RFC5933 since the underlying GOST algorithms have been deprecated by its issuer.

[Ballot comment]

  One purpose is to introduce all of the RFCs in one place so
  that the reader can understand the many aspects of DNSSEC.  This
  document does not update any of those RFCs.  Another purpose is to
  move DNSSEC to Best Current Practice status.

I think another purpose not mentioned, which for me was a main motivator for this document, is to provide a single RFC reference for other documents that want to point to "DNSSEC" using a single reference instead of referring to the 3 core components (in an incomplete way)

  More than 15 years after the DNSSEC specification was published, it
  is still not widely deployed.  Recent estimates are that fewer than
  10% of the domain names used for web sites are signed, and only
  around a third of queries to recursive resolvers are validated.

What is the value of this paragraph? You wouldn't want to have a single IPv6 reference
RFC say this either :)

This document will be "the reference RFC" for a long time. It should not have
dated/outdated statistics in it.

  However, this low level of implementation does not affect whether
  DNSSEC is a best current practice

I don't think the level of implementation is low. It is actually quite high. Practically all
DNS software implements it. I think you meant deployment ?



NITS:

  which algorithms recursive resolver operators should or should not
  validate.

change to:

  which algorithms recursive resolver operations should or should not
  use for validation

(the algorithms themselves are not validated)

[Ballot comment]
Thank you to Catherine Meadows for the SECDIR review.

** Section 1.1
  Recent estimates are that fewer than
  10% of the domain names used for web sites are signed, and only
  around a third of queries to recursive resolvers are validated.

Since this is a point-in-time measurement, this document would age better with a reference to these figures.

** Section 1.1
  However, this low level of implementation does not affect whether
  DNSSEC is a best current practice; it just indicates that the value
  of deploying DNSSEC is often considered lower than the cost.
  Nonetheless, the significant deployment of DNSSEC beneath some top-
  level domains (TLDs), and the near-universal deployment of DNSSEC for
  the TLDs in the DNS root zone, demonstrate that DNSSEC is suitable
  for implementation by both ordinary and highly sophisticated domain
  owners.

Editorial style.  The first sentence states that most of the Internet doesn’t see the value of DNSSEC relative to the cost.  The second sentence suggests that it is “suitable for … ordinary domain owners.”  I might have used the word “applicable for …” because for me, part of suitability is that it is that the cost is acceptable for many in the target population (which the first sentence suggests it is not)

** Section 2.
  Earlier iterations have not been deployed on a significant scale.

Consider if the text can qualify the differences in scale from the one posed on Section 1.1 (i.e., <10% of the domain).

** Section 3.
  Cryptography improves over time, and new algorithms get adopted by
  various Internet protocols. 

Consider rephrasing this statement.  Overtime, existing cryptographic algorithms typically weaken as computing power and new cryptoanalysis emerges.

[Ballot comment]
Thanks, Paul, for this useful and easy-to-read document. Thanks also to Tim Wicinski for putting in the work to build the excellent evaluation table.

## COMMENT

### Section 1

~~~
  This document lists many (but not all) of the RFCs that should be
  considered by someone creating an implementation of, or someone
  deploying, modern DNSSEC.
~~~

Why not list all the ones that should be considered? That seems like a bit of a tease! But maybe (probably?) you meant that the list is not guaranteed comprehensive, in which case perhaps something like this

~~~
  This document lists RFCs that should be
  considered by someone creating an implementation of, or someone
  deploying, modern DNSSEC. Although an effort was made to be
  thorough, it would be unwise for the reader to assume this list
  is comprehensive.
~~~

could be used.

But maybe you meant exactly what you wrote, in which case, OK.

[Ballot comment]
Thanks for this document, I think that it is helpful, and was easy to read.

More generally, out of scope for this work, it would be nice to an updated document describing all the core aspects of DNS, that would probably be helpful to the wider community.  I appreciate that such an undertaking would be a significant amount of less appealing work though ...

Regards,
Rob

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

The IANA Functions Operator has reviewed draft-ietf-dnsop-dnssec-bcp-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-05):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dnssec-bcp@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Security Extensions (DNSSEC)) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Security Extensions
(DNSSEC)'
  as Best Current Practice

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 2022-10-05. 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


  This document describes the DNS security extensions (commonly called
  "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of
  others.  One purpose is to introduce all of the RFCs in one place so
  that the reader can understand the many aspects of DNSSEC.  This
  document does not update any of those RFCs.  Another purpose is to
  move DNSSEC to Best Current Practice status.

  This document is currently maintained at
  https://github.com/paulehoffman/draft-hoffman-dnssec.  Issues and
  pull requests are welcomed.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5702: Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc4034: Resource Records for the DNS Security Extensions (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc4033: DNS Security Introduction and Requirements (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) (Proposed Standard - Internet Engineering Task Force (IETF))

# Document Shepherd Write-Up for draft-ietf-dnsop-dnssec-bcp

In doing the write for this document, the shepherd went and searched
for all RFCs which had DNSSEC in the title or abstract, along with a few
others and built this table to make sure this BCP was capturing all
relevant information.

https://gist.github.com/moonshiner/0746776f2351ae9c8e3edb3373ee39c6

## Document History

1. Document was not considered in any other WG.

2. There was no controvesy about this document that caused the WG to not adopt.

3. There are no threats of appeals, or extreme discontent.

4. There are significant number of DNSSEC implemnetations currently.

## Additional Reviews

5. Document contents don't interact with technologies in other working groups or
  organizations.

6. Document does not require any formal expert reviews.

7.  No Yang module

8.  This document contains no sections which require any automated checks.

## Document Shepherd Checks

9.  This document is needed, it is clearly written and complete, and ready for the
    Area Director.

10. The shepherd feels any area reviews would be best served by the ops and sec areas.

11. This document is requested as a Best Current Practice.
    This is the proper type for this document.
    The Datatrack reflects this.

12. Authors are aware of the IPR disclosures; and there are no such IPR disclosures.

13. The author has shown their willingness to be listed as such.

14. There are no I-D nits in this document.

15. All informative references are correct and do not need to be normative.

16. All normative references are freely available.

17. There are no normative downward references

18. All normative references have been published.

19. This document will not change the status of existings RFCs.

20. Review of the IANA considerations section is consistent with this document.
    It identifies existing registries and the RFCs they are defined in.

21. No new IANA Registries

# Document Shepherd Write-Up for draft-ietf-dnsop-dnssec-bcp

In doing the write for this document, the shepherd went and searched
for all RFCs which had DNSSEC in the title or abstract, along with a few
others and built this table to make sure this BCP was capturing all
relevant information.

https://gist.github.com/moonshiner/0746776f2351ae9c8e3edb3373ee39c6

## Document History

1. Document was not considered in any other WG.

2. There was no controvesy about this document that caused the WG to not adopt.

3. There are no threats of appeals, or extreme discontent.

4. There are significant number of DNSSEC implemnetations currently.

## Additional Reviews

5. Document contents don't interact with technologies in other working groups or
  organizations.

6. Document does not require any formal expert reviews.

7.  No Yang module

8.  This document contains no sections which require any automated checks.

## Document Shepherd Checks

9.  This document is needed, it is clearly written and complete, and ready for the
    Area Director.

10. The shepherd feels any area reviews would be best served by the ops and sec areas.

11. This document is requested as a Best Current Practice.
    This is the proper type for this document.
    The Datatrack reflects this.

12. Authors are aware of the IPR disclosures; and there are no such IPR disclosures.

13. The author has shown their willingness to be listed as such.

14. There are no I-D nits in this document.

15. All informative references are correct and do not need to be normative.

16. All normative references are freely available.

17. There are no normative downward references

18. All normative references have been published.

19. This document will not change the status of existings RFCs.

20. Review of the IANA considerations section is consistent with this document.
    It identifies existing registries and the RFCs they are defined in.

21. No new IANA Registries