Hi, I certainly agree that we should not block ourselves from better transport in the future, therefore it is important that the following SHOUDs are SHOULDs and definitely no MUSTs:
DNS servers SHOULD NOT relay on path MTU discovery or PLPMTUD (RFC4821/RFC8899) but SHOULD use IPV6_USE_MIN_MTU=1 from RFC 3542 to avoid the need to do path MTU discovery. With the current believed state of ICMP / MTU blackholing, I fear it is the best we can get working right now for UDP, hopefully we can reise this in 10 years and increase the recommendation. With regards to TCP & QUIC… I am unsure whether PLPMTUD has any chance with short-lived flows to discover anything. Perhaps we should as @Gorry for his expert opinion on that one… AVE! Philipp > On 13. Aug 2025, at 12:01, Joe Abley <[email protected]> > wrote: > > Hi Paul, > > It seems to me that there are only two approaches here: > > (a) standardise a way for DNS messages over UDP/IPv6 to be retained after > sending in some predictable fashion so that they can be fragmented at source > if necessary, or > > (b) specify that when sending a DNS message over stateless transport where > path MTU discovery is expected (over UDP over IPv6) the sender of the > response MUST NOT send a message so large that fragmentation is possible. > > Personally I think that (a) is simply reinventing the overhead of using > stateful transports. Focusing on a wholesale move to those transports and > giving up on large UDP messages is better than trying to bolt state as an > afterthought onto UDP. > > > Joe > >> On 13 Aug 2025, at 11:14, Paul Vixie <[email protected]> >> wrote: >> >> Are we using the recent fragmentation avoidance rfc so soon? Mark, the >> locally witnessed network MTU does not completely predict the full path MTU. >> Plpmtud is and should remain in scope. Let's not close off a way to reach >> reasonable datagram sizes in the future. Every 10x in speed should someday >> show up as 3.333x in packet rate and 3.333x in packet size. We are using >> tinygrams in comparison. What we do today will affect the possibilities >> later. Vixie >> Paul Vixie >> Aug 5, 2025 03:30:00 Mark Andrews <[email protected]>: >> >> draft-ietf-dnsop-3901bis-03 states: >> >> If the requesting resolver is unable to process fragments, or if >> fragments are filtered on-path, resolution will fail over UDP. >> These issues are more prevalent for IPv6, as it no longer allows >> on-path hosts to fragment packets. Therefore, working Path MTU >> Discovery (PMTUD) is essential for IPv6 DNS-over-UDP packets to be >> fragmented to a size that allows them to traverse all segments on >> a path. >> >> This is not factually correct. There is NO requirement to perform PMTUD >> at all in a DNS server over IPv6. For UDP you just fragment at network >> MTU in the sending node at network MTU. This can be achieved by using >> IPV6_USE_MIN_MTU=1 socket option from RFC 3542 or using an interface that >> is configured with a MTU that matches the network MTU. For TCP you use >> the socket option TCP_MAXSEG to set the MSS to the network MTU. >> >> Both of these options have been used for years in nameservers and avoid >> response losses caused by attempting PMTUD itself. >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: [email protected] >> >> _______________________________________________ >> DNSOP mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> _______________________________________________ >> DNSOP mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
