Reference guide · dns-ssl · Published 2026-08-16 · 5 min read
DNS over HTTPS explained
DNS over HTTPS explained: how DoH encrypts lookups, the resolver change it makes for browsers, and what it means for DNS debugging.
- ·How DoH works
- ·Who sees what
- ·Test over DoH
How DoH wraps a DNS lookup
DNS over HTTPS (DoH) sends the DNS query as an HTTPS POST or GET to a resolver over 443, instead of the plaintext UDP/TCP format that classic DNS uses on port 53. The resolver still walks the tree (root to TLD to authoritative nameserver), but the query and answer travel inside a TLS connection, so the path between your device and the resolver is encrypted.
| Property | Classic DNS | DNS over HTTPS |
|---|---|---|
| Transport | UDP/TCP port 53 | HTTPS, port 443, TLS |
| Sees the query in the clear between you and the resolver | Yes | The link is encrypted |
| Standard API | RFC 1035 wire format | JSON to a resolve?name= endpoint |
| Browser support | Default | Chrome, Edge, Firefox, Safari (per-connection opt-in) |
The "resolver" at the other end is the same recursive resolver as before (your network's own, a public 1.1.1.1, or 8.8.8.8), just reached over HTTPS instead of classic port 53.
Where the encryption actually starts and ends
The security boundary is between your device and the HTTPS resolver. Everything downstream of that resolver, the root, TLD and authoritative answers, is still in the clear and still caches for the TTL you set. So DoH does not hide your queries from the resolver operator, and it does not stop the responder side caching or the zone operator observing traffic at the authoritative layer. What it removes is the ability of an in-path observer (a hotel Wi-Fi, an ISP with port-53 inspection, or a middlebox) to read or alter the query.
Practical consequences:
- The site sees the same recursive-resolver IP in its logs it would see with classic DNS when you use the same resolver.
- The zone still answers queries it has always answered; no zone or web change is needed for a visitor to use DoH.
- Setup for the site is zero. DoH changes the client side, not the records.
How to check what resolves over DoH
Resolvers expose the same lookups over their DoH endpoints:
curl -s "https://1.1.1.1/dns-query?name=example.com&type=A" -H "accept: application/dns-json"
This returns the A record if DoH is working from your network. Compare to a classic dig example.com @8.8.8.8. The two should agree; a difference means your network's classic resolver (or a middlebox) is rewriting or blocking the classic path, and DoH bypasses that. That is why a DoH lookup is a good diagnostic when "the site is down for me but not for staff": classic DNS is failing or filtered on your network while the encrypted path works.
Browsers and per-site behaviour
Chrome, Edge, and Firefox let users pick a secure-DNS resolver (for example, Chrome's bundled DoH provider, or a manually configured one), and each offers a fallback to the operating system's resolver when the secure path fails. For a site you operate:
- A user who cannot reach you because their resolver returns a stale or wrong answer still fails the same way: the browser falls back to the system resolver for propagation windows.
- Browser-level "secure DNS" that uses a public DoH server does not change DNS records, so nothing on your side to configure.
- Some corporate networks disable/override DoH; a user unable to load the site from a locked-down network is a network problem, not a zone problem.
DoH versus other DNS privacy features
DoT (DNS over TLS) is the same encryption over a dedicated 853 port rather than HTTPS. The operational difference for a site is negligible; DoH rides the same 443 path as everything else, which is why enterprise filters often miss it first. Type of resolver levels in nameserver configs (DoT/DoH listeners) are policy questions for the DNS host, not for the zone.
What an operator should know
- DoH is client-side. There is no "turn it on" for a zone, and nothing a host can publish affects whether visitors use it.
- The authoritative server still sees the query, because the resolver must ask it. DoH stops the network between you and the resolver from seeing it, not the whole path.
- When debugging "why did this visitor's query miss my new record", you are theorising over a mix of DoH-in-default resolvers and classic caches; the propagation article explains the timing side of that mix.
- Enterprise privacy policies that matter to you (a hotel portal, a school filter) may route DoH around the block; the DNS of the network article covers that failure shape.
When DoH does not help
DoH is not a privacy layer for the entire internet and it is not a fix for a broken zone. Nothing about DoH changes missing records (an NXDOMAIN), an expired registration, or a provider outage. It also does not stop your operating-system-level cache; flushing it is a separate step. The tool it replaces is only the last mile of the query, which is the layer it encrypts.