ECH adoption statistics: 99.8% of deployments share one identity, and none rotate keys
Encrypted Client Hello (ECH) adoption statistics from a fresh DNS census of 30,000 domains: 7.1% publish an ECH configuration, and 99.8% of those publish the exact same public identity, cloudflare-ech.com. That concentration is already documented elsewhere. What we measured beyond it is the part nobody has published: every single one of those 2,143 ECH deployments, all of them, publishes exactly one ECHConfig entry. Not two, not a handful for a graceful handover, one. That means when a key rotates, there is no overlap window where the old and new configs are both valid; a client that cached the old config has nothing to fall back to until it re-resolves DNS, and the only thing bounding that cache window is a published DNS TTL that sits at five minutes for 99.95% of deployments. Adoption is concentrated, and the concentration is also running its key hygiene at the tightest possible margin.
What ECH publishes in DNS, and what we read
ECH configuration lives in the HTTPS resource record (RR type 65), the same SVCB-family record that carries a domain's ALPN protocols and IP hints. One of its parameters, ech, carries a base64-encoded ECHConfigList: a length-prefixed list of ECHConfig entries, each one a key-encapsulation ID, a public key, a supported cipher-suite list, a maximum padded name length, and a public_name, the placeholder identity the outer, unencrypted part of the handshake presents while the real SNI stays hidden inside. Reading this is exactly what a browser's own DNS resolution does before it ever opens a TLS connection: a public DNS answer, fetched from a resolver, nothing sent to the domain itself.
We took the same cached Tranco top-30,000 list used in our DNSSEC census, queried the HTTPS record for each domain via Cloudflare's public DoH resolver (1.1.1.1), and, where an ech= parameter was present, decoded it byte by byte against the wire format the draft specifies. The algorithm identifiers, KEM, KDF, AEAD, are fixed-width integers in the structure, so classification is exact, not inferred from a label. We read the DNS answer's own TTL field for the rotation-window analysis and counted how many ECHConfig entries appeared inside each list. Nothing beyond the resolver was contacted; no TLS handshake was attempted against any of the 30,000 domains, so this measures what is published, not whether a live connection actually negotiates ECH correctly.
Adoption at the DNS layer
| Layer | Domains | Share |
|---|---|---|
| Resolved successfully | 29,999 | 99.997% of 30,000 |
| Publish an HTTPS DNS record at all | 6,180 | 20.6% of resolved |
| Publish an ECH configuration | 2,143 | 7.1% of resolved · 34.7% of HTTPS-RR publishers |
The first bottleneck is the HTTPS record itself. Four in five top-30,000 domains do not publish one at all, which caps how far ECH can spread before a domain even has a place to put the configuration. Of the domains that clear that bar, a bit over a third go on to publish an ECH config, which as the next section shows is overwhelmingly a byproduct of which CDN they sit behind rather than a deliberate choice each operator made.
99.8% of ECH is one identity
The outer, unencrypted part of an ECH-protected handshake still needs some server name for routers to direct the connection, so it carries the config's public_name instead of the real one. That name being shared across many unrelated domains is what stops the outer handshake from narrowing down which of a provider's customers you are visiting. Here is who is publishing that shared name in our sample:
| Public identity | Domains | Share of ECH |
|---|---|---|
| cloudflare-ech.com | 2,138 | 99.8% |
| Domain's own apex (self-hosted identity) | 2 | 0.1% |
| A handful of other shared names | 3 | 0.1% |
This half of the finding is not new; the Center for Democracy and Technology's ECH rollout report and a SIGCOMM 2025 poster measuring live ECH deployments both already put Cloudflare's share in the same range. Our fresh count confirms it has not meaningfully diversified: essentially the entire DNS-visible ECH population still fronts through one company's shared identity. Only two domains in 30,000 publish their own apex as the ECH identity rather than borrowing a shared one.
That concentration has already had a real consequence. Because cloudflare-ech.com plus an ECH extension is such a strong, consistent fingerprint, Russia's Roskomnadzor started dropping connections that showed exactly that pattern in November 2024, according to the CDT report, blocking access to sites regardless of what they individually served. A privacy feature that hides which site you are visiting can still, on its own, mark you as using that feature, and when nearly everyone using it shares one identity, blocking that one identity alone reaches almost the entire population at once. The SIGCOMM poster adds an important caveat to our own method: it found a second major deployment, Meta, that runs ECH without exposing its configuration through DNS the way Cloudflare does, so a DNS-only census like ours is structurally blind to it. Our 99.8% describes DNS-visible ECH, not all ECH traffic on the internet.
The part nobody measured: zero rotation overlap
An ECHConfigList can carry more than one ECHConfig entry. That is not an edge case in the spec; it is the mechanism a deployment is supposed to use to rotate its ECH key without a gap, publish the new config alongside the old one, let clients that already cached the old one keep working while new resolutions start picking up the new key, then drop the old entry once caches have turned over. We counted how many entries each of the 2,143 domains actually publishes.
| Configs published | Domains | Share |
|---|---|---|
| Exactly one (no rotation overlap possible) | 2,143 | 100% |
| Two or more (overlap window available) | 0 | 0% |
Every single deployment we found runs the single-config pattern. That includes the 99.8% behind Cloudflare's shared identity, which means one operational decision at one company sets the rotation posture for nearly the entire DNS-visible ECH population. With one config, a key rotation is a hard cutover: the record changes, and any client holding a cached copy of the old config, from before the new DNS answer propagated, has no valid alternative to fall back to inside that config's own structure. The only thing standing between that gap and a real interruption is how long a resolver is willing to keep serving the stale answer, which is exactly what the record's TTL controls.
| TTL observed | Domains | Share |
|---|---|---|
| 300 seconds or less (decaying from a 300s origin TTL) | 2,142 | 99.95% |
| 3,600 seconds | 1 | 0.05% |
A five-minute TTL is short, and on its own that is good news: it caps how long a stale, cached ECH config can keep being handed to a client after rotation. But it means the entire ecosystem's rotation safety net is a five-minute cache expiry rather than the overlap window the spec's multi-config structure exists to provide. Nobody we measured is using the belt; everyone is relying entirely on the suspenders.
The other fields we decoded came back essentially uniform: every ECHConfig used the X25519 key-encapsulation mechanism and the HKDF-SHA256 plus AES-128-GCM cipher suite, which is the mandatory-to-implement baseline the specification requires every conforming client and server to support. Uniformity there is expected and unremarkable, it is what interoperability is supposed to look like. The uniformity that is not mandated by the spec, and that we did not expect going in, is the rotation architecture.
Why this matters, and the honest limits
ECH is a real privacy improvement when it works end to end, and encrypting SNI closes a genuine gap that DNSSEC and plain TLS never addressed. But the operational picture behind the adoption number is thinner than the number alone suggests. Near-total reliance on one provider's shared identity means one company's rotation policy, one company's TTL choice, and one company's outer name are load-bearing for the whole ecosystem's ECH privacy today, and the Roskomnadzor case shows that concentration itself can become the thing that gets targeted. If you are deciding how much to weight ECH in a threat model, the honest read is: strong where it is deployed, deployed almost nowhere outside one CDN, and running its key hygiene at the minimum the DNS TTL allows rather than the overlap margin the protocol supports.
- One list, one pass. This is the Tranco top-30,000 on a single date. Configs rotate and adoption grows, so exact counts will move; the structural finding, universal single-config publishing, is the durable part unless deployments change how they operate, not just how many there are.
- DNS-visible ECH only. We read what is published in DNS. As the SIGCOMM poster found, at least one large deployment (Meta) runs ECH without a DNS-visible config, so our 99.8% concentration figure describes the DNS-visible population, not all ECH traffic on the internet.
- Presence, not a working handshake. A published ECHConfig means a domain is capable of ECH, not that a live connection to it will actually negotiate and honor ECH correctly. We did not attempt a TLS handshake against any of the 30,000 domains; that would mean connecting to a third party, which is outside what a passive DNS census does.
- The Tranco list is a ranking, not a census of the web. Adoption on unranked or smaller domains, which are a much larger population than the top 30,000, is not represented here and could look different.
Frequently asked questions
What is Encrypted Client Hello (ECH) and why does it matter?
Encrypted Client Hello is a TLS 1.3 extension that encrypts the server name (SNI) field of the handshake, the part that historically leaked in plaintext and let anyone on the network path see which site you were connecting to even though the page content itself was encrypted. ECH wraps the real ClientHello in an encrypted payload using a key the destination publishes in DNS, so only that server can read the real request. It matters because SNI was the last major piece of a typical HTTPS connection still sent in the clear.
Does ECH really hide the SNI from network observers and censors?
When every layer holds up, yes: the client has to support ECH, DNS-over-HTTPS or another encrypted resolver has to be active so the ECH key itself is not leaked in plaintext DNS lookups, and the destination has to correctly terminate ECH. Our census only checks the DNS side, whether a config is published, not whether a live handshake actually hides the SNI end to end. Publishing a config is a precondition, not proof.
Which browsers support ECH by default?
Firefox has shipped ECH on by default since version 119, given a compatible DoH resolver. Chrome's BoringSSL stack enables ECH once Secure DNS is active, which is Chrome's default resolver mode on most platforms. Safari exposes no user-facing ECH toggle. In every case ECH depends on encrypted DNS being active first, since the ECH key has to arrive over an encrypted channel or the design falls apart.
Is ECH enabled by default on Cloudflare?
Yes, and our numbers show how dominant that default is: 2,138 of the 2,143 domains in our sample that publish an ECH config (99.8%) name cloudflare-ech.com as their identity, Cloudflare's shared front. Cloudflare is by far the largest driver of DNS-visible ECH adoption today.
What is cloudflare-ech.com and why does my browser connect to it?
It is the shared public_name Cloudflare publishes in the ECHConfig of every domain it fronts with ECH. The outer, unencrypted part of the handshake still needs some server name for routing, and using one shared name across millions of unrelated sites is what stops that outer name from revealing which specific site you are visiting. Your browser presents that name on the wire while the real, encrypted request goes to whatever domain you actually asked for.
How is ECH different from ESNI?
ESNI, ECH's predecessor, only encrypted the SNI field and shipped experimentally around 2018 to 2020 before researchers showed it could still be partially fingerprinted through other unencrypted handshake fields. ECH encrypts the entire inner ClientHello rather than just the SNI, and ties key delivery to a formal DNS record type instead of ESNI's separate TXT-record approach. ESNI is obsolete; ECH is its specified, deployed successor.
Why hasn't ECH been more widely adopted?
Our own numbers show the bottleneck: only 20.6% of the top 30,000 domains publish an HTTPS DNS record at all, the record type ECH rides on, and only 7.1% publish an ECH config. Adoption needs the browser, an encrypted DNS resolver, and the origin or its CDN to all line up, and almost all of today's adoption comes from one CDN enabling it for customers by default rather than operators configuring it themselves.
Can enterprise firewalls or network security tools still inspect traffic when ECH is enabled?
Not the SNI field itself, which is the point of the feature. A middlebox relying on plaintext SNI for filtering or logging loses that signal once ECH applies end to end. Enterprises typically respond with a trusted TLS-inspecting proxy on managed devices or by disabling ECH at the network resolver; neither is visible to a passive DNS census like this one.
Is ECH vulnerable to fingerprinting or blocking by censors?
Yes, and there is a documented case. Because the outer handshake still needs a server name, and because cloudflare-ech.com accounts for 99.8% of the ECH configs in our census, the combination of that specific name plus an ECH extension became a fingerprintable pattern on its own. The Center for Democracy and Technology's ECH rollout report documents Russia's Roskomnadzor dropping connections matching that exact pattern starting in November 2024.
How do I check if a website supports ECH?
Query the domain's HTTPS DNS record (type 65) through a tool that shows raw record data, such as a DNS-over-HTTPS lookup, and look for an ech= parameter. Its presence means an ECH config is published; it does not confirm a live connection will successfully use it. This is the same check our census automated across 30,000 domains, one at a time.
Related reading
- DNSSEC post-quantum readiness: 0% of the top 30,000 domains. The same Tranco list and DoH method, applied to a different DNS-layer security property.
- Certificate transparency post-quantum: 43% of static-CT logs already sign with ML-DSA-44. Another passive, structure-decoded census with the same read-only method.
- SMTP TLS downgrade: the 92% gap behind DMARC. The same pattern in mail transport: a security control publishing widely while the mechanism that would make it airtight lags behind.