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 -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
