This is a worthwhile clarification and update to the original specs. Some questions and comments:
2.1. Parameters of a Priming Query A priming query SHOULD use a QNAME of "." and a QTYPE of NS. The priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]). Is this supposed to forbid fallback to TCP? That seems wrong to me. Fallback to TCP isn't expected in practice, but it seems wasteful to require extra logic in the resolver to suppress it in this special case. The resolver SHOULD also use EDNS0 [RFC6891] and SHOULD announce and handle a reassembly size of at least 1024 octets [RFC3226]. Again I think priming queries should use the resolver's normal EDNS buffer size. It ought to be OK for a resolver on a network with a small MTU and broken fragment support to advertise a small buffer. 2.2. Repeating Priming Queries A resolver SHOULD NOT originate a priming query more often than once per day (or whenever the resolver starts). It SHOULD adhere to the TTL values given in the priming response. Why the special once per day requirement? Shouldn't this be entirely driven by the NS RRset TTL? 3.3. Completeness of the Response For an EDNS response, a resolver SHOULD consider the address information found in the additional section complete for any particular server that appears at all. If the resolver did not announce a reassembly size larger than 512 octets, this assumption is invalid. This extra SHOULD seems to over-simplify the normal DNS reply processing rules, which I suppose is what the following paragraph is about. I think it would be better to describe what is expected to happen non-normatively rather than imposing new rules. [[Issue 2: 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 name server implementation. Is this diversity we can live with? Should the authoritative source prevail? Is it therefore a protocol issue rather than an operational choice of parameters?]] Oh that's a bit weird and interesting :-) Looks like some servers fill the additional section with the glue RRs from the root zone (TTL 6 days) and some with the authoritative RRs from the root-servers.net zone (TTL 1000 hours). Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
