Subject: Re: [dns-privacy] [perpass] draft-bortzmeyer-dnsop-dns-privacy (was: [DNSOP] DNS privacy : now at least two drafts)

From: John Heidemann <[email-masked]>
Date: Thu, 22 May 2014 17:19:43 -0700

[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-masked]
>https://www.ietf.org/mailman/listinfo/perpass
>