DNS-over-HTTPS and DNS-over-TLS: the encryption that broke network filtering

For about thirty years the Domain Name System ran in the clear, and almost nobody minded. A stub resolver on your laptop sent a UDP packet to port 53 on whatever resolver your DHCP lease handed you, the resolver sent a packet back, and every device on the path between them could read both. The query said www.yourbank.com. The answer said 203.0.113.5. Any coffee-shop router, any ISP, any transit provider, any government tap could log the lookup, and many did. The content of your traffic moved to HTTPS years ago. The names of the sites you visited did not move with it. DNS was the last reliably plaintext thing most people did online without knowing it.

Two protocols closed that gap, and in doing so they reopened a fight that the DNS community has not finished having. DNS-over-TLS wrapped the same query bytes in a TLS session on a dedicated port. DNS-over-HTTPS went further and hid the query inside ordinary-looking HTTPS, indistinguishable on the wire from a web request. The privacy win is real. So is the collateral: network operators who relied on watching DNS to filter malware, enforce parental controls, or meet legal blocking obligations suddenly could not see the queries anymore, and in the DoH case could not even tell that DNS was happening. This post is about how both protocols work, what they actually protect, and why the same property that makes them good for privacy makes them hard for the people who used to run the network.

The plan from here: the threat that motivated encrypted DNS, then the mechanics of DoT (RFC 7858) and DoH (RFC 8484) side by side, then what the encryption does and does not hide once you account for SNI and the resolver itself. After that, the deployment fight: browser defaults, the canary domain, the enterprise visibility problem, the NSA’s guidance, and the centralization argument. Then the second-generation answers, Oblivious DoH and Encrypted Client Hello, and a closing read on where this sits in 2026.

What was actually exposed

Start with the unencrypted baseline, because the encrypted versions only make sense as a response to it. A classic DNS query from a stub resolver to a recursive resolver is a UDP datagram, usually under 512 bytes, with no transport security of any kind. There is no handshake, no authentication of the server, no integrity protection on the answer. The query name travels in plaintext. So does the response. The protocol predates the assumption that the network is hostile.

That exposure has two distinct shapes, and encrypted DNS addresses them separately. The first is confidentiality: anyone on the path sees which names you look up, which is a fairly complete record of which sites you visit even when the page content itself is encrypted. The second is integrity: because the answer is unauthenticated, an on-path attacker can forge a response, and the resolver or the network can silently rewrite an answer to point you somewhere else. ISPs have used exactly this to inject ads into NXDOMAIN responses and to redirect blocked domains to notice pages. Captive portals depend on it. State-level censors depend on it too.

DNSSEC, the older answer, addresses only the second problem and only partway. It signs records so a validating resolver can detect tampering, but it does nothing for confidentiality (the query and answer still travel in plaintext) and it secures the authoritative side of the lookup, not the stub-to-resolver hop where most users actually sit. The encrypted-transport protocols invert that emphasis. They do not sign records. They encrypt the channel between your device and the recursive resolver, which is the hop a coffee-shop network or an ISP can most easily watch. If you want the end-to-end picture of how a name gets resolved across both hops, the DNS resolution walkthrough covers the stub-to-authoritative path that sits underneath all of this.

*The encrypted protocols protect the first hop. The recursive resolver itself always sees the query name; that is what makes resolver choice a privacy decision, not just a transport one.*

DNS-over-TLS: the same query, wrapped

DoT came first. RFC 7858 was published in May 2016, and its design goal is conservative: take the existing DNS wire format and run it inside a TLS session, changing as little else as possible. A DoT client opens a TCP connection to port 853 on the resolver, the well-known port the RFC reserves for this. The first thing on that connection is a TLS handshake. After the handshake completes the connection is encrypted, and from that point the client and server exchange ordinary DNS messages, each prefixed with the two-octet length field that DNS-over-TCP already used (the framing from Section 4.2.2 of RFC 1035). There is no new query format to learn. It is DNS-over-TCP with TLS in front of it, on its own port.

