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