Extensively trimming: To be honest, this thread has gotten so long that I've lost track of the various changes being proposed, so here's my comments on the text as a whole.
> "An increasing number of applications are offering > application-specific encrypted DNS resolution settings, rather than > defaulting to using only the system resolver. A variety of heuristics > and resolvers are available in different applications including > hard-coded lists of recognized DoH/DoT servers. As I said earlier, I think this text is highly misleading. There are at least two major loci of filtering via DNS: 1. In the operating system itself via the system resolver or hooks into that resolver. 2. In the network via (a) the selected resolver or (b) on-path filtering of the traffic to/from that resolver. There are least three major application resolution technologies that render one or more of these techniques ineffective: 1. Using an application-level resolver which uses the system settings [what Chrome currently does] bypasses (1) 2. Using an application-level resolver which uses DoH/DoT to the system configured resolver [what Edge and Chrome are experimenting with] bypasses (1) and maybe 2(b) if the network config gets out of sync (i.e., you don't want your system configured resolver to do DoH/DoT if you use network-level filtering, but it's easy to see how this can happen if (for instance) you just offer the the user the ISP resolver and they start supporting DoH/DoT 3. Using an application-level resolver which uses DoH/DoT to an application-selected resolver [as in the Firefox TRR system] bypasses all of these. The key point is that a lot of filtering is broken by reasons that have nothing to do with encrypted transport, and so this text is misleading. > For users to have the ability to manage the DNS resolver settings for > each individual application in a similar fashion to the OS DNS > settings, each application would need to expose the default settings > to the user, provide a configuration interface to change them, and > support configuration of user specified resolvers. This seems sort of true, though of course in some systems (I don't know how common this is in the world of mostly single-user computers) users actually can't change the system resolver settings. > The system resolver resolution path is sometimes used to configure > additional DNS controls e.g. query logging, domain based query > re-direction or filtering. This conflates the network and in-OS filtering discussed above, which I really think needs expansion. > If all of the applications used on a given device can be configured to > use the system resolver, such controls need only be configured on the > system resolver resolution path. However if applications offer neither > the option to use the system resolver nor equivalent > application-specific DNS controls then users should take note that for > queries generated by such an application they may not be able to > > * directly inspect the DNS queries (e.g. if they are encrypted), or > > * manage them to set DNS controls across the device which are > consistent with the system resolver controls. OK. > Note that if a client device is compromised by a malicious > application, the attacker can use application-specific DNS resolvers, > transport and controls of its own choosing. ยป This seems opaque. Why not say "then any DNS-based controls may be ineffective." -Ekr
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
