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:

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

It's sounding like people don't like the mention of a time at all. 
Proposed replacement:

If a priming query does not get a response within a short time, the 
recursive resolver needs to retry the query with a different target 
address from the configuration.

(I am avoiding saying "within a configured time" because I don't think 
this is easily configured in some common recursors.)

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

Proposed wording:

An on-path attacker who sees a priming query coming from a resolver can 
inject false answers before a root server can give correct answers. If 
the attacker's answers are accepted, this can set up the ability to give 
further false answers for future queries to the resolver. False answers 
for root servers are more dangerous than, say, false answers for TLDs 
because the root servers are the highest node of the DNS.

--Paul Hoffman