Doesn't that contradict RFC 9715, Section 3.1, R.2? Setting DF=1 is how you prevent fragmentation.
On Fri, 21 Mar 2025 at 14:05, Ondřej Surý <[email protected]> wrote: > IP_PMTUDISC_PROBE sets DF=1, DNS needs the fragmentation happen > if it can't be avoided. Otherwise this breaks too many things too often. > > Ondrej > -- > Ondřej Surý (He/Him) > [email protected] > > My working hours and your working hours may be different. Please do not > feel obligated to reply outside your normal working hours. > > > On 21. 3. 2025, at 14:00, Marten Seemann <[email protected]> > wrote: > > > > RFC 9715, Section 3.1, R.2 says: > > > UDP responders should configure their systems to prevent fragmentation > of UDP packets when sending replies, provided it can be done safely. > > > > Why don't they use IP_PMTUDISC_PROBE? > > > > On Fri, 21 Mar 2025 at 13:57, Ondřej Surý <[email protected]> wrote: > > Most (all) DNS servers use IP_PMTUDISC_OMIT[1] on Linux which makes > sockets ignore PMTU information and send packets with DF=0, looks like the > draft is incomplete in this regard. > > > > The options is available since Linux 3.15. > > > > 1. https://lists.openwall.net/netdev/2014/02/26/4 > > > > Ondrej > > -- > > Ondřej Surý (He/Him) > > [email protected] > > > > My working hours and your working hours may be different. Please do not > feel obligated to reply outside your normal working hours. > > > > > On 21. 3. 2025, at 9:05, C. M. Heard <[email protected]> wrote: > > > > > > Greetings, > > > > > > The I-D "Controlling IP Fragmentation on Common Platforms," targeted > as an information RFC, was presented in a recent IETF 122 tsvwg session and > is under consideration for adoption in that working group. > > > > > > At least one of the findings reported therein has a bearing on > Recommendation R2 in Section 3.1 of RFC 9715: > > > Linux systems do not expose a direct API for this purpose and require > the use of Path MTU socket options (IP_MTU_DISCOVER) to manage > fragmentation settings. However, it is important to note that enabling IPv4 > Path MTU Discovery for UDP in current Linux versions is considered harmful > and dangerous. For more details, see Appendix C. > > > > > > This may already be out-of-date, given what I see in Section 3.1 of > the aforementioned draft: > > > PMTUD behavior is controlled via the IP_MTU_DISCOVER and > IPV6_MTU_DISCOVER socket options at the IPPROTO_IP and IPPROTO_IPV6 levels. > There are two closely related values: For IPv4, both IP_PMTUDISC_DO and > IP_PMTUDISC_PROBE enable setting the DF bit. For IPv6, both > IPV6_PMTUDISC_DO and IPV6_PMTUDISC_PROBE prevent fragmentation by the > sender.¶ > > > The difference between the former and the latter is that the former > instructs the kernel to process ICMP "Fragmentation Needed" messages, while > the latter does not.¶ > > > This point may be worth considering when and if RFC 9715 is updated > from Information to RFC. > > > > > > Thanks and regards, > > > > > > Mike Heard > > > > > > On Mon, May 6, 2024 at 6:59 AM Petr Špaček wrote: > > > Hello dnsop, > > > > > > Warren asked implementers to provide feedback on the current text, so > > > I'm doing just that. > > > [ ... ] > > > On 01. 03. 24 3:54, [email protected] wrote: > > > > Internet-Draft draft-ietf-dnsop-avoid-fragmentation-17.txt is now > available. > > > > It is a work item of the Domain Name System Operations (DNSOP) WG of > the IETF. > > > > > > > > Title: IP Fragmentation Avoidance in DNS over UDP > > > > Authors: Kazunori Fujiwara > > > > Paul Vixie > > > > Name: draft-ietf-dnsop-avoid-fragmentation-17.txt > > > > Pages: 14 > > > > Dates: 2024-02-29 > > > > > > > [ ... ] > > > > > > > R2. Where supported, UDP responders SHOULD set IP "Don't Fragment > flag (DF) bit" [RFC0791] on IPv4. At the time of writing, most DNS server > software did not set the DF bit for IPv4, and many operating systems' > kernels constraint make it difficult to set the DF bit in all cases. > > > > > > E.g. on Linux socket API does not expose DF bit directly. Application > > > can request DF bit to be turned on in outgoing packets but at the same > > > time this implicitly enables receipt and processing of unauthenticated > > > ICMP messages. These messages can be used to manipulate Path MTU > records > > > in the kernel and mount attacks misusing this technique. > > > _______________________________________________ > > > DNSOP mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
