On 5 Aug 2016, at 2:45, Shane Kerr wrote:
All,
At 2016-08-04 20:03:35 -0400
Tim Wicinski <tjw.i...@gmail.com> wrote:
Remember the Resolver Priming draft? This thing has been kicking
around
for a good solid 5 years. It stalled for a few years waiting for the
busy authors perform some updates.
Then Paul Hoffman took the reins and has done a great job getting
this
ready for publication.
w00t
I like this document, and am happy that it is moving again. :)
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.
I have two minor comments, which may not require any changes.
First, we have:
"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."
The "2 seconds" seems a bit arbitrary.
Yep. But...
I'm not sure why any
recommendations need to be made at all. The document already says that
these are basically normal DNS queries elsewhere - surely that is
enough?
The queries are normal, but the reliance on them is not. Without
priming, nothing can be answered, so that makes them kinda special.
(And maybe if we do want to recommend a retry then we need to be clear
that if an answer comes from an earlier query that the resolver may
accept it?)
That would be a radical shift. Instead, how about "If a priming query
does not get a response within a short period (for example, 2 seconds),
..."?
Second, a possible additional security consideration is that a priming
query typically signals a resolver starting with an empty cache
(although not always - the Knot resolver has a persistent cache, for
example). This may be an especially vulnerable time for a resolver for
cache poisoning. I don't know what can be done to mitigate this though
aside from requiring TCP or DNS cookies for a time after startup, so
perhaps this can be left out.
Priming queries happen both when there is an empty cache and at timeout
of the root records. Unless we know for sure what the ratio between
those two are, I'm hesitant to put anything in the document saying that
it is "common".
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
