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." 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
