On Fri, Aug 7, 2020 at 7:20 AM Andrew McConachie <and...@depht.com> wrote:
> > > On 6 Aug 2020, at 16:41, Paul Hoffman wrote: > > > On Aug 6, 2020, at 4:08 AM, Andrew McConachie <and...@depht.com> > > wrote: > >> > >> What does it mean for a resolver to be primed, or for a resolver to > >> not be primed? For example, is a resolver considered primed only if > >> it has all root server names and IP addresses? 50%? At least 1? > > How about this for the last sentence, “A recursive resolver starts > with no cached information about the root servers, and finishes with a > full list of their names and their addresses in its cache.” > > (Sorry for being very late to the party.) It might be useful to compare the "priming" to the elevation from "glue" to "authoritative". I.e. You can use glue information to obtain authoritative data, but you CANNOT answer a query with data that isn't authoritative, and in particular cannot promote glue to answers. Thus, "priming" is about populating a cache with authoritative data, where the "SBELT" (pre-configured or pre-compiled resolver configuration) is the equivalent of glue, but technically not glue (weaker than glue). I believe a canonical priming query/answer would obtain a single authoritative answer (the NS set for .) and a bunch of glue data (the A/AAAA records for those names). It is stronger that the SBELT, and is necessary (but not sufficient) to obtain an answer for the A or AAAA records of any root-server, and also necessary for locating the name servers for any TLD (by using the glue info to select a root server to which to send a TLD query, which would return a delegation response.) Apologies for mangling any of the terminology. Hope this is a little bit useful for improving the -bis doc. Brian.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
