Ballot for draft-ietf-dnsop-avoid-fragmentation
Yes
No Objection
No Record
Summary: Has enough positions to pass.
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". If what you want is "we really really want this but it cannot be done on every OS", then I think SHOULD instead of MUST is fine, but MAY seems too weak. R7. UDP requestors MAY drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. R8. DNS responses may be dropped by IP fragmentation. Upon a timeout, to avoid resolution failures, UDP requestors MAY retry using TCP or UDP with a smaller EDNS requestor's maximum UDP payload size per local policy. Same here. R7 and R8 are "recommendations" so I feel the MAY's should be SHOULDs. Otherwise the recommendation becomes "do whatever you MAY please", in which case why are these in the document? R9. Use a smaller number of name servers (13 may be too large) I would say "name server names" instead of "name servers", to avoid any ambiguity of anycast name servers operating under the same name. Eg the document is not saying "use less than 13 name servers", but it is saying "use less than 13 name server names" smaller than those usually used for RSA. smaller than those of equivalent cryptographic strength using RSA
# Internet AD comments for draft-ietf-dnsop-avoid-fragmentation-16 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S1 * "TCP avoids fragmentation by ..." TCP also benefits hugely from widespread support for MSS rewriting. If something like an "EDNS0 Payload Size rewriting" function was available and as widely deployed there might be a very different conversation to be had. No text changes necessary; just a random thought.
I support Rob's DISCUSS position.
Thanks for addressing my DISCUSS and Barry's remaining ARTART review point. I support Rob Wilton's DISCUSS position. Piling on a bit, in reference to: R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size to the RECOMMENDED size of 1400 or a smaller size. I think the "RECOMMENDED" here is just carrying forward a "RECOMMENDED" from someplace else. If that's correct, I suggest changing it to "recommended" or, if you want to be more precise, "... to the size recommended by RFCXXXX of 1400 or smaller." Now it's clear what the SHOULD is referencing, and you don't own the RECOMMENDED part here. I suggest defining "EMSGSIZE" in Section 2 to be the UNIX error code of the same name. Otherwise, we encounter it in Section 3.1 in a way that could mean it's an error code (which is how I think you intend it) or as a symbolic name for the path MTU size. Forwarded comments from Orie Steele, incoming ART Area Director: "Recommendations for zone operators and DNS server operators" * Define "large / small" better. "Protocol compliance considerations" * Would be nice to see reporting recommendations, perhaps that make the failure an internal cost for the failing component?... would not want a repeat of dmarc though.
Thank you to Donald Eastlake for his SECDIR review. Please review his proposed text on including clarifying language around the applicability of TSIG. I support Martin Duke and Rob Wilton’s DISCUSS positions. ** Section 7.2 This would indicate prior reliance upon IP fragmentation, which is universally considered to be harmful to both the performance and stability of applications, endpoints, and gateways. Is there a reference that can be cited to substantiate this “universal” position?
Thank you for this document, DNS is so important for the global Internet that a BCP is welcome. I am afraid that for several reasons I was unable to review correctly this document on time, mainly relying on Vladimír Čunát's DNS-dir review at https://datatracker.ietf.org/doc/review-ietf-dnsop-avoid-fragmentation-16-dnsdir-telechat-cunat-2023-12-27/ . Nevertheless, I support Rob's DISCUSS about the use of MAY/SHOULD about the IPv4 DF-bit in section 3.1; also, an assertion like `many OS kernel constraints make it difficult to set the DF bit` should be backed by a reference. I also find 'light' to rely on TCP MSS as it is set by the end points only, i.e., it can also leads to IPv4 fragmentation in the path (or IPv6 fragmentation by the kernel at the source). Section 3, does `These recommendations are intended for nodes with global IP addresses on the Internet` also cover the use of NAT/NPT when the requestor uses RFC 1918 addresses or ULA? In section 3.1: - R1 why not simply stating that there should be no IPv6 fragmentation ? Atomic fragments are now discouraged for IPv6 - R3 where is the packet size of 1400 coming from ? Some reasoning would be welcome (e.g., based on some measurements over the global Internet). Put at least a forward reference to the appendix. In section 4, R9: where is `13 may be too large` coming from ? Appendix `the authors' recommendation` is it a recommendation by the authors or by the IETF in an IETF stream document? -éric
# 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
Thanks for addressing my DISCUSS. Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for responding. (1) I support Rob's DISCUSS (and Paul's comment) about SHOULD/MAY. "do it unless the OS makes it impossible" is a typical use of SHOULD. (2) Section 3.1, R1 says that responders SHOULD omit the fragment header. Under what circumstances would it be reasonable to keep it?
Thanks for addressing my comments. Regards, Rob