[DNSOP] Re: Gunter Van de Velde's No Objection on draft-ietf-dnsop-rfc8109bis-06: (with COMMENT)

[Mark Andrews <[e-mail]>]

> On 20 Aug 2024, at 20:32, Gunter Van de Velde via Datatracker <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]