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

["Paul Hoffman" <[e-mail]>]

On 17 Aug 2016, at 9:45, 神明達哉 wrote:

> I've read draft-ietf-dnsop-resolver-priming-07.  I think this is a
> useful document and is almost ready for publication.

Thanks for the careful review.

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

This seems like a far-fetched example that would require a new fallback 
mechanism. There are many, many reasons why the root server operators 
would prevent *all* the addresses from changing during the TTL.

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

Agree. We'll reword this.

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

Yes. Earlier WG discussion brought this up, and we'll remove anything 
about time.
>
> - 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.

The conclusion was the current text. In essence, it says "turn on DO if 
you want; although it is useless now, it might be useful in the future".

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

Good suggestion.

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

Agree: we will remove the SHOULD.

--Paul Hoffman