> The DNSOP WG chairs welcome feedback on the draft > draft-homburg-add-codcp, Control Options For DNS Client Proxies > ([1]https://datatracker.ietf.org/doc/draft-homburg-add-codcp/). > > I find it a bit weird for a client to *choose* how the proxy/resolver > might connect to upstream, even choosing an IP address set. > And for each request separately.
The goal of the draft is to give a stub resolver the same control over a local proxy as the stub resolver has when it connects to upstream resolvers directly. In most cases, stub resolvers just use systems defaults (usually in /etc/resolv.conf). But in quite a few cases, applications want to deviate from that. For example, Firefox allows the user to specify which DoH provider is used. To keep the system simple, we opted to include the proxy control option in every request. We assume that a connection to localhost is high speed and does not have MTU issues. The alternative would be to have a stateful session between the stub resolver and the local proxy. That deviates quite a bit from how stub resolvers work today. > Moreover, I fail to understand motivation for the caching part > - tagging by properties of transport. If an answer is cached, > what are the privacy concerns? No further connection to upstream > is made for that request anyway. The assumption is that in general, different upstream resolvers may give different answers. The obvious case is if one upstream goes out directly to the internet and another goes through a company VPN. To avoid confusion, the cache should keep those answers separate. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
