DNS over HTTPS: What Encryption Protects and What It Leaves Exposed
DoH carries DNS queries and responses inside HTTPS exchanges, protecting data on the network path. RFC 8484 and operational documentation help explain the trust boundary, what the resolver can still see, and how GET, POST, and caching differ.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
DNS over HTTPS (DoH) carries the DNS exchange used to find an address for a domain inside HTTPS. This makes the query contents harder for an observer on the network path to read as plaintext DNS, but it does not prevent the selected resolver from seeing the questions it answers or make a user's browsing anonymous. The resolver choice, other name-resolution paths on the device, and the destination of the HTTPS connection still matter.
1. Carrying DNS messages in HTTP exchanges
RFC 8484 maps a DNS query and response to an HTTP exchange. The client sends a DNS wire-format message in an HTTPS request, and the resolver returns a DNS response in the HTTP response body. The standard defines both GET and POST. With GET, an encoded query is carried in a URL parameter, which can work with HTTP caching but may also appear in URL logs or telemetry. Implementations should avoid putting sensitive information in URLs. With POST, the query is carried in the request body, reducing exposure through URL recording.
DoH does not replace DNS semantics with a different name-resolution system. The query and response remain DNS messages, with HTTP headers, status, and transport behavior around them. DNS caching rules do not disappear. RFC 8484 permits use of HTTP caching semantics, but actual reuse depends on response headers, intermediary caches, and client behavior. Enabling DoH therefore does not mean every query is cached, or that no query can be cached.
2. The encrypted connection and who can observe it
HTTPS encrypts transport between the client and the DoH server and authenticates that server. A network operator or observer on public Wi-Fi can no longer inspect the query name in the same way as an unencrypted DNS packet on that connection. The resolver, however, must process the DNS question to return an answer. The protocol does not determine the operator's data-retention policy, internal access controls, account linkage, or legal jurisdiction.
DoH also does not automatically put every lookup by a browser or operating system onto one path. Per-application resolver settings, a VPN, a proxy, local network policy, and other DNS mechanisms may coexist. Even if a DNS query is protected, DoH does not hide the later HTTPS connection to a website, erase browser history on the device, or remove information associated with a logged-in account. Treating encrypted DNS as anonymous browsing would overstate what the protocol does.
3. Choosing a resolver and operating it
A DoH client communicates with a resolver at a configured HTTPS endpoint. Cloudflare's documentation explains client setup for its 1.1.1.1 resolver. Other providers have their own retention policies and operating conditions, so users should read those policies rather than assuming that all resolvers behave alike. On a managed device, changing resolver settings can conflict with company DNS, filtering, or incident-response controls; administrators should decide how DoH fits those requirements.
Because DoH can resemble ordinary HTTPS traffic, it may work across networks that handle plaintext DNS differently, but that same property can conflict with network policy. A managed environment may need to review known resolver endpoints, browser policies, and device settings together to understand which resolver receives queries. Blocking or redirecting connections should account for compatibility, clear policy communication, and failure handling. Users and administrators should be able to determine where queries go.
4. Expert perspective: questions for a privacy review
When evaluating an implementation, do not stop at the statement that traffic is encrypted. Check which endpoint the client actually selected, the resolver's data-handling policy, whether URLs and request metadata are logged, and which fallback path is used when the configured endpoint is unavailable. The standard describes protocol format and interoperability; a provider's documentation describes that provider's service and configuration. These sources answer different questions.
Verification can begin on the device by checking where DNS requests are sent. In a managed environment, review browser and operating-system DoH settings alongside VPN policy, then read the resolver's privacy and retention terms. The protection boundary depends on the whole path. DoH reduces exposure on an unencrypted DNS segment; it does not remove the need to trust the resolver or prevent all forms of tracking.