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?
Thank you!
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
