In your letter dated Tue, 10 Jan 2023 11:33:57 -0500 (EST) you wrote: >Why should the application have control over this? If you want to give >control to the application, what should they control? What if two >applications disagree? What if they look up the same thing, but the >first application was okay with in the clear and the second was not. > >Will you use any proxy/cache or redo the request over secure transport? >(assuming if you bother with a proxy, you might as well give the proxy >a cache) > >To me, this seems more like an OS setting, and not an application >setting.
Why should the application have control? The goal is to reduce the complexity of the stub resolver that is linked with the application, without limiting what the application can do. Should applications control this by default? No. But in my opinion, it is better if the user can control this per application (in addition to system-wide defaults) than that we force applications that do want to have this kind of control work around what the system provides. If the first application is okay with sending a request in clear text and attempts to set up an encrypted transport fail, then the request will be sent in clear text. It is possible that if the second request requires an authenticated transport and such a transport is not available that the second request may fail. This behavior is quite similar to what would happen if each application links with its own stub resolver, and decides locally whether to set up an encrypted transport of not. On current systems, a web browser may use DoH where other application use Do53. The draft does not require a cache, but obviously adding a cache is encouraged. The draft specifies that the cache is partitioned per transport instance to avoid confusion on multi-homed devices, and to avoid the possibiliy that a request on unauthenticated transport pollutes answers to requests that require authentication. The goal is to make a local proxy safe for applications that do have requirements with respect to privacy. Currently, applications cannot assume anything about how a local proxy operates. Which encrourages applications to only use their own stub resolvers that set up encrypted transports, potentially ignoring any system-wide settings. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop