> OK. I suppose I'm stuck in the model of (at least) machine-wide > policies, thinking that it would be really messy if each app > chooses properties of their DNS separately. (Which sounds more > like a job for a library API anyway.)
The goal is to move the implementation of the various DNS upstreams (DoT, DoH, DoQ, etc) to the proxy while keeping the stub resolver in the application in control. The division of labour between the application and the stub resolver is outside the scope of the draft. The draft focusses on mechanism. It allows the stub resolver to default to the system setting, and for example only require an encrypted transport. Or the application can take full control and specify exactly which upstreams should be used. I don't think every application should choose properties of their DNS. However, if we don't provide the mechanism, then people will just extend stub resolvers to give applications more control. And then we end up with potentially many different implementations in applications, which seems worse to me. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
