DNS over HTTPS (DoH) is a protocol that carries DNS queries and responses inside encrypted HTTPS connections between a client and a DNS resolver. Standardized in RFC 8484, it encodes ordinary DNS messages in the binary DNS wire format and sends them as HTTP requests over TLS on port 443, the same port used by regular web traffic.
Within DNS, DoH addresses a long-standing weakness: classic lookups travel as unencrypted UDP or TCP on port 53, so anyone on the network path can read which domain names a device requests and can alter the answers. DoH provides confidentiality and integrity for the path between the client and its resolver, and it is built into major browsers and operating systems.
How DNS over HTTPS works
A DoH client, called a stub resolver, sends each DNS query to a resolver URL known as a DoH template, for example a path such as /dns-query on the resolver’s host. The query is the same binary message that classic DNS uses, labeled with the media type application/dns-message.
- GET requests carry the query encoded in base64url inside a
dnsURL parameter, which allows HTTP caching. - POST requests carry the query in the request body, which keeps URLs short.
- Responses return the DNS answer in the body, and the HTTP cache lifetime follows the smallest TTL in the answer.
DoH runs over HTTP/2 or HTTP/3, so many queries can share one connection through multiplexing. After the initial TLS handshake, lookups add little overhead, and a persistent connection can make DoH comparable in speed to plain DNS. The first connection, however, costs extra round trips, which is why clients keep it open.
The resolver receives the query, resolves the name in the usual recursive way, and returns the result over the encrypted channel. The resolver-to-authoritative leg remains classic DNS in most deployments, so DoH protects only the first hop.
DNS over HTTPS compared with other DNS transports
DoH is one of several ways to encrypt or protect DNS traffic. They differ in transport, port and how easily network operators can recognize them.
| Protocol | Transport and port | Encryption | Visibility to networks |
|---|---|---|---|
| Classic DNS | UDP or TCP on port 53 | None | Fully readable |
| DNS over TLS (DoT) | TLS over TCP on port 853 | Yes | Easy to identify and block by port |
| DNS over HTTPS (DoH) | HTTPS on port 443 | Yes | Blends with web traffic |
| DNS over QUIC (DoQ) | QUIC on UDP port 853 | Yes | Identifiable by port |
| DNSSEC | Any DNS transport | No, signatures only | Readable but tamper-evident |
The table highlights a frequent misconception: DNSSEC and DoH solve different problems. DNSSEC proves that answers come unaltered from the zone owner, but it does not hide the queries. DoH hides queries from observers on the path, but the client must still trust its resolver to answer honestly. Used together, they complement each other.
Where DoH is implemented and configured
DoH can be enabled at three different levels: inside an application, in the operating system, or on a local network resolver that forwards queries upstream over DoH. The level determines which traffic is protected and who controls the setting.
| Level | What uses DoH | Who controls it | Typical behavior |
|---|---|---|---|
| Browser | Only that browser’s lookups | User or browser policy | Upgrades to DoH when the resolver supports it |
| Operating system | All applications on the device | User or device management | Configured resolver template |
| Network forwarder | All devices behind it | Network administrator | Local DNS forwarded upstream over DoH |
Browsers commonly use an automatic upgrade mode: if the system’s configured resolver is known to offer DoH, the browser switches to its DoH endpoint while keeping the same provider. Some browsers also support a canary domain check that lets a network signal that DoH should be disabled, and enterprise policies can turn browser DoH off or point it at an internal resolver.
Benefits, trade-offs and controversy
DoH improves privacy on untrusted networks such as public Wi-Fi, prevents simple on-path manipulation of answers, and makes DNS-based censorship harder to apply. At the same time, it shifts visibility from local networks to the chosen resolver operator.
| Party | Main benefit | Main concern |
|---|---|---|
| End users | Queries hidden from local observers | Resolver operator still sees queries |
| Network administrators | Fewer spoofing attacks on clients | DNS filtering and logging bypassed |
| Security teams | Encrypted transport for managed devices | Malware can hide lookups in HTTPS |
| Resolver operators | Modern, multiplexed transport | Concentration of queries in few providers |
The centralization concern is the most debated point: when many users send all lookups to a handful of large resolvers, those operators gain a broad view of browsing behavior. Choosing a resolver with a clear data retention policy, or running one’s own DoH resolver, addresses this risk.
Limitations and common mistakes
DoH encrypts one part of the journey, so its protection is easy to overestimate.
- Assuming full anonymity: the destination IP address and, without Encrypted Client Hello, the server name in the TLS handshake still reveal visited sites.
- Breaking split-horizon DNS: an external DoH resolver cannot answer internal company names, so internal sites stop resolving.
- Bootstrapping errors: the DoH server’s own hostname must be resolved first, usually by classic DNS or a fixed IP address.
- Silent fallback: some clients revert to plain DNS when DoH fails unless a strict mode is enforced.
- Ignoring policy: managed networks need explicit configuration, otherwise browsers and systems may bypass corporate filtering.
Put simply
Whenever you visit a website, your device first asks for its address. Normally that question travels as an open postcard that anyone along the route can read. DNS over HTTPS seals the question in an envelope.
It uses the same secure connection that protects online banking pages. People on the same café network can no longer see which sites you look up. They also cannot quietly change the answer. The service that answers still knows the question, so choosing a trustworthy one matters.
In practice
A mid-sized company notices that some employee laptops ignore its internal DNS filter, because browsers have switched to a public DoH resolver on their own. As a result, internal names such as the intranet and the ticketing system sometimes fail to resolve, and malicious domains are no longer blocked on those devices.
The IT team deploys its own internal DoH resolver that applies the same filtering and knows internal zones. Device management policies point the operating system and the browsers to this resolver and disable fallback to public DoH services. Employees keep encrypted lookups on hotel and café networks, while the company restores filtering and internal name resolution across all managed laptops.