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. ...
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?
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?
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