Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Bob Harold <[e-mail]>]

On Wed, Aug 17, 2016 at 12:45 PM, 神明達哉 <[e-mail]> wrote:

> At Thu, 4 Aug 2016 20:03:35 -0400,
> Tim Wicinski <[e-mail]> 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.
>
> I think we could clarify the sentence by adding some thing like "as long
as at least one of the configured addresses (for each address type, IPv4
and IPv6) responds with the correct list."  Even if all the IP's change, we
just need one of the IP's to respond with the new list.


> - 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
>
>