[Reposing to dns-privacy. Originally posted to dnsop and perpass; sorry lost track of the new dedicated mailing list.]
On Mon, 19 May 2014 13:09:48 -0700, John Heidemann wrote: > >Folks, > >I believe consensus was that dnsop needs a problem statement about DNS >privacy before we explore possible solutions. > >Stephane's draft-bortzmeyer-dnsop-dns-privacy seems like a very good start >to this problem statement. Are there plans to discuss this draft at >IETF90 in Toronto? > >I sent him some detailed comments out-of-band, but one question for the >list: what do we call the parts of the DNS resolver hierarchy? > >draft-bortzmeyer-dnsop-dns-privacy-02 defines and uses the terms >(1) "stub resolver", >(2) "resolver" and >(3) "name server" > >and also >(2.5) a forwarding DNS resolver/server that is beyond the first-hop >recursive resolver/server but not authoritative. > > >for the things that >(1) initiates queries, >(2) handle recursive resolution, >(3) reply with authoritative responses. > > >The short version is: > >I recommend against use of resolver without an adjective for (2). > >Prior RFCs do not have consensus about what to use (both recursive resolver and >recursive name server appear). Personally I'd go with "recursive >resolver". Does the list have other recommendations? > > > >The tl;dr version is below: > >I looked over many (but certainly not all) existing RFCs, and there is >some variation in terminology: > >RFC-1035 (the original DNS spec): >(1) stub resolver >(2) recursive server >(3) no specific term (!)... it does talk about "foreign name servers" >and "masters" and "authoritative data", but not authoritative servers > >RFC-1996 (DNS notify): >(1) (not used) >(2) (not used) >(3) authoritative server > >RFC-1999 (EDNS): >none > >RFC-3833 (DNS threats) uses >(1) stub resolver >(2) recursive name server >(3) authoritative name servers > >RFC-4033 and 4035 (DNSsec) use: >(1) stub resolver >(2) recursive name server >(3) authoritative name servers > >RFC-4871 (DKIM): >uses only >(2) recursive name server > >RFC-5966 (DNS over TCP): >(1) stub resolver >(2) recursive server (or forwarder) >(3) authoritative server > >RFC-6891 (ENDS(0)): >(1) stub resolver >(2) recursive resolver AND caching resolver >(3) authoritative server > > > > >Back to > >draft-bortzmeyer-dnsop-dns-privacy > >My recommendation for terms is: > >(1) stub resolver >(2) recursive resolver >(2.5) forwarding resolver OR maybe caching intermediate resolver >(3) authoritative nameserver (or authoritative name-server) > >Based on these observations: > >- "resolver" without an adjective for (2) risks ambiguity > >- recursive resolver vs. recursive server for (2) seem to depend on if > you're approaching the problem from the end-user or the providers > point of view. The challenge is that (2) is both a client AND server, > leading to inconsistency. > >Just a suggestion, > -John Heidemann > >_______________________________________________ >perpass mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
