Re: [DNSOP] Last Call: <draft-ietf-dnsop-resolver-priming-09.txt> (Initializing a DNS Resolver with Priming Queries) to Best Current Practice

What method is in place to ensure that the cache is, #1, checked before
emitting priming queries, #2, that if there is already data (complete or
partial) in the cache, how is the client supposed to determine if the
cached data is preferred over unverified, remote data?  Or does the client
operate with the presumption that local data is always wrong and the best
data is always external?

Inquiring Minds want to know.

/Wm

On Thu, Oct 27, 2016 at 7:57 AM, The IESG <iesg-secretary@ietf.org> wrote:

>
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document:
> - 'Initializing a DNS Resolver with Priming Queries'
>   <draft-ietf-dnsop-resolver-priming-09.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2016-11-10. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document describes the queries that a DNS resolver should emit
>    to initialize its cache.  The result is that the resolver gets both a
>    current NS RRSet for the root zone and the necessary address
>    information for reaching the root servers.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     rfc5452: Measures for Making DNS More Resilient against Forged Answers
> (Proposed Standard - IETF stream)
>     rfc4033: DNS Security Introduction and Requirements (Proposed Standard
> - IETF stream)
>     rfc3226: DNSSEC and IPv6 A6 aware server/resolver message size
> requirements (Proposed Standard - IETF stream)
> Note that some of these references may already be listed in the acceptable
> Downref Registry.
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>