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

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

On 5 Aug 2016, at 2:45, Shane Kerr wrote:

> All,
>
> At 2016-08-04 20:03:35 -0400
> Tim Wicinski <[e-mail]> 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