> 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
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