The RFC is firm that the port is not to be reused for cleartext. A server supporting DoT “MUST listen for and accept TCP connections on port 853,” and clients and servers “MUST NOT use port 853 to transport cleartext DNS messages.” That dedicated port is the protocol’s defining property and, later, its weakness. Anyone watching the network can see a connection to port 853 and conclude, correctly, that encrypted DNS is happening. They cannot read the queries, but they know the channel exists, and a firewall that wants to block DoT can do it with a single port rule. The encryption hides the content. It does nothing to hide that you are using it.

Because TCP and TLS setup is expensive relative to a single UDP round trip, the RFC leans hard on connection reuse. Clients and servers “SHOULD NOT immediately close a connection after each response” and “SHOULD reuse existing connections” to amortize the handshake cost across many queries. A successful TLS negotiation is treated as a signal that both sides are willing to keep idle DNS connections open. In practice a stub resolver opens one DoT connection and runs hundreds of lookups through it, which makes the per-query overhead converge toward plain TCP.

Authenticating the resolver

Encrypting the channel is only half of a privacy guarantee. If you cannot tell whether you are talking to the resolver you intended or to a machine that intercepted the connection, the encryption protects your conversation with the attacker. RFC 7858 defines two usage profiles that draw the line differently.

The opportunistic privacy profile encrypts when it can and does not insist on authentication. It is the lowest-friction option and works with any current client, but the RFC is explicit about its limit: it “only provides privacy when there are no on-path active attackers.” A man-in-the-middle who can intercept the port 853 connection and present any certificate gets to read everything, because the client was never required to check who it was talking to. Opportunistic DoT defeats passive logging. It does not defeat an active attacker.

The out-of-band key-pinned profile is the strict one. The client is provisioned ahead of time with a set of SPKI fingerprints (the Subject Public Key Info of the resolver’s certificate), and it authenticates the server by matching the presented key against that pinned set. The RFC requires implementations to support computing the fingerprint “as the SHA-256 hash of the DER-encoded ASN.1 representation of the SPKI.” Pinning the key means an attacker cannot substitute a different certificate even one a public CA would sign, because the client is not checking CA trust, it is checking a specific key it was told to expect. The cost is that the pin has to be configured and rotated out of band, which is why this profile lives mostly in managed deployments rather than consumer defaults.

DNS-over-HTTPS: hiding the protocol itself

DoH, standardized in RFC 8484 in October 2018, makes a different bet. Instead of a dedicated port that announces “encrypted DNS here,” it carries each DNS query inside an HTTPS request to port 443, alongside all the other HTTPS on the network. A DoH exchange maps one DNS query-response pair onto one HTTP request-response. The client is configured with a URI Template (RFC 6570) describing how to build the request URL, and servers “MUST implement both the POST and GET methods.”

The two methods differ in where the query bytes go. With POST, the DNS query is the raw request body. With GET, the query is base64url-encoded into a single URI variable named dns, and the RFC specifies that “padding characters for base64url MUST NOT be included.” Either way the payload is the same on-the-wire DNS message format that everything else uses, carried under the media type application/dns-message, with a maximum size of 65535 bytes. The wire format inside the body is the bare DNS message, without the two-octet length prefix that DoT inherited from DNS-over-TCP. The RFC calls this difference out directly: the wire format in the DoH media type “is different than the wire format used in RFC 7858.”

The choice to ride HTTP is the whole point and the whole controversy. Because a DoH request is an HTTPS POST or GET to a normal-looking server on port 443, a network observer cannot distinguish it from someone loading a web page on that same server. There is no port 853 to block. To block DoH specifically you would have to know the resolver’s address and block that host, or do far more expensive deep inspection, and even that fails the moment the resolver shares an IP with content you do not want to break. DoH does not just hide the queries. It hides the fact that DNS resolution is happening at all, folding it into the ambient noise of web traffic.

*Both run DNS inside TLS. The difference that matters operationally is the port and the disguise: DoT is honest about being DNS, DoH is not.*

Caching, cookies, and the HTTP machinery

