For thirty years, every DNS query you sent traveled in plaintext across the network — a consequence of the original protocol design. Your ISP could see every domain you looked up. The coffee shop Wi-Fi could see every site you visited. Governments could build surveillance databases of DNS traffic with trivial effort. Anyone on the network path — routers, middleboxes, intelligence agencies — could observe, log, and even modify your DNS queries.
DNS-over-HTTPS changed that by wrapping DNS queries inside encrypted HTTPS connections. It’s one of the most consequential — and controversial — protocol changes in DNS history.
Why Encrypt DNS?
The motivation for encrypted DNS falls into three categories:
Privacy
Your DNS queries reveal an extraordinarily detailed picture of your online life. Every website visit, app connection, smart device check-in, and API call starts with a DNS query. An observer who can see your DNS traffic knows what news you read, what health conditions you’re researching, which financial services you use, and when you’re home or away.
RFC 7626 (“DNS Privacy Considerations”) documents these privacy concerns formally:
“The DNS protocol… does not include any built-in mechanisms to provide confidentiality for the data exchanged between DNS clients and servers.”
Censorship Resistance
DNS manipulation is the most common censorship technique worldwide. ISPs in restrictive countries redirect or block DNS queries for banned domains. If DNS queries are encrypted and sent to a resolver outside the censorship jurisdiction, this technique stops working.
Integrity
Even without malicious intent, some ISPs modify DNS responses — injecting ads into NXDOMAIN (non-existent domain) responses, redirecting typos to search pages, or manipulating results for commercial purposes. Encrypted DNS with a trusted resolver prevents this tampering.
How DoH Works
DNS-over-HTTPS, defined in RFC 8484 (published October 2018), tunnels DNS queries inside standard HTTPS requests. From a network perspective, DoH traffic is indistinguishable from normal web browsing — it uses port 443, the same TLS encryption, and standard HTTP/2 framing.
The Protocol
A DoH client sends DNS queries to a DoH server’s URI template, typically something like:
https://dns.example.com/dns-query
Queries can be sent via either HTTP GET or POST:
GET request — the DNS query is Base64url-encoded in the dns query parameter:
GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: dns.example.com
Accept: application/dns-message
POST request — the binary DNS message is sent directly in the request body:
POST /dns-query HTTP/2
Host: dns.example.com
Content-Type: application/dns-message
Accept: application/dns-message
Content-Length: 33
<binary DNS query>
The response is a standard binary DNS message (the same wire format defined in RFC 1035), returned with Content-Type: application/dns-message.
Why HTTPS Specifically?
The choice of HTTPS as the transport was deliberate:
- Port 443 is universally open. Almost no network blocks HTTPS. Using port 443 makes DoH extremely difficult to block without blocking all web traffic.
- Existing infrastructure. DoH piggybacks on the massive infrastructure of HTTP/2, TLS 1.3, and CDN networks. No new protocols or ports needed.
- Connection reuse. HTTP/2 multiplexing allows many DNS queries to share a single connection, amortizing the TLS handshake cost.
- Caching. HTTP caching semantics apply — intermediate caches (where appropriate) and client caches can store responses using standard
Cache-Controlheaders.
Browser Implementation
DoH’s most significant deployment vector has been web browsers, which bypassed the operating system’s DNS configuration entirely.
Firefox
Mozilla was DoH’s earliest and most aggressive advocate. Firefox enabled DoH by default for US users in February 2020, sending queries to Cloudflare’s 1.1.1.1 resolver. This was groundbreaking — and controversial.
Firefox’s implementation includes:
- Trusted Recursive Resolver (TRR) program — providers must meet Mozilla’s privacy and data handling requirements
- Canary domain check — Firefox queries
use-application-dns.net; if the query is blocked (returns NXDOMAIN), Firefox disables DoH, allowing enterprise networks to opt out - Fallback — if DoH fails, Firefox falls back to the system resolver
Chrome
Google took a different approach. Rather than switching all users to a single DoH provider, Chrome checks whether the user’s existing DNS resolver supports DoH and upgrades the connection if possible. If the user is configured to use 8.8.8.8 (Google DNS), Chrome uses Google’s DoH endpoint. If they use 1.1.1.1 (Cloudflare), Chrome uses Cloudflare’s DoH endpoint. If the resolver doesn’t support DoH, Chrome continues using plaintext DNS.
This “same provider” approach was designed to avoid the centralization concerns that dogged Firefox’s rollout.
Other Browsers
Safari added DoH support in iOS 14 and macOS Big Sur (2020), though it’s primarily available to apps through the NEDNSSettingsManager API rather than enabled by default. Edge follows Chrome’s approach (since it’s Chromium-based). Brave supports DoH with configurable providers.
The Controversy
DoH triggered one of the fiercest debates in internet governance. The arguments map neatly onto fundamental tensions in internet architecture.
Centralization Concerns
The loudest criticism: DoH concentrates DNS traffic at a handful of large providers. When Firefox sends all US users’ DNS queries to Cloudflare, that’s an enormous amount of browsing data flowing to a single company. Even with strong privacy policies, this concentration creates a single point of surveillance, failure, and government compulsion.
The UK’s Internet Service Providers’ Association nominated Mozilla for its “Internet Villain” award in 2019 over this concern. The irony — Mozilla was trying to protect user privacy — highlights the genuine tension between privacy from local network observers and concentration at remote providers.
Enterprise Visibility
IT departments use DNS as a monitoring and security tool. They run internal DNS resolvers that log queries, block malicious domains, and enforce acceptable use policies. When browsers bypass the corporate resolver and send queries directly to Cloudflare or Google, all of that visibility vanishes.
Split-horizon DNS — where internal domains resolve differently inside vs. outside the corporate network — breaks entirely if the browser ignores the local resolver.
This is why Firefox’s canary domain mechanism exists, and why Chrome’s “same provider” approach was specifically designed to not disrupt enterprise configurations.
ISP Opposition
ISPs worldwide pushed back against DoH. Some had legitimate operational concerns — DNS data helps ISPs detect malware, enforce court-ordered blocking, and manage network traffic. Others had less noble motivations: ISP DNS data is commercially valuable, and DoH threatens that revenue stream.
In the UK, ISPs are legally required to block certain categories of websites, and they implement this through DNS filtering. DoH, if universally adopted, would make this filtering ineffective.
The Privacy Counterargument
DoH advocates counter that the privacy benefits outweigh the centralization risks:
- Users already trust their web traffic to CDN providers; DNS traffic to the same providers is no different
- The alternative — plaintext DNS visible to every network observer — is demonstrably worse for privacy
- Users can choose their DoH provider; the browser doesn’t force a specific one
- Regulatory frameworks can (and do) apply to DoH providers just as they apply to ISPs
DoH Providers
The major DoH providers as of 2025:
| Provider | Endpoint | Notable Features |
|---|---|---|
| Cloudflare | https://cloudflare-dns.com/dns-query |
Privacy-focused (no logging policy), APNIC partnership |
https://dns.google/dns-query |
Logs anonymized data, global anycast | |
| Quad9 | https://dns.quad9.net/dns-query |
Threat-blocking, non-profit, Swiss jurisdiction |
| NextDNS | https://dns.nextdns.io/{config} |
Customizable filtering, analytics, per-device configs |
| Mullvad | https://dns.mullvad.net/dns-query |
No logging, from the VPN provider |
Each provider makes different tradeoffs between features, privacy policies, jurisdiction, and filtering capabilities. The choice of DoH provider is, in many ways, a choice about who you trust with your browsing history.
JSON API: The Alternative Format
While RFC 8484 defines the standard binary DNS message format over HTTPS, several providers also offer a JSON API that’s more developer-friendly:
GET https://cloudflare-dns.com/dns-query?name=example.com&type=A
Accept: application/dns-json
Response:
{
"Status": 0,
"Answer": [
{
"name": "example.com",
"type": 1,
"TTL": 3600,
"data": "93.184.216.34"
}
]
}
This JSON format isn’t standardized in an RFC but is widely supported and convenient for web applications that want to perform DNS lookups directly from JavaScript.
Performance Considerations
DoH adds overhead compared to traditional DNS:
- TLS handshake — the initial connection requires a TLS handshake (1-RTT with TLS 1.3, 0-RTT for resumed connections)
- HTTP framing — HTTP/2 headers add bytes to each query/response
- Connection establishment — TCP + TLS is heavier than a single UDP packet
In practice, HTTP/2 connection reuse and multiplexing mitigate most of this overhead. After the initial connection is established, subsequent queries add minimal latency. Some measurements show DoH performing comparably to traditional DNS for sustained browsing sessions, though the initial connection setup is noticeably slower.
Key Takeaways
- DoH wraps DNS queries in HTTPS, making them indistinguishable from web traffic on the wire
- RFC 8484 defines the protocol; queries use
application/dns-messagecontent type over HTTP/2 - Firefox pioneered default DoH (Cloudflare); Chrome upgrades existing resolvers to DoH when possible
- The controversy centers on centralization (concentrating DNS data at few providers) vs. privacy (protecting queries from local observers)
- Enterprise and ISP concerns led to opt-out mechanisms (canary domains) and “same provider” upgrade strategies
- DoH is the most widely deployed encrypted DNS protocol, primarily through browser adoption