On 5/19/14, 1:09 PM, John Heidemann wrote: > > Folks, > > I believe consensus was that dnsop needs a problem statement about DNS > privacy before we explore possible solutions.
If I were to speculate on the basis of the dicussion here and in the DNSE bof the solution space involves signficant if maybe not dramatic architecture changes. I would be happy to support exploration of the problem here and documents of an according nature, but I imagine us chartering it as a standalone activity. > 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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