Riding HTTP brings the rest of HTTP along, and RFC 8484 has to reconcile two caching models. DNS has TTLs; HTTP has its own freshness rules. The RFC ties them together: the freshness lifetime of a DoH response “MUST be less than or equal to the smallest TTL in the Answer section,” and clients “MUST account for the Age response header field’s value when calculating the DNS TTL.” That lets ordinary HTTP caches and CDNs sit in front of a DoH endpoint without serving stale records, which is one reason DoH scales well on existing web infrastructure. It is DNS resolution running on the same plumbing that serves the rest of the web, and the CDN cache-key mechanics that govern any HTTP cache apply here too.

HTTP also brings tracking surface that plain DNS never had. Cookies are the obvious one. A resolver that set a cookie on a DoH response could correlate a client’s queries across time the way an ad network correlates page views, which would quietly undo much of the privacy DoH is supposed to provide. The RFC pushes back: “HTTP cookies SHOULD NOT be accepted by DOH clients unless explicitly required by a specific use.” It is a normative SHOULD NOT, and well-behaved DoH clients drop cookies for exactly this reason. The privacy of DoH depends not just on encryption but on clients declining the parts of HTTP that would re-identify them.

Padding is the other inherited tool. Even encrypted, DNS messages vary in length, and the length of a query leaks information about which name was looked up. RFC 8484 allows a DoH server to add DNS padding per RFC 7830 when the client requests it, smoothing message sizes so that an observer counting ciphertext bytes learns less. It is optional and request-driven, not automatic, which means in practice the size side channel is only partly closed.

What the encryption does not hide

It is easy to read “encrypted DNS” as “private browsing” and conclude more than the protocols deliver. Two leaks survive, and both matter enough that the NSA called DoH “not a panacea” in its 2021 guidance.

The first leak is the resolver. DoT and DoH encrypt the path between you and the recursive resolver, but the resolver has to decrypt the query to answer it. It sees every name you look up, in plaintext, by design. Encrypted transport changes who can see your DNS from “everyone on the path plus the resolver” to “the resolver.” That is a real reduction, but it is also a concentration: you have handed your complete browsing-by-name history to one party, and the protocol gives you no way to look up a name without somebody being able to read it. Which resolver you choose is now a privacy decision with real weight, and that decision is most of what the centralization argument later in this post is about.

The second leak is downstream of DNS entirely. Once you have the IP address, you open a TLS connection to it, and the TLS ClientHello has historically carried the destination hostname in the clear in the Server Name Indication field. An observer who could not read your encrypted DNS query can simply read the SNI on the connection that follows and learn the same hostname a fraction of a second later. Encrypting DNS while leaving SNI in plaintext is closing one window and leaving the adjacent one open. This is precisely why DoH and Encrypted Client Hello are usually discussed together: ECH encrypts the ClientHello, and the client typically fetches the ECH configuration over DoH so that even the lookup of the key does not leak the name. Neither protocol is sufficient alone. The hostname leaks through whichever one you forget.

There is also the matter of the IP address. Even with DNS and SNI both encrypted, the connection still goes to a specific server IP, and for sites on dedicated addresses that IP maps back to a hostname. Large CDNs blunt this by serving thousands of sites behind a shared pool of anycast addresses, so the destination IP no longer identifies the site; the way one anycast IP can front the whole planet is part of why ECH is viable at all. On infrastructure that does not pool addresses, the IP remains a tell.

The deployment fight

The protocols are the easy part. The hard part started when browsers decided to turn DoH on for users who had not asked for it, and to send those queries to a resolver the browser picked rather than the one the network handed out. That single design choice (DoH plus a browser-chosen default resolver) is what turned an encryption upgrade into a years-long argument about who controls name resolution.

Mozilla moved first and most decisively. After a long trial, Firefox began enabling DoH by default for US-based users on 25 February 2020, sending those queries to Cloudflare’s resolver unless the user or network signaled otherwise. The reasoning was that most users never change DNS settings and would never opt into privacy they had to configure, so the privacy had to be the default. The objection was equally direct: a browser overriding the system resolver takes name resolution away from the network operator, and a lot of things the operator did at the DNS layer stop working.

In the UK the reaction was sharp enough to become a minor scandal. In July 2019 the Internet Services Providers’ Association nominated Mozilla for its “Internet Villain” award, arguing that default DoH would bypass UK filtering obligations and parental controls and “undermine internet safety standards in the UK.” The nomination drew enough backlash that the ISPA apologized and withdrew it, but the underlying concern stuck, and Mozilla committed not to enable DoH by default in the UK without further discussion with local stakeholders. The episode set the template for every later argument: privacy advocates on one side, network operators and child-safety filtering regimes on the other, and a browser vendor deciding the default for millions of users at once.

