Last Call Review of draft-ietf-dnsop-avoid-fragmentation-15
review-ietf-dnsop-avoid-fragmentation-15-secdir-lc-eastlake-2023-10-28-00
review-ietf-dnsop-avoid-fragmentation-15-secdir-lc-eastlake-2023-10-28-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with Issues. I debated with myself as to whether the things that were bothering me about this draft were small issues or big nits. I ended up deciding that they were issues, although it might just be me. The goal of this Best Current Practice draft is to, as the title says, avoid fragmentation. This is for better security over UDP and better efficiency over TCP for DNS. Security -------- I don't understand why R2 is not a SHOULD now. Please consider moving Appendix A into the Security Considerations Section. I think Appendix A is almost all Security Considerations. Other Issues ------------ My first problem is with the first sentence in the abstract. The mere existence of EDNS0 doesn't "enable" large responses. There seems to be a lot missing in this sentence. I suggest something like "The widely deployed EDNS0 feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity which supports the sending of large UDP responses by a DNS server." Similar problem in the first paragraph of the Introduction although split over multiple sentences. A Best Current Practice document should specify things, not propose them. The first two occurrences of "propose" in this document should be changed to "specify" and the Section 3 title should be changed to "How to avoid IP fragmentation in DNS". Other occurrences of "propose", which are all in Appendices, are OK. In Section 3, why are R2 and R4 only "MAY"? What not "SHOULD"? In Section 3, R3, for clarity, suggest inserting "minimum of" so it would start with "UDP responders SHOULD compose response packets that fit in the minimum of the ..." Section 4: Not all large responses are the result of zone configuration. For example, queries may use the TYPE * (ALL). Wording should be something like "Large DNS responses are typically the result of zone configuration." Appendix D: It is unusual to have lots of details of particular implementations in a BCP. This information will become out of date. Should there be an RFC Editor comment to remove this appendix before publication? Nits ---- According to the nits checker: the RFC 2119 boilerplate has an error, and draft-ietf-dnsop-glue-is-not-optional has been published as RFC 9471 so the reference should be updated. Suggest eliminating the Section 5.1 header and changing the Section 5. title to "Protocol compliance considerations". Suggest changing Section 6 to be "This document requests no IANA actions." Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com