Last Call Review of draft-ietf-dnsop-rfc8109bis-05
review-ietf-dnsop-rfc8109bis-05-opsdir-lc-clarke-2024-07-24-00

I have been asked to review this draft on behalf of the OPS Directorate.  This
draft describes to initialize a recursive DNS resolver when its cache is empty
(i.e., at initial start time).  While I found the document well-written, it
left me with a few questions.  Maybe these are more my issues vs. issues with
the document, but I wanted to ask to see if some clarifying text might better
help other operators.

First, in Section 3 why not just say that RD bit MUST NOT be set?  Why leave it
to a MAY when setting the bit is undefined?  Seems like the more prescriptive
you are the better.

More importantly, I found Section 4 a bit confusing.  Section 4 itself starts
by saying, "A priming query is a normal DNS query".  This is good.  Makes
things simple.  But then in Section 4.1 there are specific requirements for the
priming response.  Those requirements seem reasonable, but it kind of
conflicted (at least in my mind) with the second sentence in Section 4: "Thus,
a root server cannot distinguish a priming query from any other query for the
root NS RRset."  So I'm not sure that a server could know to adhere to those
requirements in its response.  I suppose this could be cleared up by being
explicit that the client processing the priming response MUST ensure the
response has those properties or it must not prime its cache with that response.

One other question left in my head is with the priming targets configuration. 
You mentioned named.root (which I'm familiar with), but you say this should not
be used.  I think bind does use this by default, and I _think_ this is okay
with this draft since the point is that it shouldn't solely rely on those
addresses.  That is, it should use that as a list of initial target addresses,
but still use the NS priming process to get the current set of A/AAAA records
for the roots.  I guess what I'm asking is that if that language could be
softened a bit to say that this file _could_ be used as that initial address
configuration?

Thanks for your consideration.