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
