Lars Eggert has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-16: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-dnsop-avoid-fragmentation-16 CC @larseggert Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/VBI2ri6JwD9TEPjcxKBi828dVs4). ## Comments ### Paragraph 2 ``` IP Fragmentation Avoidance in DNS ``` Title should clarify this is for DNS over UDP. ### Section 1, paragraph 5 ``` This document specifies various techniques to avoid IP fragmentation of UDP packets in DNS. ``` Really wish that this BCP made a much stronger recommendation for DNS over TCP. ### Section 3.1, paragraph 0 ``` 3.1. Recommendations for UDP responders ``` I find myself agreeing with other ballots on these recommendations. Will refrain from duplicating them (and also from holding another DISCUSS based on them.) ### Section 3.1, paragraph 3 ``` At the time of writing, most DNS server software did not set the DF bit for IPv4, and many OS kernel constraints make it difficult to set the DF bit in all cases. Best Current Practice documents should not specify what is currently impossible, so R2, which is setting the DF bit, is "MAY" rather than "SHOULD". ``` Maybe I'm familiar with different kernels, but all the ones I am familiar with (except for some IoT platforms) readily offer socket options to set DF (and prevent stack fragmentation in v6). ### Section 3.1, paragraph 3 ``` R3. UDP responders SHOULD compose response packets that fit in the minimum of the offered requestor's maximum UDP payload size [RFC6891], the interface MTU, and the RECOMMENDED maximum DNS/UDP payload size 1400. ``` Why SHOULD, i.e., when would it ever be OK to do this? Also, where does the 1400 byte value come from (magic constant?) ### Section 3.1, paragraph 3 ``` R5. UDP responders SHOULD limit the response size when UDP responders are located on small MTU (<1500) networks. ``` Limit *to what*? ### Section 4, paragraph 0 ``` 4. Recommendations for zone operators and DNS server operators ``` I find it somewhat questionable to recommend changes in how DNS is being operated just to cater to UDP needing to remain a viable transport. (I realize I may be an outlier here.) ## 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 Document references `draft-ietf-dnsop-svcb-https`, but that has been published as `RFC9460`. ### Grammar/style #### "Appendix B.", paragraph 3 ``` fter two UDP timeouts, BIND 9 will fallback to TCP. C.2. Knot DNS and Knot R ^^^^^^^^ ``` The word "fallback" is a noun. The verb is spelled with a space. ## 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
