DNS over HTTPS changes resolver policy, not just transport

DNS over HTTPS introduces a new layer of consideration in resolver policy, extending beyond just the transport mechanism. While encrypting the communication between client and resolver protects the data path, it does not inherently standardize the resolver used or ensure globally consistent responses. The encryption merely changes the medium of communication, leaving other resolver operations, such as split DNS, local filtering, and logging, unaffected.

When transitioning clients to a public DoH service, both the answers received and the available network evidence can change, necessitating a reevaluation of resolver choices based on environment, device class, and name scope. Enterprises must configure specific resolvers for internal domains versus public domains, ensuring that client configuration accurately reflects the intended resolver for different network contexts.

A robust resolver policy must account for the fallback mechanisms when the DoH endpoint fails, balancing the need for cleartext DNS against the potential risks in various network settings. It is crucial to document the HTTP surface considerations, as DoH relies on HTTPS URLs and specific media types, requiring clients to validate both the HTTPS certificate and the structure of the DNS response.

Responsibility for logging and monitoring must be precise, distinguishing between different failure types related to transport, TLS, DNS message processing, and normal negative responses. The privacy impact of DNS over HTTPS should also be acknowledged, as privacy-preserving designs like Oblivious DoH can mitigate some concerns but do not eliminate them entirely.

HTTP intermediaries present additional challenges, potentially exposing sensitive information through logging or caching mechanisms, thus necessitating strict data minimization practices akin to those applied to traditional DNS logs.

DNSSEC remains a distinct layer of security within the DoH framework. While it secures the authenticity of DNS responses, it does not inherently protect against forged or unsigned responses from misconfigured resolvers. It is imperative to separate the concerns of confidentiality (achieved through DoH), authentication (achieved through DNSSEC), and validation (performed by the resolver itself) when deploying DoH solutions.

To implement a successful DoH deployment, organizations should construct a comprehensive resolver policy that includes a detailed name map of internal, partner, break-glass, and public domains. Rigorous testing across these varying domains, including scenarios with corporate proxies and direct DNS queries, is essential to confirm that applications receive the correct responses.

Key aspects to document include the resolver endpoint, discovery method, TLS validation procedures, DNSSEC policies, split-DNS rules, logging responsibilities, and fallback mechanisms in case the DoH service becomes unavailable. This thoughtful, comprehensive approach ensures that the transition to DNS over HTTPS is executed with the same meticulous planning as any other critical change to network infrastructure.