On Sun, Aug 14, 2016 at 6:27 PM, Paul Hoffman <paul.hoff...@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.)
This sounds fine / good to me -- or perhaps even: "If a priming query does not get a response, the recursive resolver needs to retry the query with a different target address from the configuration." s/ within a short time//. This avoids the obvious "What did you mean by 'short'?!" question. IMO implementors can make their own decision here. W > >> 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
