DNS Security Extensions (DNSSEC)
Note: This ballot was opened for revision 05 and is now closed.
Comment (2022-10-17 for -05) Sent
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.
(was Discuss) Yes
Comment (2022-10-19 for -05) Sent for earlier
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)
Comment (2022-10-18 for -05) Sent
# É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
(was Discuss) No Objection
Comment (2022-10-25) Sent for earlier
# 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
Comment (2022-10-20 for -05) Sent
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.
Comment (2022-10-17 for -05) Sent
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
Comment (2022-10-17 for -05) Sent
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.
Comment (2022-10-19 for -05) Sent
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.
Alvaro Retana Former IESG member
No Objection (2022-10-20 for -05) Not sent
I support Lars' DISCUSS.