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
pgpl3Vpd0FiUV.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
