[DNSOP] Re: [Ext] Opsdir last call review of draft-ietf-dnsop-rfc8109bis-05

[Paul Hoffman <[e-mail]>]

Thanks for the review! Comments below.

On Jul 24, 2024, at 18:21, Joe Clarke via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Joe Clarke
> Review result: Has Issues
> 
> 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.

Some systems might set RD to 1 for all queries, such as due to lazy programming. Setting it to 1 does no harm to anyone.

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

The requirements in 4.1 and 4.1 are the normal requirements for any server authoritative for a particular zone. They are just restated here for clarity.

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

The text in 2.1 says that the root server identifiers (such as "l.root-servers.net") that appear in named.root should not be used in priming.

> 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?

I think we can make this clearer by adding an example of a root server identifier as the thing that should not be used; we'll do so in the next version.

--Paul Hoffman