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 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. 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: > "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. > /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., 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. > > ----------------------------- > ## 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. > ----------------------------- > ## 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. > > ----------------------------- > ## 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 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. > ----------------------------- > ## 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. > --------------------------------------------------------------------- > - > 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]
