I want to add one thought to the general argument that goes along the lines of "I need to enforce a policy on my network, and doh will just encourage more https interception - we have gotten nowhere."
This argument assumes a scenario where the network is trusted by the application and can require/achieve host or application configuration. Indeed - deploying trust anchors to these clients is the only way you're going to intercept https as the notion of network defined configuration of "trusted proxies" and the like is consistently rejected by clients. That seems like the right standard for DNS as well - go ahead and configure a different policy but do it via an existing authenticated configuration mechanism like you would use for adding a trust root. However, rather than adding a root I would suggest that if you're doing client configuration for network-local DNS policy, that you deploy a DoH server that enforces that policy and point DoH clients at it through the various enterprise config mechanisms. It doesn't require any kind of access that adding a trust root does not. This has the desirable property that the application can reliably know what server is providing DNS service in a fully authenticated way. Perhaps in a "my way or the highway" scenario it will choose the highway. That's fair enough - that should be a real choice. When you just intercept 8.8.8.8:53 an informed decision cannot be made. Use of non-default trust roots is also a property generally visible to applications. Most allow it as a matter of user configuration. -Patrick
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
