> 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.
[JMC] Been there. Would it make sense, then, to say, “server MUST ignore RD”?
> 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.
[JMC] Okay.
> 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.
[JMC] I re-read 2.1, and I see what you mean. But my first reads interpreted the “such information” to include the whole of the contents of named.root. Maybe it’s just me. But
if not, I would suggest a slight edit to:
“Although there is no harm in adding root server identifiers to the priming configuration, they are not useful for the root priming process.”
> 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.
[JMC] That seems like it would definitely help. Thanks!
Joe
