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.
Gorry > On 31 Jan 2026, at 18:10, Tobias Fiebig <[email protected]> wrote: > > Hello Gorry, > > thanks again for your input. Please see comments below on how we are > addressing it. > > All changes are currently pending review in this PR: > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/81 > > I also included the added text in this mail, inline, below. > >> On Sat, 2026-01-31 at 16:28 +0100, Gorry Fairhurst wrote: >> ## Section 3.2: EDNS(0) size >> I do not really understand the requirement arising from: >> "Hence, DNS servers MAY also opt to set an EDNS(0) size of 1232 >> octets as suggested by the [DNSFlagDay2020] initiative." >> - I’m not a DNS expert, but please coulkd you explain what does this >> “MAY” >> permit relative to other options? >> RFC9715 recommends an EDNS(0) size of 1400 to avoid fragmentation. >> However, and EDNS(0) size of 1232 ensures that DNS packets have a >> maximum size of 1280, i.e., the minimum MTU in IPv6. >> The MAY here allows operators to follow either, i.e., 9715, or the >> more >> strict 1232, which is also the default in many implementations. >> >> GF: I am not sure this text does say this yet. >> >> I suggest that any final text needs to say exactly what is needed, >> recommended, allowed now and how this is changed from a previous RFC. >> I >> could start by suggesting something like: >> >> [RFC9715] describes using an EDNS(0) size of 1400 bytes. This >> document >> updates this recommendation to note that for some deployments it is >> beneficial for a client to use an EDNS(0) size of 1232 bytes. This >> size ensures that DNS response packets have a maximum size of 1280 >> bytes, i.e., the minimum MTU for IPv6 [RFC8200], which avoids IPv6 >> host >> fragmentation by the server. For clarity the present document >> specifically notes that clients MAY use an EDNS(0) size of 1232 >> bytes. >> This is current default in some current implementations. > > I picked up your text suggestion and rewrote the paragraph as follows: > > In general, DNS servers <bcp14>SHOULD</bcp14> follow <xref > target="RFC9715"/>, which provides additional guidance on preventing > fragmentation. <xref target="RFC9715"/> suggests setting an upper bound > for received EDNS(0) sizes of 1400 octets to avoid the need for > fragmentation. However, the <xref target="DNSFlagDay2020"/> initiative > suggests using an upper bound EDNS(0) size of only 1232 octets, which > is also adopted by most implementations. Setting the upper bound at > 1232 octets ensures that generated packets do not exceed 1280 octets, > i.e., the minimum MTU for IPv6 <xref target="RFC8200"/> which avoids > IPv6 host fragmentation by the server. Hence, for clarity, the present > document specifically notes that clients <bcp14>MAY</bcp14> use an > EDNS(0) size of 1232 octets as well. > > Additionally, e.g., as an additional precaution or because the DNS > implementation in use does not support limiting the effective EDNS(0) > size, DNS servers <bcp14>MAY</bcp14> opt to explicitly not rely on path > MTU discovery <xref target="RFC4821"/> or PLPMTUD <xref > target="RFC8899"/>. It can do so, for example, by setting > IPV6_USE_MIN_MTU=1 from <xref target="RFC3542"/> to avoid the need to > perform PMTU discovery. > >> [RFC 8200] “strongly recommended that IPv6 nodes implement Path MTU >> Discovery”, in order to discover and take advantage of path MTUs >> greater than 1280 bytes. When a transport protocol can use PMTU (or >> PLPMTUD [RFC8201] or Datagram PLPMTUD) [RFC4821][RFC8899] this SHOULD >> be used to determine an effective PMTU. >> >> When a server is unable to successfully determine an effective PMTU >> to use, the server SHOULD configure the maximum response size to >> avoid IPv6 host fragmentation or black-holing of packets larger than >> the actual PMTU. For TCP, this could restrict the used MSS, for >> example to either 1388 bytes [RFC9715]) or 1220 bytes (analogous to >> [DNSFlagDay2020]). >> >> I expect you may have better insight into the protocols, and I look >> forward to seeing a proposed revised text. > > I kept TCP and UDP separate here. Adapting your text, I changed the > text in the TCP subsection as follows: > > [RFC9715] does not provide explicit guidance on mitigating this > issue. > > [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. > performing PMTU (or > PLPMTUD [RFC8201] or Datagram PLPMTUD [RFC4821] [RFC8899]) may /may/could/ > 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 > 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. > > 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. >> ----------------------------- >> ## Section 3.2: >> "However, similar >> to the case of DNS-over-UDP, DNS-over-TCP may encounter MTU >> discards, especially on IPv6, if PMTUD does not work, if the >> MSS >> honored by the authoritative DNS server leads to IP packets >> exceeding the PMTU. " >> (a) I am unable to understand what is special here for IPv6, and I >> would appreciate if this can be explained. It might be if the MSS >> allows more than the minimum IPv6 MTU that this results in packet >> discard? However, I am not sure then what is meant by the “PMTU” is >> that the server PMTU, or the actual PMTU supported by the path? (Is >> there data that can be used to show the case?) >> The highlighting of IPv6 here is due to vocal concerns that packets >> requiring fragmentation and PMTUD for IPv6 are notably worse than for >> IPv4. I would be happy to remove the ", especially on IPv6,". >> >> "the PMTU" here refers to the actual PMTU supported by the path. >> GF: I think a rewrite of the sentence would improve this, "MTU >> discards" >> is not a phrase I know, so can we avoid that (or if needed, see if it >> can be carefully defined)? >> >> I suggest you define and use: "Effective PMTU" and define: Effective >> Path Maximum Transmission Unit (PMTU) is the largest IP packet size >> (in >> bytes) that can successfully traverse a network path from source to >> destination without requiring fragmentation. > > I aligned the terminology to 'effective PMTU', and added the definition > you suggested. > Great. That will help. >> /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? > cannot be returned to the sender, or if the size communicated in > these messages is incorrect, i.e., a middle-box alters packet size > on-path.Under these conditions, the MSS honored by the > authoritative DNS server leads to IP packets exceeding the > effective PMTU of the path taken by responses.In that case, > similar to the case of DNS-over-UDP, DNS resolution will time out > when the recursive DNS resolver did not receive a response in > time. > > >> >> ----------------------------- >> (b) What is the impact/prevalence of MSS Clamping in this case? >> MSS clamping is the suggested mitigation in the document, i.e., if we >> clamp the MSS to a value ensuring that packets do not exceed 1280, no >> MTU blackholes should occur. >> GF: OK. I note that MSS Clamping is TCP-only, and if there is a need >> to >> mention, then please explain this, e.g.: >> "MSS (Maximum Segment Size) Clamping is a router technique used to >> lower >> the maximum amount of data per TCP segment (the MSS) during the >> initial >> TCP handshake." > > I added the following text, see also above: > > 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. > Looks ok >> >> ----------------------------- >> ## Section 3.2: Transport Black Hole detection? >> "In that case, similar to the case of DNS- >> over-UDP, DNS resolution will time out when the recursive DNS >> resolver did not receive a response in time." >> - Several TCP stacks implement black-hole detection, would that >> influence the DNS result or not? >> Please see Mark's reply on this point. In DNS, standard blackhole >> detection exceeds the timeframe for a query to time out. >> >> GF: I think Mark's text was heading in a valuable exception to >> explain why DNS is a special case. Please do include text similar to >> this. > > The following text has been added, see also above: > > However, DNS is highly time-constraint, and performing PMTU (or > PLPMTUD [RFC8201] or Datagram PLPMTUD [RFC4821] [RFC8899]) may > 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], 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. > > Thanks I will check when the ID is published. >> ----------------------------- >> ## Section 3.2: What is the effect of MAY? >> "...Hence, DNS servers MAY set an MSS of no more than 1388 octets for >> TCP connections." >> (a) I suggest TCP admins can already advertise any valid MSS, what >> does this “MAY” change? (b) I did not find an explanation for the >> value of 1388, please cite where this is explained? (I also could not >> find any explanation in RFC 9715, so please explain the use of this >> reference). >> This MAY enables taking the same precautions as for UDP via capping >> the >> EDNS(0) size for TCP as well. RFC9715 suggests setting an EDNS0 size >> of >> 1400 (leading to packets of 1448 octets). Setting an MSS of 1388 >> should >> similarly lead to TCP packets of 1448 octets. >> >> GF:Could you please propose text that explains this that can replace >> the current text? (see suggestion above) > > The text above has been adjusted and adopted; As written above: > > 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]. > >> ----------------------------- >> ## 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? >> >> ----------------------------- >> ## Section 3.2: MAY opt to not rely on PMTU discovery >> "Additionally, DNS servers MAY opt to not rely on PMTU discovery. " >> - As above, a TCP server can be setup to not rely on PMTU, etc, but I >> don’t understand the need for a formal requirement to permit this. >> Please explain the requirement and what is the impact of other in- >> built mechanism that a TCP stack would normally use, such as black- >> hole detection? >> The benefit here is that this approach ensures that packets will not >> exceed PMTU. However, operators might see issues with settings this >> for >> DNS servers (as it may increase load). It, nevertheless is an option. >> Hence, the idea was to explicitly allow it with MAY, but not mandate >> it >> via SHOULD/MUST. >> >> GF: I agree. Could this be explained in the security considerations >> section? > > I would argue that this is sufficiently explained with the reference to > 8200's recommendation on PMTUD. However, in addition, the following > text was added to the security considerations: > > Preventing fragmentation according to the guidance in this document > may increase load on DNS servers, as more TCP fallbacks might be > required.While measurements have shown this to be in the range of Currently? … or is there evidence that this is always the case? > 3-5% of connections [DNSv6MTU], operators SHOULD monitor the actual > impact on their servers when implementing guidance from this document > to detect unexpected load increases early on. Seems good > >> ----------------------------- >> ## Section 4.1: MTU break >> The document speaks of an “MTU break”, but I could not find an >> explanation of what was intended. Please could you explain? >> We understand a link in a path whose MTU is smaller than the PMTU of >> the preceeding section of the path to be the point of an MTU break. >> We >> will add this to the terminology section. >> >> GF: Could the document avoid creating a new term? Please see earlier >> note on "effective PMTU", which is a more commonly used term. > > The term has been removed. > >> ----------------------------- >> ## RFC 9715 >> "Furthermore, similar to the guidance >> in [RFC9715], authoritative DNS servers MAY set an MSS of >> either >> 1388 (analogous to [RFC9715]) or 1220 (analogous to the >> [DNSFlagDay2020] suggestions) in TCP sessions carrying DNS >> responses." >> - See above the MAY does not seem to imply a requirement to do >> anything here, please explain what is being allowed/required. >> The may here is in place to allow setting either, while also not >> mandating this to be set. >> >> GF: See suggestion above. > > Again, see above on how this has been implemented by adopting the > suggestion. > Ok >> --------------------------------------------------------------------- >> - >> COMMENT: >> --------------------------------------------------------------------- >> - >> >> # COMMENTS (non-blocking) >> >> Please find below some non-blocking COMMENT points/nits (replies >> would be appreciated even if only for my own education). >> >> ## Section 3.2: I could not understand the "otherwise" in this: >> "Otherwise, if the protocol is not >> resilient to IP layer fragmentation related issues by default, >> the >> above guidance for TCP and UDP based connections SHOULD be >> applied >> analogously." >> - There is use of DNS over other transports and I do understand what >> is being called for by this requirement, please explain (and consider >> rephrasing?). >> This text has been added due to WG discussions highlighting the >> existence of other transports. I would personally like to improve the >> text here, but have been struggling to find a better formulation. If >> you can think of a better formulation, input would be greatly >> appreciated. >> >> What I'd want to say here is: >> >> "There may be new things we have not thought about yet. If these see >> issues with MTU blackholes, things should be done to limit the >> maximum >> packet size, similar to what we tried to do for TCP/UDP." >> >> GF: See above. > > I am currently unable to determine which above this refers to. Could > you please be more explicit w.r.t. the change you expect here, also > given other changes already implemented. > > > With best regards, > Tobias > > > -- > Dr.-Ing. Tobias Fiebig > T +31 616 80 98 99 > M [email protected] > Pronouns: he/him/his _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