The canary domain

Mozilla’s technical concession to network operators is a small and slightly awkward mechanism: a canary domain. Firefox checks a special name, use-application-dns.net, using the operating system’s configured resolver before enabling default DoH. If that lookup returns NXDOMAIN, or returns NOERROR but with no A or AAAA records, Firefox treats it as a signal that the network is unsuitable for DoH and leaves DoH off. A network administrator who runs DNS-based filtering can configure their resolver to answer the canary negatively and thereby opt the whole network out of Firefox’s default DoH.

The mechanism has two honest limitations, and Mozilla documents both. It only applies to users who have DoH enabled as the default; a user who turned DoH on themselves is making an explicit choice that the canary does not override. And it is a request, not an enforcement: it relies on Firefox voluntarily checking the name and honoring a negative answer, which other DoH clients are under no obligation to do. The canary works because one vendor chose to implement it, not because the protocol requires anything. It is a social contract dressed as a DNS record.

Chrome took a quieter path that mostly sidesteps the fight. Rather than switching everyone to a new resolver, Chrome’s secure DNS, rolled out in 2020, does same-provider auto-upgrade: it checks whether the resolver the system is already using also offers DoH, and if so it upgrades the existing relationship to encrypted transport without changing which resolver answers. The user keeps the same DNS provider; only the transport gets encrypted. Split-horizon and enterprise configurations keep working because the resolver does not change. It is a smaller privacy claim than Firefox’s (it does not protect you from an ISP resolver that does not offer DoH) but it generated far less operational friction, because it never took name resolution away from the network.

*The canary is an opt-out a network operator can publish, but it works only because Firefox chose to honor it. The protocol compels nothing.*

The enterprise visibility problem

For a network operator, DNS was never only a lookup service. It was a control point and an observation post. Watching DNS queries is one of the cheapest forms of security telemetry there is: a workstation suddenly resolving a known command-and-control domain, or generating the high-entropy nonsense names that domain-generation-algorithm malware produces, shows up in DNS logs before any payload moves. Blocking at DNS is just as cheap: return NXDOMAIN for a malicious or policy-violating domain and the connection never starts. Schools, enterprises, and entire countries built filtering on this. Encrypted DNS, and DoH in particular, removes the visibility and the control in one move.

The acute version of the problem is not the enterprise choosing to deploy DoT to its own resolver. That is fine, even good, and operators do it deliberately. The problem is an individual application, a browser or a piece of malware, that turns on DoH to a third-party resolver of its own choosing and routes its lookups straight past the enterprise resolver. The NSA’s January 2021 guidance, Adopting Encrypted DNS in Enterprise Environments, names this directly: client applications using third-party DoH resolvers “can completely circumvent the enterprise DNS service” and the security controls attached to it. Its recommendation is to take the choice back. Run an enterprise resolver that supports encrypted DNS for the privacy benefit, point all clients at it, and then block and disable every other DoH resolver so applications cannot route around it.

That advice only works if the operator can identify and block the bypass traffic, and DoH’s design makes that the whole fight. DoT is straightforward: block outbound port 853 and DoT to external resolvers stops. DoH has no dedicated port. Blocking it means maintaining a blocklist of known public DoH endpoint addresses and hoping the list stays current, which it never quite does, because new resolvers appear and old ones change addresses. The same property that protects a journalist from a censor, indistinguishability from ordinary HTTPS, protects malware from a SOC. The NSA’s framing is careful about this. DoH is useful and worth adopting, but it “is not a panacea,” it can create “a false sense of security,” and it protects only the DNS transaction between client and resolver, not where the client goes after the lookup is answered.

