What DNS over HTTPS Protects—and Where Trust Remains
Separate the device-to-resolver protection from information still visible to the resolver and destination, then check internal DNS and policy before deployment.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
The connection DoH encrypts
DNS over HTTPS (DoH) carries DNS queries and responses in HTTPS HTTP exchanges. TLS encrypts the connection between a device and its configured DoH resolver and authenticates that server. An intermediary on the path therefore sees an HTTPS connection and traffic metadata instead of plaintext DNS messages. The protection ends at the selected resolver. That resolver must process the query and can see the domain name; whether it stores or correlates the query with connection information depends on the service’s operating and privacy policies.
DoH alone does not prove that a DNS answer is authentic. HTTPS protects the channel between client and resolver; DNSSEC validates signed DNS data. They address different trust properties, and one does not automatically replace the other.
What each observer can see
| Observer | Information typically visible | What DoH changes |
|---|---|---|
| Path between device and selected resolver | Device/resolver IP addresses, connection timing, and traffic size | TLS protects query and response contents, but does not erase the destination endpoint or all traffic-analysis signals. |
| Selected DoH resolver | DNS queries/responses it processes and connection metadata | The resolver becomes the chosen trust boundary. Check its retention and use policies. |
| Website contacted after lookup | The subsequent connection and requests sent to that site | DoH does not hide later web requests or prevent the destination from identifying a visitor. |
RFC 8484 says HTTPS’s default port 443 and sharing a connection with other HTTPS traffic can deter on-path interference and make DNS traffic analysis harder. That does not mean every network observer finds DoH indistinguishable from ordinary HTTPS.
HTTP request format and transport
Under RFC 8484, a client sends a DNS wire-format message with HTTP GET or POST. GET places the Base64URL-encoded message in the URI’s dns variable; POST carries the binary message in the request body. The media type is application/dns-message. HTTP/2 runs over TCP, while HTTP/3 maps HTTP semantics over QUIC. Avoid describing DoH as one protocol that uses both TCP and UDP port 443.
Hypothetical deployment: a company with private names
Assume company laptops resolve wiki.intra.example only through an internal DNS service. If a user changes only the browser to a public DoH resolver, that query may no longer pass through the organization’s split-DNS or filtering policy. The name may fail to resolve, or monitoring and blocking may differ from expectations. This is an illustrative scenario, not a result observed on a particular product.
Before rollout, check:
- Which resolver will be selected, and what are its data-retention and use policies?
- Will private zones, split DNS, threat filtering, and fallback behavior still work?
- Can browser-specific settings on managed devices create a path that differs from system DNS policy?
- Have you measured actual latency separately for new and reused connections? The RFC alone cannot establish an improvement for a particular deployment.
Current provider documentation lists these wire-format URI examples: Cloudflare https://cloudflare-dns.com/dns-query, Google https://dns.google/dns-query, and Quad9 https://dns.quad9.net/dns-query. These illustrate endpoint formats, not recommendations or a comparison of privacy policies. Check each provider’s current documentation and your organization’s policy before configuring a client.