> On 22 Jan 2026, at 04:42, Gorry Fairhurst via Datatracker <[email protected]> > wrote: > > Gorry Fairhurst has entered the following ballot position for > draft-ietf-dnsop-3901bis-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-3901bis/ > > > > ---------------------------------------------------------------------- > 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? > > ## 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?)
DNS servers really don’t work well when the used MSS used on the reply segments results in PMTUD occurring. They do not have the time budget for PMTUD to work. We are looking at TCP connections that are being torn down about a second after they are established, most carrying a single DNS message which max out at 64K. Forcing the MSS down to 1232 avoids trigging PMTUD except for rare cases, allowing the answer to get through in the available time budget. > (b) What is the impact/prevalence of MSS Clamping in this case? MSS clamping lowers the MSS value in the SYN > > ## 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? > > ## 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). > > ## 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? > > ## 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? > > ## 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? > > ## 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. > > > ---------------------------------------------------------------------- > 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?). > > ## 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. > > ## 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). > > ## 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? > > - Gorry > > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
