> On 20 Aug 2024, at 20:32, Gunter Van de Velde via Datatracker > <nore...@ietf.org> wrote: > > Gunter Van de Velde has entered the following ballot position for > draft-ietf-dnsop-rfc8109bis-06: No Objection > > 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-rfc8109bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Gunter Van de Velde, RTG AD, comments for draft-ietf-dnsop-rfc8109bis-06 > > ## Many thanks for writing this document. I found it an nice read into the > depths recursive DNS resolvers. > > ## The comments below are of cosmetic nature and mostly suggest alternate > textblobs > > Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ > documenting the handling of ballots. > > #DISCUSS items > #============= > ##tbc > > #GENERIC COMMENTS > #================ > ## The text states "undefined" in section 3.: > > "The Recursion Desired (RD) bit MAY be set to 0 or 1, although the meaning of > it being set to 1 is undefined for priming queries."
Actually it is NOT undefined. RFC 1034 says exactly what to do. Sending recursive queries to authoritative only servers results in RD=1 and RA=0 being set in the response header and you get the same response as you would if you had RD=0 in the request. That is 100% clear in RFC 1034. Root servers don’t behave differently to other servers. The only difference is that they are configured to serve “." > I am unsure what 'undefined' means in this context. does it mean that setting > this to 1 is forbidden? Maybe a line explaining the implications of the > undefined can be helpfull for iplementors to know what to do if they ever > receive such RD with a priming query. > > Maybe this statement could be something like: > > " > The Recursion Desired (RD) bit SHOULD be set to 0. The meaning when RD is set > to 1 is undefined for priming queries and outside the scope of this document. > " > > ## In section 3.2 both IPv4 and IPv6 are handled equally as potential Target > Selection. Would it not be better for the Internet if there is a bias > suggested > towards IPv6 when all other things being equal? > > #DETAILED COMMENTS > #================= > ##classified as [minor] and [major] > > 19 This document, when published, obsoletes RFC 8109. See Section 1.1 > 20 for the list of changes from RFC 8109. > > [minor] > Mostly i found that when documents obsolete other documents with a newer > revision that the changes are in the Appendix. It seems a more logical place > add these. Not sure it belongs in the main body of the draft. > > 114 * Changed "man-in-the-middle" to "machine-in-the-middle" to be > both > 115 less sexist and more technically accurate. > > [minor] > s/less sexist/more inclusive/ > > 159 Priming is the act of finding the list of root servers from a > 160 configuration that lists some or all of the purported IP addresses > of > 161 some or all of those root servers. In priming, a recursive > resolver > 162 starts with no cached information about the root servers, and > 163 finishes with a full list of their names and their addresses in its > 164 cache. > > [minor] > I found this paragraph difficult to parse. What about the following alternatve > textblob: > > " > Priming refers to the process by which a recursive resolver obtains the list > of > root servers from a configuration that includes the purported IP addresses of > some or all of those root servers. During priming, the recursive resolver > begins without any cached information regarding the root servers and concludes > with a complete list of their names and corresponding addresses stored in its > cache. " > > 173 software. This list is usually correct and complete when shipped, > 174 but may become out of date over time. > > [minor] > small cosmetic rewrite: > > " > While this list is generally accurate and complete at the time of > distribution, > it may become outdated over time. " > > 176 The domain names for the root servers are called the "root server > 177 identifiers". This list has been stable since 1997, but the IPv4 > and > 178 IPv6 addresses for the root server identifiers sometimes change. > 179 Research shows that after those addresses change, some resolvers > 180 never get the new addresses; for example, see [OLD-J]. > > [minor] > What about following cosmetic alternative textblob: > > " > The domain names assigned to the root servers are referred to as "root server > identifiers." Although this list has remained stable since 1997, the > associated > IPv4 and IPv6 addresses for these root server identifiers occasionally change. > Research indicates that, following such changes, certain resolvers fail to > update to the new addresses; for further details, refer to [OLD-J]. " > > 182 Therefore, it is important that resolvers be able to cope with > 183 change, even without relying upon configuration updates to be > applied > 184 by their operator. Root server identifier and address changes are > 185 the main reasons that resolvers need to use priming to get a full > and > 186 accurate list of root servers, instead of just using a statically > 187 configured list. > > [minor] > cosmetic alternative textblob to consider: > > " > It is therefore essential that resolvers possess the capability to adapt to > changes, even in the absence of configuration updates applied by their > operators. Changes to root server identifiers and their corresponding > addresses > are primary reasons why resolvers must employ the priming process to obtain a > complete and accurate list of root servers, rather than relying solely on a > statically configured list. " > > 224 SHOULD be randomly selected (see [RFC5452]). The Recursion Desired > 225 (RD) bit MAY be set to 0 or 1, although the meaning of it being set > 226 to 1 is undefined for priming queries. > > [major] > I am unsure what 'undefined' means in this context. does it mean that setting > this to 1 is forbidden? Maybe a line explaining the implications of the > undefined can be helpfull for iplementors to know what to do if they ever > receive such RD with a priming query. > > Maybe the statement should be something like: > > " > The Recursion Desired (RD) bit SHOULD be set to 0. The meaning when RD is set > to 1 is undefined for priming queries and outside the scope of this document. > " > > 255 3.2. Target Selection > > [major] > The current text handles IPv4 and IPv6 equally and leaves it entirely up to > the > implementation. Would it not be beneficial that there would be a suggested > bias > in this document to use an IPv6 address instead of a legacy IPv4 address? It > smels as a missed opportunity in the path towards pervasive IPv6 > > 338 At the time this document is published, there are 13 root server > 339 operators operating a total of more than 1500 root server > instances. > 340 Each has one IPv4 address and one IPv6 address. The combined size > of > 341 all the A and AAAA RRsets exceeds the original 512-octet payload > 342 limit from [RFC1035]. > > [minor] > proposed alternate cosmetic textblob: > > " > As of the publication of this document, there are 13 root server operators > collectively managing more than 1,500 root server instances. Each instance is > assigned both an IPv4 address and an IPv6 address. The total size of all the A > and AAAA resource record sets (RRsets) exceeds the original 512-octet payload > limit specified in [RFC1035] " > > 371 5. Post-Priming Strategies > 372 > 373 When a resolver has a zone's NS RRset in cache, and it gets a query > 374 for a domain in that zone that cannot be answered from its cache, > the > 375 resolver has to choose which NS to send queries to. (This > statement > 376 is as true for the root zone as for any other zone in the DNS.) > Two > 377 common strategies for choosing are "determine the fastest name > server > 378 and always use it" and "create buckets of fastness and pick > randomly > 379 in the buckets". This document gives no preference to any > particular > 380 strategy other than to suggest that resolvers not treat the root > zone > 381 as special for this decision. > > [minor] > Alternative cosmetic textblob: > > " > When a resolver has a zone's NS RRset in its cache and receives a query for a > domain within that zone that cannot be answered from the cache, the resolver > must select which nameserver to direct the queries to. This process applies > equally to the root zone as it does to any other zone within the DNS. Two > commonly employed strategies for making this selection are: "identify the > fastest nameserver and consistently use it" and "group nameservers based on > response speed and select randomly within those groups." This document does > not > advocate for any specific strategy, other than suggesting that resolvers > should > not treat the root zone differently when making this decision. " > > > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