The malware concern stopped being hypothetical quickly. In 2019 researchers documented Godlua, described as the first known malware to abuse DoH, using encrypted DNS to fetch the location of its command-and-control server while hiding the lookup from network monitoring. Since then DoH-based C2 has become a known technique in several toolkits, and it works for exactly the reason it works for privacy: a defender watching the wire sees HTTPS to a reputable-looking resolver, not a suspicious DNS query. The distinction between server-side and client-side detection that anti-abuse vendors wrestle with, covered in server-side vs client-side bot detection, has a direct analogue here, except the defender has lost the cheapest server-side signal they used to have.

There is also a quieter breakage: split-horizon DNS. Enterprises commonly run internal names, wiki.corp.example, that only the internal resolver knows how to answer. A browser that ships those queries to an external DoH resolver gets NXDOMAIN for names that exist, and internal services break. Chrome’s same-provider auto-upgrade avoids this by never changing the resolver. Firefox’s default-resolver model has to lean on the canary domain and on enterprise policy to keep internal resolution working. The collision is structural: split-horizon assumes the network sees and answers the query, and DoH-to-an-external-resolver assumes it does not.

The centralization argument

Underneath the operational fights is a deeper one about shape. Plain DNS is answered by a globally distributed mesh of recursive resolvers, mostly run by the ISP each user already connects through. When a browser sets a default DoH resolver, it nudges a large population of users toward one operator at once. The privacy model of encrypted DNS, the resolver sees everything, then concentrates that everything in fewer hands.

The numbers give the argument teeth. APNIC’s measurement work, which distributes a script through online ads to millions of distinct users per day and records which recursive resolver actually handles each user’s lookups, found Google Public DNS serving about 14% of users and Cloudflare’s 1.1.1.1 about 3.2%, with all open resolvers combined around 20% of the market. Restrict the view to that open-resolver subset and the concentration is stark: Google holds roughly 68.7% of open-resolver use, and the four largest providers together about 91.6%. Default DoH does not create this concentration on its own, but it points more users at the same small set of operators, and it does so through a decision made in a browser rather than by the user.

The critics here are people who built the DNS, not reflexive opponents of encryption. Geoff Huston at APNIC has written for years that the real question with consolidation is whether independent activities are being folded into a single service, and that a name-resolution system depending on “a small clique of providers” is a different and more fragile thing than a distributed one, a high-value target for both monitoring and denial-of-service. Paul Vixie has argued from the operator’s side that pushing the recursive resolver outside the network perimeter surrenders control and visibility that organizations have good reasons to keep. Their point is not that encrypted DNS is wrong. It is that moving the trust boundary from “the resolver my network runs” to “the resolver my browser vendor chose” is a real transfer of power, and that it happened largely by default rather than by deliberate choice.

There is one economic wrinkle that cuts against the usual centralization worry. Huston notes that the large open resolvers do not charge their users, so the monopoly-pricing failure mode that normally accompanies market concentration does not obviously apply here. The risk is not that Google or Cloudflare will raise the price of DNS. It is resilience and surveillance: a handful of resolvers seeing a large fraction of the world’s lookups is a concentration of both failure risk and visibility, regardless of what anyone charges.

*Among open resolvers the concentration is already steep. Encrypted DNS does not cause it, but browser defaults push toward it.*

Second-generation answers: ODoH and ECH

The resolver-sees-everything leak bothered the people building these protocols too, and the answer was to split the two things the resolver knows. A resolver learns your IP address (because the connection comes from you) and your queries (because it has to read them to answer). Oblivious DoH, published as the experimental RFC 9230 in June 2022 and developed by engineers at Cloudflare and Apple, arranges things so no single server holds both at once.

ODoH inserts a proxy between the client and the resolver, and wraps the query in a second layer of encryption keyed to the resolver. The client encrypts the DNS query to the target resolver’s public key using HPKE (Hybrid Public Key Encryption), then sends that ciphertext through a proxy. The proxy forwards it to the target. The proxy sees the client’s IP but cannot read the query, because it is encrypted to a key the proxy does not hold. The target can read the query but sees only the proxy’s IP, never the client’s. Neither party alone can link a user to their lookups. The guarantee rests on one assumption, stated plainly in Cloudflare’s writeup: the proxy and the target must not collude. If they do, the separation collapses.

