I made a pass through the document and have the following feedback.
> 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. > 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. > 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. > 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. > 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? > 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... > 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. DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
