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

From: 神明達哉 <[email-masked]>
Date: Wed, 17 Aug 2016 09:45:59 -0700

At Thu, 4 Aug 2016 20:03:35 -0400,
Tim Wicinski <[email-masked]> 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

---

From: Bob Harold <[email-masked]>
Date: Wed, 17 Aug 2016 13:03:31 -0400

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

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

---

From: 神明達哉 <[email-masked]>
Date: Wed, 17 Aug 2016 10:43:09 -0700

At Wed, 17 Aug 2016 13:03:31 -0400,

> just need one of the IP's to respond with the new list.

Yes, that's one way to address this point (if we want to address it).

--
JINMEI, Tatuya

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 19 Aug 2016 16:31:18 -0700

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

> useful document and is almost ready for publication.

Thanks for the careful review.

> But there seem

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.

>   the obvious, and if we want to say that I don't see why it's not

Agree. We'll reword this.

>   (see my other message on this specific point).

Yes. Earlier WG discussion brought this up, and we'll remove anything 
about time.
>   because the current text still seems to have some explanation gap to

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

>   one easy tweak is to say "there should be an Additional section..."

Good suggestion.

>   resolve a "missing" AAAA via a separate direct query?

Agree: we will remove the SHOULD.

--Paul Hoffman

---

From: 神明達哉 <[email-masked]>
Date: Mon, 22 Aug 2016 11:16:09 -0700

At Fri, 19 Aug 2016 16:31:18 -0700,

> >   configuration updates", we may need to consider some extreme cases
[...]
> would prevent *all* the addresses from changing during the TTL.

I'm okay with dismissing the issue.

> you want; although it is useless now, it might be useful in the future".

Okay, then that's fine for me.

--
JINMEI, Tatuya