On 14/08/2025 08:22, Joe Abley wrote:
Hi Philipp,
On 13 Aug 2025, at 22:49, Philipp S. Tiesel <[email protected]> wrote:
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.
RFC 4821 and RFC 8899 rely on either session state existing between the sender
and receiver, or the opportunity to send probe packets, or both. How is this
applicable to the stateless transmission of a DNS response over IPv6 and UDP?
I think we need to carefully explain what we mean as "UDP".
Transport-layer fragmentation is potentially more useful: be it over TCP
or UDP as a Datagram service: as in draft-ietf-tsvwg-udp-options (when
supported). Or when a session-oriented transport works over UDP, as in
QUIC, or we choose TCP.
... Obvious: (1) Both client and server need to choose to use this. (2)
Sender has to choose the size.
I am not aware of a mechanism that would allow a DNS response that requires
fragmentation somewhere on the path away from the sender ever to be received.
Unless such a mechanism exists, I don't see why SHOULD NOT is the right answer
here -- it seems clear that it's a MUST NOT. If a plausible mechanism is
developed in the future, the restriction could be relaxed for those who choose
to implement it.
Perhaps the problem here is that the prescription above is too general, and
that different transports have different characteristics.
For UDP over IPv6: MUST NOT rely on pMTUd, MUST use RFC 3542
I think "rely" here is part of your argument, alas I think PMTUD needs
to be seen as best effort: PTB messages are blocked many places and can
have other problems. So PMTUD is only "safe" if combined with another
method - either a black hole detection method (e.g., that drives down
the PMTU when there is no reponse); or a probing method (such
as PLPMTUD) which requires at least a sequence of probe packets to be
tracked).
Part of what is recommeneded depends on what is intended by the term
"UDP", so clarifying this as a datagram service, likely this is correct.
For UDP over IPv4: SHOULD NOT rely on pMTUd, seems reasonable, fragmentation at
least works even if it has undesirable characteristics
For stateful transports like TCP, DoT, DoH, DoQ: I think pMTUd is probably
fine, especially for long-held sessions over which many messages are exchanged
where the cost of fragmentation can be amortised over the lifetime of the
session.
If you layer a transport over UDP (QUIC, UDP-Options, etc)a and below
DNS, UDP can be used as in RFC 8899. This will work for a session, but
not for individual messages sent in datagrams (because there is no time
to probe or do black-hole detection).
TCP does fragmentation - so you can still send big messages in lots of
smaller TCP segments. For TCP, the general practice of selecting a small
server MSS, or using MSS-clamping in network equipment generally
prevents you ever using PMTUD to discover a larger PMTU. PLPMTUD for
TCP ought to have been usable, but as far as I know there is no working
version in use.
I see QUIC as similar to TCP, except that MSS-clamping is not posible,
and therefore DPLPMTUD could be used to grow the packet size - providing
either your path is stable, or you have time to probe and find out what
works. I'd like to hope that this provides some pathway for evolution of
the packet size.
Joe
Gorry
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
