On Sun, Aug 14, 2016 at 4: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.)
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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
