On Thu, Mar 27, 2025 at 8:50 AM Petr Špaček wrote: > On 3/21/25 08:22, Marten Seemann wrote: > > Doesn't that contradict RFC 9715, Section 3.1, R.2? Setting DF=1 is how > > you prevent fragmentation. > > That's possible. RFC 9715 is aspirational info document, not a > real-world-battle-tested advice. See introduction: > > ... This document was originally intended to be a Best Current Practice, > but due to operating system and socket option limitations, some of the > recommendations have not yet gained real-world experience; therefore, > this document is Informational. ... >
Correct, and the reason that I brought the draft to DNSOP's attention is because one operating system and socket limitation that the RFC claims to exist -- i.e., that Linux does not permit setting DF=1 without also enabling traditional PMTUD per RFC 1191 -- in fact does not exist. More on this below. The actually important recommendation is R6 and R7: > R6. UDP requestors should drop fragmented DNS/UDP responses without IP > reassembly to avoid cache poisoning attacks (at the firewall function). > > R7. DNS responses may be dropped by IP fragmentation. It is recommended > that requestors eventually try alternative transport protocols. > > Is there an API for R6 these days? > None that I am aware of. > As for IP_PMTUDISC_PROBE - in DNS that's relevant mostly on server side. > > Quick recap of typical DNS paradigm: > - 1 very small UDP packet with one DNS request comes in > - it generates 1 potentially large UDP packet with response to this request > - no state is retained after the response is sent > > How exactly are the servers supposed to use IP_PMTUDISC_PROBE? > A Linux IPv4 responder can set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE in order to satisfy R2. Doing this will prevent source fragmentation and set the DF bit in outgoing packets and will disable the processing of ICMP "Fragmentation Needed" messages. Similarly, a Linux IPv6 responder can set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE to accomplish the same things for IPv6. Doing this will prevent source fragmentation and will disable the processing of ICMPv6 "Packet too Big" messages. The second paragraph under R2 says: For BSD-like operating systems, the IP Don't Fragment (DF) flag bit [RFC0791] can be used to prevent fragmentation. In contrast, Linux systems do not expose a direct API for this purpose [...] This is at best misleading, given that Linux provides exactly the desired effect with IP_PMTUDISC_PROBE or IPV6_PMTUDISC_PROBE. Thanks, Mike Heard > Petr Špaček > > > > > > On Fri, 21 Mar 2025 at 14:05, Ondřej Surý <ond...@isc.org > > <mailto:ond...@isc.org>> 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) > > ond...@isc.org <mailto: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 14:00, Marten Seemann <martenseem...@gmail.com > > <mailto:martenseem...@gmail.com>> 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ý <ond...@isc.org > > <mailto: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 <https:// > > lists.openwall.net/netdev/2014/02/26/4> > > > > > > Ondrej > > > -- > > > Ondřej Surý (He/Him) > > > ond...@isc.org <mailto: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 > > <mailto: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 <mailto: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 <mailto:dnsop@ietf.org> > > > > To unsubscribe send an email to dnsop-le...@ietf.org > > <mailto:dnsop-le...@ietf.org> > > > > > > > > > _______________________________________________ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org > > > -- > Petr Špaček >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
