Tobias,
Just a wee note to say the revised I-D has completed my review, and I have
cleared of my DISCUSS.
- thanks for the effort put into this work and for enabling better IPv6
networking!
Gorry
On 09/02/2026 12:45, Tobias Fiebig wrote:
Hello Gorry,
On Sat, 2026-01-31 at 18:46 +0100, Gorry (erg) wrote:
There are a lot of changes and this is heading in a direction that
will resolve some (or all), I will comment and then expect a revision
so I can check where this has reached.
Thanks. I reply to your points inline; The new revision has just been
posted for review:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-3901bis-12&url2=draft-ietf-dnsop-3901bis-13&difftype=--html
[RFC8200] strongly recommended that IPv6 nodes implement Path MTU
Discovery”, in order to discover and take advantage of path MTUs
greater than 1280 octets.Usually, when a transport protocol can
use PMTU (or PLPMTUD [RFC8201] or Datagram PLPMTUD [RFC4821]
[RFC8899]) this SHOULD be used to determine an effective PMTU.
However, DNS is highly time-constraint, and
.. probably the service benefits from low latency.
changed
performing PMTU (or
PLPMTUD [RFC8201] or Datagram PLPMTUD [RFC4821] [RFC8899]) may
/may/could/
changed
lead to DNS requests timing out before the effective PMTU can be
established by the server.Furthermore, most DNS messages fit
into less than 1280 octets [DNSv6MTU],
I would prefer to avoid that assertion, albeit true at this current
time. Is it possible to rephrase as “short messages benefit …”etc
I would argue that there is no direct benefit of short messages. DNS
usually having short messages--at the moment--is a result of what the
DNS does/how it is used.
I would suggest to, instead, clarify that this assertion is 'at the
time of writing'.
which means that the
benefits of being able to leverage a larger effective PMTU only
effect corner cases, e.g., requests for DNSKEY RRs.In turn,
though, due to the constraint time budget of DNS servers, this may
prevent resolution for these comparatively rare, yet critical,
cases all together.
Again, please consider turning this around to say the benefits where
messages are larger without judging which are going to be “rare” in
future.
I turned the text around, focusing on the time benefit:
Additionally, not having to rely on PMTUD benefits DNS' time budget, as
the time needed for PMTUD could already exceed the timeout budget for
DNS resolution, i.e., could prevent resolution for cases where PMTUD is
needed all together.
Hence, DNS servers SHOULD configure the maximum response size to
avoid fragmentation or on-path discarding of packets larger than
the effective PMTU. For TCP, this can be accomplished by
restricting
the used maximum segment size (MSS), either by the host limiting
the
MSS on its own, or by rewriting the MSS field in packets during a
TCP
handshake. Therefore, it is RECOMMENDED that DNS servers set an
MSS of
no more than 1388 octets for TCP connections.Similarly, aligned
with
the recommendations of the [DNSFlagDay2020] initiative, DNS servers
MAY ensure that a total packet size of 1280 octets is not exceeded
by setting an MSS of 1220 octets.Additionally, DNS servers MAY
accomplish the same effect by opting to not rely on PMTU
discovery, which will also implicitly set a corresponding MSS for
outgoing packets.It can do so, for example, by setting
IPV6_USE_MIN_MTU=1 from [RFC3542].
Please also check my comments relating to the general case, and then
specify tcp.
I aligned TCP and UDP more, following your comments.
/PMTUD does not work/ is too vague, is this if /PMTUD is not
supported by the path/ or something else?
I look forward to seeing revised text.
I tried to add more clarity here by providing examples:
A resolver can for various reasons also initiate connections via
TCP for resolution to an authoritative server. However, similar
to the case of DNS-over-UDP, DNS-over-TCP may encounter MTU
discards if PMTUD is not possible on a given path.This can
occur, for example, if PMTUD related messages are dropped, i.e.,
Is this:
Messages dropped or ICMP messages are dropped?
Clarified that this is about ICMP/ICMPv6.
Do you think that this needs informative references for ICMP/ICMPv6?
-----------------------------
## Section 3.2: Impact of other headers (why “MAY)
"DNS servers MAY ensure that a total packet
size of 1280 octets is not exceeded by setting an MSS of
1220
octets."
(a) I suggest this wording does not present a requirement,
perhaps
the "MAY" ought to be lower case "may" or "can". (b) Please
explain
why how this avoids a size of 1280 octets? (To me, the total
packet
size includes any other extension or encapsulation headers, and
these
could result in a packet greater than 1280 octets.) What use-case
was
intended?
This again follows the same rational as with RFC9715 for UDP, but
translated to TCP.
GF: I agree, adding that explanation would be useful.
That explanation should be in there as well, now:
Please note that, for TCP, the resulting packet's size may be
further
enlarged by additional fields in the TCP header being in use, and
these
MSS values assume a minimal TCP header.
Is that correct? Or does MSS consider this?
The MSS does not consider the TCP header, see:
https://www.rfc-editor.org/rfc/rfc9293#name-maximum-segment-size-option
I added a reference to 9293.
With best regards,
Tobias
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
