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

[神明達哉 <[e-mail]>]

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.

- 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