Thanks for the review! Comments below. On Jul 24, 2024, at 18:21, Joe Clarke via Datatracker <noreply@xxxxxxxx> 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
