On 22/01/2026 09:17, Tobias Fiebig wrote:
Hello Gorry,
thank you for your review. Please find responses in-line.
This is slightly complicated because I don't understand the current text
in various places, but I do expect we can converge quickly on some new
text. See text marked: GF below.
Gorry
---------------------------------------------------------------------
DISCUSS:
---------------------------------------------------------------------
Thank for writing this document and the work that went into
documenting DNS
IPv6 Transport and thank you to Martin Duke for a TSV-ART review. I
am not a
DNS expert, but do have (mostly transport) topics that I would like
to
understand. I have some concerns about whether the broader remit of
this
document compared to that offered by BCP 91 (RFC 3901) is backed by
the same of
maturity and rigour as for the IPv6-related DNS topics. However, the
following
DISCUSS comments will mostly focus on the new transport topics.
As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/
,
a DISCUSS ballot is a request to have a discussion on the points
below; I
really think that the document would be improved with a change here,
but can be
convinced otherwise. I hope that this review helps to improve the
document,
DISCUSS (blocking) - after discussion/resolution I plan to change my
position:
## 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.
[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.
-----------------------------
## 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.
/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.
-----------------------------
(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."
-----------------------------
## 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.
-----------------------------
## 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)
-----------------------------
## 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.
-----------------------------
## 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?
-----------------------------
## 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.
-----------------------------
## 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.
I note that RFC 9715 was Informational. From the discussion, I
understand that the claim is that time constraints for DNS motivate not
using standard methods to determine an effective PMTU and hence these
recommendations seek to configure a minimum message size that is
expected to work across all current IPv6 paths and where necessary to
provide fragmentation of a response above the IP layer.
I would like DISCUSS what exactly is being recommended and why, but I
expect the earlier comments may suggest a proposal for this that I would
be happy to finalise with you/the WG.
---------------------------------------------------------------------
-
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.
## Section 4.1. Guidelines for Authoritative DNS Server
Configuration:
"Every DNS zone SHOULD be served by at least two IPv4-reachable
authoritative DNS servers to maintain name space continuity."
- Because this is a "SHOULD", please explain the implications when
the advice
is not followed. I then read, the following: " To reduce the chance
of DNS
name space fragmentation, it is RECOMMENDED that at least two
IPv4-reachable and two IPv6-reachable name servers are configured
for
a zone."
- I think I may have been confused by the various recommendations and
tried to
see how to reconciled these two statements. I am a little concerned
that the
advice in this section might be complicated, and I wonder whether
these
(initial) statements are not intended to be normative, because the
following
bullets appear to define more specific requirements. More clarity
would be
appreciated.
We are already reworking this text in response to another comment.
## Section 4.1. fall back
" and providing TCP fall back options [RFC7766]."
- Please be more specific to which section of RFC7766 is being
cited, I could
only find one that is normative (and one informative).
We will clarify this text, and also remove the word 'fall back' (see
changes to 5966 in Paragraph 3 of Section 5 for 7766).
## Section 4.3: What is required?
“ When providing multiple DNS servers to stub resolvers, network
operators SHOULD consider that various implementations can only
configure a small set of possible DNS resolvers, e.g., only up to
three for libc [MAN], and additional resolvers provided may be
ignored by clients."
- What is the protocol requirement here? I can see consideration
might be important, but I expect it isn't sufficient to think about
the problem and sort sort of action might be required/desired?
There might be additional things to do, e.g., trying to mandate a
higher number of resolvers being supported in libs. However, while this
point was vocally asked for to be in the document as a warning sign,
there was also great clarity in the WG that making any requirements for
libc implementers would significantly expand the documents scope.
Hence, the current text.
With best regards,
Tobias
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
