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] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
