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ý <ond...@isc.org> 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) > ond...@isc.org > > 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 <he...@pobox.com> 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, internet-dra...@ietf.org 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 -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
