Stephane Bortzmeyer <[email protected]> writes: > You mention the risk coming from the resolver. That's why, IMHO, we > should recommend people to run a local resolver, as much as possible > (I'm aware it may not always be possible, for instance for constrained > devices). See section 2.2.1 of draft-bortzmeyer-dnsop-privacy-sol-00
But that doesn't really mitigate everything. Anyone sniffing the wire either near you or even near the resolver in question can see who is making the traffic and where it's going. To get secured deployment using a local resolver scheme, you still have to have the local resolver doing DTLS (or equivalent) from it to everywhere, and the destination NS still gives a lot away even if you could encrypt everything everywhere "soon". I do agree that everyone should use a local resolver. Or, even better, smarter in-application validating APIs with local caches. Anyway, the hack in my Apr 1. document gets around these problems by only needing a few of the distant anonymizing resolvers in place. (FYI, in the document I listed the suggested name as EEEE.K1.example.org, but it really should be reversed to provide easier state tracking in both places: K1.EEEE.example.org). -- Wes Hardaker Parsons _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
