Basically, I think this document is useful and I support it to be (eventually) published.
Here are my comments on the current version: - Section 2.2 A resolver SHOULD NOT originate a priming query more often than once per day (or whenever it starts). Depending on the TTL of the NS, this requirement cannot be met as long as we honor the TTL. Even if this is not a problem in practice for the Internet root servers today, we may (though unlikely) see much a shorter TTL in the future. Note also that this document seems to cover "internal" root servers (Section 3.1), which perhaps have a shorter TTL more realistically. Is that intent that these cases are covered as an exception to "SHOULD NOT"? - Section 2.3 For resending the priming query to a different server the random selection SHOULD also be used. I don't understand what "resending" means here. Does this mean a subsequent priming query after the cached ./NS RRset (or its glues) expires? Or does that mean a priming query that is resent to a different server when previous ones time out (or fail unexpectedly)? - Section 2.4 Discussion: Delegations in referral responses are not signed, so consequently the priming response is not validated, either. I don't understand this. The priming response is a response to ./NS from a root server, which is authoritative and could be signed and validated? - Section 3.1 The priming response can be expected to have an RCODE of NOERROR and the AA bit set. Some people don't like terms like NOERROR because it's an implementation specific keyword. If the IESG is consistent (which I doubt though), they will object to the use of it in an RFC. I personally don't have an opinion on the usage, but it's safer to use "no error" (or "No error") as spelled in RFC1035. - Section 4. addresses of all root name servers. This can easily achieved by making all root name servers authoritative for the zone containing the servers' names. nit: s/can easily achieved/can easily be achieved/ More substantially, I'm not sure if this is true. If I remember correctly, (at least some versions of) NSD doesn't populate the additional section from a different zone than that for the answer (in this case, the answer section comes from the root zone and the additional section comes from the root-servers.net zone). - Section 4. [[Do the TTLs for the root NS RRSet and address RRSets in the root and the ROOT-SERVERS.NET. zones need to be aligned? In real life responses, the address RRSet's TTL values vary by implementation.]] I don't think it matters much because the cached RRsets can be purged separately for implementation specific reasons (e.g. memory shortage). - Section 5. There is also a chance that the random target selection chooses the address of a retired root name server. I didn't understand security implication of this point. Maybe more explanation should be provided or this sentence should be removed or moved to somewhere more appropriate. --- JINMEI, Tatuya Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop