Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Paul Hoffman <[e-mail]>]

On Jan 16, 2024, at 16:46, Wessels, Duane <[e-mail]> wrote:
> 
> I made a pass through the document and have the following feedback.

Thanks!

>> Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034].  The
>> scenario used in that description, that of a recursive server that is
>> also authoritative, is no longer as common.
> 
> Since RFC 1034 doesn't use the term "priming" maybe it would be good to be more descriptive here? For example:
> 
>   Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034], where
>   it is referred to as a "safety belt" or part of the SBELT structure.

Yep, already got that from earlier comments.

> 
>> Research shows that after those addresses change, some resolvers
>> never get the new addresses.
> 
> If you feel like this would benefit from a reference, https://indico.dns-oarc.net/event/24/contributions/378/ is one such that would fit.

Sounds good. Let's hope DNS-OARC prevents URL rot.

>> Root server
>> identifier and address changes are the main reasons that resolvers
>> need to do priming instead of just going from a configured list to
>> get a full and accurate list of root servers.
> 
> I find "to get a full..." at the end here to be confusing.  Maybe a slight reordering and rewording?
> 
>   Root server identifier and address changes are the main reasons that
>   resolvers need to use priming to get a full and accurate list of root
>   servers, instead of just using a statically configured list.

Excellent, yes.

> 
>> A priming query is a DNS query used to get the root server
>> information in a resolver.
> 
> I find the above imprecise.  Perhaps:
> 
>   A priming query is a DNS query whose response provides root server
>   names and addresses.

Yep.

> 
>> If a resolver chooses to pre-fetch the root NS RRset before that
>> RRset has expired in its cache, it needs to choose whether to use the
>> addresses for the root NS RRset that it already has in its cache or
>> to use the addresses it has in its configuration.  Such a resolver
>> SHOULD send queries to the addresses in its cache in order to reduce
>> the chance of delay due to out-of-date addresses in its
>> configuration.
> 
> This section doesn't say what a non-pre-fetching resolver should do.
> Does it imply or mean that a non-pre-fetching resolver can only re-prime
> from the original configuration?

No, it just doesn't say. This was discussed during the run-up to RFC 8109, and there was not consensus on a SHOULD for those resolvers.


>> Resolver software SHOULD NOT expect 13 NS RRs because
> 
> This is somewhat out of the blue.  There is no prior discussion on the number of
> root server identifiers.  Although there is immediately after...

Already fixed from an earlier comment.

> 
>> If the Additional section is truncated, there is no expectation that
>> the TC bit in the response will be set to 1.  At the time that this
>> document is written, many of the root servers are not setting the TC
>> bit on responses with a truncated Additional section.
> 
> I think I tried to argue about this phrasing before, but looks like I was unsuccessful.
> IMO truncated should mean TC=1 and TC=1 should mean truncated.  I don't think
> its okay to say that a message can be truncated but TC bit not set.  RFC 1035 says:
> 
> TC            TrunCation - specifies that this message was truncated
>                due to length greater than that permitted on the
>                transmission channel.
> 
> It would be better to use "partial" instead of "truncated" here.  e.g.:
> 
>   If the Additional section contains a partial set of A / AAAA RRsets, there is no expectation that
>   the TC bit in the response will be set to 1.  At the time that this
>   document is written, many of the root servers are not setting the TC
>   bit on responses when not all A / AAAA RRsets fit in the Additional section.

This too was caught in an earlier review, and is now "If the Additional section omits some root server addresses..."

--Paul Hoffman