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

On Sun, Aug 14, 2016 at 4:27 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 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.)

Since root-servers.net is not signed, recursor also has to deal with
compatibility problems, such as EDNS stripping for example. I wonder
how much should be clarified. I was a bit surprised the
root-servers.net is still unsigned, is this deliberate or what would
it take to sign it? It's a critical zone, and signing it would make
this draft much shorter.

Marek

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