> On Mar 18, 2021, at 9:40 AM, Eric Orth <[email protected]> > wrote: > > > > On Thu, Mar 18, 2021 at 12:33 PM Jim Reid <[email protected] > <mailto:[email protected]>> wrote: > > > > On 18 Mar 2021, at 16:21, Eric Orth <[email protected] > > <mailto:[email protected]>> wrote: > > > > I disagree with your assumption that clients/users are only concerned about > > particular resolvers. > > Eric, I didn’t make any assumptions about that at all. It was Tommy who said > ODNS would benefit those who were concerned about leakage to very large > public resolvers. All I did was suggest a simpler alternative that wouldn’t > need an RFC or the introduction of more complexity and lots more moving parts. > Ah, thanks for the explanation. Maybe Tommy can further explain his point? > > > If the aim of ODNS is to prevent leakage to resolvers *in general*, then > that’s a different story. But as I said the use case and problem statement > isn’t (yet) compelling enough. The cost/benefit analysis is unclear too. YMMV. > Preventing leakage to resolvers *in general* would be exactly my interest in > ODoH. This goes along with my previous statement that I think clients could > find good use in automatically using ODoH (for either particularly-sensitive > or all queries) as an autoupgrade to known-supporting providers rather than > just being something users explicitly select when they have particular > concerns.
To clarify my point earlier, I was mainly replying to the concern that supporting ODoH would be a burden for resolvers to implement. Although I don’t think it’s actually that much complexity to add, given our experience, I don’t see a deployment scenario where all recursive resolvers would offer oblivious resolution. Mainly, this is relevant for resolvers that directly receive client-generated queries, are not directly on the local network (and thus already know a lot about the user), and are in a position where a client can use a proxy to access them. Large public resolvers do fall into this category, but it isn’t limited. It could also be the resolvers used for ISPs, carriers, etc. Thanks, Tommy > > > > _______________________________________________ > dns-privacy mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dns-privacy > <https://www.ietf.org/mailman/listinfo/dns-privacy> > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
