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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
