At Thu, 4 Aug 2016 20:03:35 -0400, Tim Wicinski <tjw.i...@gmail.com> wrote:
> This starts a Working Group Last Call for draft-ietf-dnsop-resolver-priming > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/ > > Please review the draft and offer relevant comments. Also, if someone > feels the document is *not* ready for publication, please speak out with > your reasons. > > This starts a two week Working Group Last Call process, and ends on 19 > August, 2016 I've read draft-ietf-dnsop-resolver-priming-07. I think this is a useful document and is almost ready for publication. But there seem to be a few non-trivial issues that may need to be addressed. Specific comments: - Section 2 Therefore, it is important that resolvers be able to cope with change, even without relying upon configuration updates to be applied by their operator. If we really want to make it work "even without relying upon configuration updates", we may need to consider some extreme cases where all of the ./NS data (and/or all of their glue AAAA/A records) change while a resolver keeps running for a very long period. If this happens, once the cached priming data expires, even the next priming would fail, since at that point the resolver needs to use the configured data but none of the configured data is usable. If we want to make it work even in such cases, we may have to encourage some specific techniques more strongly, e.g., query prefetch or auto-update the configured "root hint" with the result of priming query, etc. Or, if this sentence doesn't intend to cover such extreme cases, it may probably have to be reworded to avoid misunderstanding. - Section 3.1 The recursive resolver SHOULD expire the NS records of the root servers according to the TTL values given in the priming response. Isn't this (= expiring cached data according to TTL) obvious and non-specific to priming responses? I don't see why we bother to say the obvious, and if we want to say that I don't see why it's not even a MUST. - Section 3.2 If a priming query does not get a response within 2 seconds, the recursive resolver SHOULD retry with a different target address from the configuration. This sentence doesn't seem to be necessary (and may even cause an unnecessary confusion), so I'd primarily suggest just removing it (see my other message on this specific point). - Section 3.3 (DNSSEC with Priming Queries) I remember I commented on this section before and we had discussions about how to address it. I don't remember the conclusion at that time, but is this a result of that discussion? I'm asking this because the current text still seems to have some explanation gap to me. - Section 4.1 [...] There may be an Additional section with A and/or AAAA RRSets for the root name servers pointed at by the NS RRSet. At least in principle, I suspect the additional A and/or AAAA RRsets is critical information for priming to work correctly. If the priming response completely replaces ./NS in the cache populated from the local configuration but the response lacks the additional address RRsets, then no further recursive resolution will be successful. I don't know what's the best way to address this, but one easy tweak is to say "there should be an Additional section..." instead of "may". - Section 4.2 Said another way: in an EDNS response, if the additional section only has an A RRSet for a server, the resolver SHOULD assume that no AAAA RRSet exists. It's not clear to me why we need to say this, especially with an RFC2119 keyword. What's wrong, for example, if a resolver tries to resolve a "missing" AAAA via a separate direct query? -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
