See below > On 10 Feb 2026, at 11:34, Tobias Fiebig <[email protected]> wrote: > > Hello Gorry, > > thank you for your feedback so far, and the additional comments under > the ballot. We will address these in the next version. Comments on how > we plan to do this are in this email. > >> --------------------------------------------------------------------- >> - >> COMMENT: >> --------------------------------------------------------------------- >> - >> >> 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 >> appreciate >> the work to address the transport concerns and have updated the >> position based >> on rev -14. >> >> # 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?). > > The otherwise has been removed. > > >> ## 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. > > This text has already been rewritten from the version quoted above in > response to Eric's comments, who voiced similar concerns. > >> ## 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). > > I clarified the text and specifically referred to Sec. 5 of 7766, which > mandates TCP service availability (BCP14 MUST in 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? > > I added text further clarifying this: > > When providing multiple DNS servers to stub resolvers, network > operators have to 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. Hence, when providing more than three DNS > servers to stub resolvers, operators SHOULD ensure that any random > subset of three DNS resolvers from the provided list contains at > least one recursive DNS server supporting DNS resolution via IPv4 and > one DNS server supporting DNS resolution via IPv6. A single > recursive DNS server supporting dual-stack DNS resolution counts > towards both requirements. If this is not done, a client might > select a subset of recursive DNS servers that leads to address family > based namespace fragmentation. > > --- > > I would appreciate any opinions on these changes, either from you or > other list participants. So far, these changes are staged in the > following PR: > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/82 > > With best regards, > Tobias > > -- > Dr.-Ing. Tobias Fiebig > T +31 616 80 98 99 > M [email protected]
All seems good, thanks - I see you may wish to clarify (add current): Current implementations can only configure …. Gorry _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
