DNS over HTTPS changes resolver policy, not just transport
DNS over HTTPS sends DNS queries and responses through HTTPS. RFC 8484 maps each query and response pair to an HTTP exchange and defines the application/dns-message media type for the DNS wire format. The encryption protects the path between the client and the selected DoH endpoint. It does not make the resolver disappear, and it does not make every DNS answer globally consistent.
That distinction matters in a security review. An endpoint can be encrypted, authenticated, and still return policy-dependent answers. Split DNS, local filtering, enterprise domains, and resolver-side logging all remain part of the system. Moving clients to a public DoH service can change both the answer and the evidence available to the network owner.
Choose the resolver before the protocol
Record which resolver the client is configured to use, how it discovered the endpoint, and how it validates the TLS connection. RFC 9462 describes discovery of designated resolvers through SVCB records. RFC 9463 describes network-designated resolver options for DHCP and router advertisements. These mechanisms solve configuration distribution. They do not remove the need to define which resolver is authorized for which network.
An enterprise laptop on a corporate network may need the internal resolver for private names. The same laptop on a hotel network may need a public resolver only for public names. A DoH client that sends every query to one public endpoint can break split-horizon resolution or send internal names to a service the organization did not intend to trust.
Create a resolver policy by environment, device class, and name scope. Pin the endpoint and its certificate expectations. Document the fallback path when the DoH endpoint is unavailable. A fallback to cleartext DNS may be acceptable for some networks and unacceptable for others.
Account for the HTTP surface
DoH uses a URL template and the DNS message media type. The client must validate the HTTPS certificate and process the DNS response format, including truncation and error conditions. A response can arrive over HTTP status codes that do not map directly to DNS errors. Logging should distinguish a transport failure, a TLS failure, a malformed DNS message, and a valid negative answer.
The resolver can still see the query name and client address unless a privacy design such as Oblivious DoH is used. RFC 9230 describes one such relay design. It does not turn every DoH deployment into an oblivious one. Explain what the chosen service can observe and retain.
HTTP intermediaries also matter. A proxy that inspects DoH traffic may defeat the privacy goal, while a cache or logging layer may retain URLs and request bodies. Apply the same data-minimization rules to HTTP access logs as to DNS logs. Do not log full query strings from sensitive applications unless the investigation requires it and the retention policy permits it.
Keep DNSSEC and DoH separate
DoH protects transport to the resolver. DNSSEC authenticates signed DNS data through a chain of trust. A client can use DoH and still receive a forged or unsigned answer from a resolver that does not validate DNSSEC. Conversely, a DNSSEC-validating client can use an unencrypted transport and still verify signed answers.
Document which layer supplies confidentiality, which layer supplies data authentication, and which resolver performs validation. Test a signed name with a valid chain, a bogus signature, and an unsigned name that policy should reject. Check the result at the application, not only the resolver log.
Roll out with a name map
Build a list of internal zones, partner domains, break-glass names, and public domains that applications need. Test each class through the new endpoint. Include a service that resolves through the corporate proxy and a service that performs direct DNS. Confirm that the application receives the expected answer, not just that port 443 is reachable.
Record the resolver endpoint, discovery source, TLS validation, DNSSEC policy, split-DNS rules, logging owner, and fallback behavior. DNS is an input to almost every connection decision. Changing how it is transported deserves the same planning as changing the resolver itself.
Top comments (0)