DNS-over-HTTPS Changed Nothing (and Everything)

DNS-over-HTTPS changed almost nothing about how DNS answers are produced and almost everything about who gets to watch the question.

That’s why the politics got so heated.

At the protocol level, DoH (RFC 8484, 2018) is not mystical. It takes DNS queries that would normally travel in plaintext over UDP port 53 and wraps them in HTTPS on port 443. Same resolver logic on the other end. Same records. Same questions. Different transport. That sounds modest until you remember how much network policy, censorship, parental filtering, enterprise inspection, and ISP telemetry depended on the old plaintext behavior.

One transport change. Huge argument.

What Traditional DNS Exposed

DNS was designed in the 1980s with no privacy considerations. Every query your device sends to a resolver travels in plaintext. Your ISP can see every domain you resolve. So can anyone else on the network path — a corporate proxy, a coffee shop router, a government surveillance system.

This was fine when DNS was designed. The network was small, mostly academic, and largely cooperative; nobody was building it with eavesdroppers in mind.

By 2015 the IETF had written the problem down in RFC 7626, DNS Privacy Considerations, and plaintext DNS had become one of the easiest passive surveillance channels on the internet. ISPs used DNS data for advertising, analytics, and content injection. Government censorship systems filtered by DNS. Corporate proxies logged DNS for compliance. And anyone running a packet capture on a shared network could see exactly which sites every user was visiting.

What DoH Changes

DoH encrypts DNS queries inside HTTPS. The queries travel on port 443, mixed in with regular web traffic. An observer on the network path sees HTTPS connections to a resolver (like Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8) but can’t see the domain names being queried.

Your ISP can still see that you’re connecting to the resolver. They can see the IP addresses you subsequently connect to. They can sometimes infer the domain from the IP (especially for sites on dedicated IPs). But the DNS query itself — “what’s the IP for example.com?” — is hidden.

For the average user, this closes the most obvious passive surveillance channel. The ISP’s ability to build a complete log of every domain you visit goes from trivial to expensive.

DoH vs DoT: The Political Distinction

DNS-over-TLS (DoT, RFC 7858, 2016) does the same thing — encrypts DNS queries — but on its own dedicated port: 853. The encryption is equivalent. The privacy improvement is equivalent.

The political difference: port 853 is easy to identify and block. A network operator who wants to prevent encrypted DNS can simply block port 853. DoH on port 443 is invisible — it looks like regular HTTPS traffic. Blocking port 443 means blocking the entire web.

This is why DoH is more controversial than DoT. DoT gives network operators a choice: allow or block encrypted DNS. DoH takes that choice away. You can’t block DoH without blocking HTTPS.

ISPs hate this. Enterprise IT hates this. Governments running DNS-based censorship hate this. They all had the same objection: “you’re taking away our ability to see and control DNS resolution on our networks.”

They’re right. That’s the point.

The Pushback Was Real

When Mozilla announced DoH by default in Firefox (initially routing all DNS to Cloudflare), the backlash was intense.

ISPs argued they needed DNS visibility for network management, abuse prevention, and compliance with court orders. In 2019 the UK’s Internet Services Providers’ Association nominated Mozilla for its “Internet Villain” award, arguing DoH would bypass ISP-level filters and parental controls — then withdrew the nomination, and the whole category, after the backlash.

Enterprise IT argued that DoH bypasses internal DNS policies. If a corporate laptop uses the system resolver, the company controls DNS — they can block malicious domains, enforce acceptable use policies, route internal domains correctly. If Firefox sends DNS directly to Cloudflare, all of that breaks.

Governments argued that DNS-based censorship exists for valid reasons (child abuse material, terrorism content, court-ordered blocks) and DoH undermines those mechanisms.

None of these arguments are entirely wrong. They’re just in tension with the equally valid argument that plaintext DNS is a surveillance channel and people deserve the option to encrypt their queries.

The DNSSEC Confusion

DoH and DNSSEC solve different problems but get confused constantly.

DoH provides privacy — who can see the query. It encrypts the transport so observers can’t read your DNS questions.

DNSSEC provides integrity — is the answer authentic. It signs DNS responses so you can verify they haven’t been tampered with.

DoH without DNSSEC gives you encrypted lies. The query is private, but the answer could be forged. DNSSEC without DoH gives you authenticated responses that everyone on the path can see.

You want both. Most people have neither. DoH adoption grew through browser defaults. DNSSEC is still missing from most domains — the large majority of .com is unsigned. The two technologies that need each other are deploying on completely different timelines.

What Actually Changed

The technical change landed in browser defaults. Firefox enables DoH by default for desktop users in the US and Canada (and since 2022 in Russia and Ukraine), in a fallback mode that reverts to the system resolver if DoH fails. Chrome follows the system resolver’s DoH capability — if your configured resolver supports DoH, Chrome upgrades to it automatically.

The practical impact: millions of users are now encrypting DNS without knowing it. For those users, ISP-level DNS surveillance became significantly harder.

For users on corporate networks, enterprise IT can detect and disable DoH through various mechanisms (canary domains, group policy, network-level resolver enforcement). The bypass isn’t total.

For users in countries with DNS-based censorship, DoH provides a circumvention tool — but only if the DoH resolver itself isn’t blocked, and a censor can block well-known resolvers by IP address and hostname. The arms race continues.

If you want to turn it on yourself, it’s a setting, not a project. In Chrome: Settings → Privacy and security → Security → Use secure DNS. In Firefox: Settings → Privacy & Security → DNS over HTTPS, where “Max Protection” refuses to fall back to plaintext. Windows 11 can use DoH system-wide for known resolvers in the network adapter’s DNS settings. Android’s “Private DNS” setting was built on DoT rather than DoH — same idea, different port.

The Incomplete Picture

DoH encrypted the DNS query. Good. But SNI still leaks the destination in the TLS handshake. So you encrypted the question and then announced the answer in the next packet.

ECH (Encrypted Client Hello) fixes that — it became RFC 9849 in March 2026, and Chrome and Firefox already support it — but only on servers that have turned it on, which today mostly means sites behind a few large CDNs. Until it is the norm, the privacy improvement from DoH is real but partial. You hid which domain you’re looking up. You still reveal which domain you’re connecting to.

The full privacy stack — DoH for query encryption, DNSSEC for answer integrity, ECH for destination privacy — exists in specification. In practice, most connections have one of these at best.

We solved the easy part first. The hard parts are taking longer. As usual.