On Wed, Aug 10, 2016 at 8:38 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> On 5 Aug 2016, at 2:45, Shane Kerr wrote: > > All, >> >> At 2016-08-04 20:03:35 -0400 >> Tim Wicinski <tjw.i...@gmail.com> wrote: >> >> Remember the Resolver Priming draft? This thing has been kicking around >>> for a good solid 5 years. It stalled for a few years waiting for the >>> busy authors perform some updates. >>> Then Paul Hoffman took the reins and has done a great job getting this >>> ready for publication. >>> >> >> w00t >> >> I like this document, and am happy that it is moving again. :) >> > BH: I also like the document! > >> This starts a Working Group Last Call for draft-ietf-dnsop-resolver-prim >>> ing >>> >>> Current versions of the draft is available here: >>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/ >>> >>> Please review the draft and offer relevant comments. Also, if someone >>> feels the document is *not* ready for publication, please speak out with >>> your reasons. >>> >> >> I have two minor comments, which may not require any changes. >> >> >> 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. >> > > Yep. But... > > 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? >> > > The queries are normal, but the reliance on them is not. Without priming, > nothing can be answered, so that makes them kinda special. It seems unnecessary to say much here, trying each of the NS records, and retrying multiple times, should be 'normal' although the details will be implementation dependent. Also related is what to do if none of the servers respond, but again that is application dependent and we don't want to go down that trail. > > > (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?) >> > > That would be a radical shift. Instead, how about "If a priming query does > not get a response within a short period (for example, 2 seconds), ..."? > > 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. >> > > Priming queries happen both when there is an empty cache and at timeout of > the root records. Unless we know for sure what the ratio between those two > are, I'm hesitant to put anything in the document saying that it is > "common". Priming queries happen 1) at startup, 2) when cache is emptied (by rndc flush for example), 3) when the TTL's expire, and 4) when the server decides to prefetch. Perhaps there are others, but in every case there are the same security concerns - an attacker can: a) inject malicious data, or b) block valid data from reaching the server. The first 'owns' the server, the second disables it. > > > --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