The cost is modest enough to be interesting. Cloudflare measured the added encryption work at “consistently less than 1ms at the 99th percentile,” with the real overhead coming from the extra network hop through the proxy: median DoH resolution around 146ms against median ODoH around 228ms, roughly 82ms added by the detour. For a meaningful privacy gain that is a small toll, though it is real, and ODoH remains an experimental standard the IETF has not endorsed as more than that. Adoption has stayed niche.

ECH handles the other leak, the SNI in the TLS handshake, and it depends on encrypted DNS to work. The client fetches an ECH configuration (a public key for the server’s fronting service) from DNS, ideally over DoH so the configuration lookup itself does not reveal the hostname, then uses that key to encrypt the inner ClientHello carrying the real server name. On Cloudflare’s network the outer, visible SNI shows a generic fronting name, cloudflare-ech.com, regardless of which site behind it the user actually wants, so an observer sees a connection to the fronting service and nothing more specific. ECH closes the SNI window that DoH alone leaves open. The two together, encrypted DNS plus encrypted ClientHello, finally hide the hostname at both the places it used to leak, which is why the ECH mechanics and DoH are best understood as one privacy story told in two halves.

Where this sits in 2026

The protocols won the part of the argument that was about cryptography. Plaintext DNS to your ISP is no longer a defensible default for a privacy-conscious client, and the major browsers and operating systems ship encrypted DNS to a wide population now. DoT survives mostly inside managed networks and on mobile, where a known port and an authenticated resolver are features rather than obstacles. DoH won the open internet precisely because it refuses to be identifiable, which is the same property that keeps it controversial. The encryption debate is settled. The control debate is not.

What did not get resolved, and shows no sign of resolving, is who decides which resolver answers your queries. Encrypted DNS did not eliminate the party that sees your lookups. It relocated them, from the ISP resolver on your network to whichever resolver your browser or OS picked, and concentrated a growing share of the world’s name resolution in a handful of operators who do not charge for it and therefore are not constrained by the market in the usual way. ODoH offers a way out by splitting identity from query, but it asks you to trust that two parties will not collude, and it has stayed a research-grade option rather than a default. The honest description of encrypted DNS in 2026 is that it moved a thirty-year-old plaintext leak off the local network and into the resolver, made that resolver harder for anyone else to see or override, and left the question of who should be allowed to run it exactly where the protocol authors found it. The packet is encrypted. The politics are not.

Sources & further reading

IETF (2018), RFC 8484: DNS Queries over HTTPS (DoH) — the DoH standard: GET/POST, the base64url dns variable, application/dns-message, HTTP caching alignment to DNS TTL, and the SHOULD-NOT on cookies.
IETF (2016), RFC 7858: Specification for DNS over Transport Layer Security (TLS) — DoT on port 853, the two usage profiles, SPKI pinning, connection reuse, and 2-octet message framing.
IETF (2022), RFC 9230: Oblivious DNS over HTTPS — the experimental proxy/target separation that prevents one server from holding both client IP and query.
NSA (2021), Adopting Encrypted DNS in Enterprise Environments — guidance to run an enterprise DoH resolver and block all others, with the “not a panacea” caveat.
CISA (2021), NSA Releases Guidance on Encrypted DNS in Enterprise Environments — the alert summarizing the enterprise recommendation.
Mozilla (2024), Canary domain — use-application-dns.net — exactly how a negative answer disables Firefox’s default DoH, and the two caveats on the mechanism.
Cloudflare (2020), Improving DNS Privacy with Oblivious DoH in 1.1.1.1 — the HPKE design, the non-collusion assumption, and the measured latency overhead.
The Chromium Projects, DNS over HTTPS (aka DoH) — Chrome’s same-provider auto-upgrade approach and why split-horizon keeps working.
Geoff Huston / APNIC (2022), Looking at centrality in the DNS — the ad-based measurement of resolver market share and the argument about consolidation.
BleepingComputer (2019), New Godlua Malware Evades Traffic Monitoring via DNS over HTTPS — the first documented malware abuse of DoH for C2.
CDT (2024), Encrypted Client Hello: Closing the SNI Metadata Gap — why DoH alone leaves the hostname in SNI and how ECH closes it.
Wikipedia, DNS over HTTPS — consolidated timeline of the rollout and the UK ISPA “Internet Villain” episode.