DNS Security Extensions (DNSSEC)
RFC 9364

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.

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)

# É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