In your previous mail you wrote: > > I consider the first one to be already solved, cf. the Microsoft > > deployed solution which puts clients, local networks, the resolver > > (also the Microsoft Domain Server :-), in the same area and uses > > IPsec to protect it. > > Which may be great if you are: 1) in an environment using Microsoft > solutions; and 2) connected to those networks.
=> I gave this as a deployed example for the stub <-> resolver where the resolver is local and under your control (the second is likely if it is a DNSSEC validating resolver too). > Not so great if you are NOT in a Microsoft environment => I am very far to be a Microsoft addict (:-)! But if Microsoft can do it (or enforce it to its customers) there is no reason you can't do it too... > or are mobile or on other networks (and > yes, I realize you could VPN back into the corporate network). => you took words from my mouth: just go back to the known case (note in this case you are likely leaking the corporate name but nothing else). > >You can do other ways but IMHO we can assume > >you don't need confidentiality with far or untrusted resolvers. > >Or with other words you don't need confidentiality with 8.8.8.8 > > And I will disagree with that assumption. => I make the assumption the resolver is under your control (so by definition it is not an open recursive resolver :-). This is more about what means confidentiality in this context, so a topic by itself. > I personally want confidentiality between my stub resolver and > whatever recursive resolvers I may choose to use, including 8.8.8.8 > (and its IPv6 equivalent). I'd like to remove that connection as a > place where an attacker can monitor / observe / log my DNS queries. => to go further we need to know what/if open recursive resolver operators (there are only a few) want to do, and if they want the IETF to charter a WG to design something. IMHO it is very different from the initial perpass concern so should be addressed (if it needs to be addressed) independently. Regards francis.dup...@fdupont.fr PS: for ISP recursive resolvers the issue is simpler: DNS is a part of the ISP service and to protect it is just an easy sub case to protect ISP customers' communications. With other words either you trust your ISP, you don't trust it and there are a lot of things more critical than the DNS. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
