On Thu, Apr 17, 2025 at 1:23 AM Petr Špaček wrote:
>
> On 3/28/25 04:14, C. M. Heard wrote:
> > On Thu, Mar 27, 2025 at 8:50 AM Petr Špaček wrote:
> > On 3/21/25 08:22, Marten Seemann wrote:
> > 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.
>
> I agree this can be done, but I'm probably missing some important point.
>
> Let's say our responder is mad and tries to send DNS response inside
> 1600 byte UDP packet over Internet, with DF=1.
>
> Can you elaborate how this improved anything compared to DF=0?
I started this discussion to point out that statements in RFC 9715 to the
effect that Linux does not allow one to set DF=1 without also enabling
classical PMTUD are false. So let's please NOT assume that the responder
is mad, but that it wants to implement RFC 9715.
Recall that RFC 9715 says:
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, the network MTU value configured
by the knowledge of the network operators, and the RECOMMENDED
maximum DNS/UDP payload size 1400. For more details, see
Appendix A.
Based on that, what a responder should do if it can't compose a UDP
response whose size meets the above limits -- which a value of 1600 bytes
does not -- is to truncate the response to the size recommended in R3 and
set the TC bit to tell the requestor to retry with TCP (or perhaps another
protocol such as QUIC, if that is known to be available).
I am aware that the consensus for RFC 9715 was rough and not everyone in
DNSOP agrees with its recommendations. Nevertheless, my understanding is
that it represents what the WG settled on for the first cut at an
aspirational BCP-to-be someday as more experience is obtained.
Thanks,
Mike Heard
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
