re the 2 second timeout. perhaps timeout does not express the intent well. I think of most of the DNS timeout options to be effectively hold-down timers - to be used to prevent excessive "chatty" behaviours.
/W On Fri, Aug 5, 2016 at 2:45 AM, Shane Kerr <sh...@time-travellers.org> 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. :) > > > This starts a Working Group Last Call for draft-ietf-dnsop-resolver- > priming > > > > 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. 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?) > > > 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. > > Cheers, > > -- > Shane > > _______________________________________________ > 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
