DNS Security

DNS Security Milestone: Android 17 Turns On ECH

Published August 30, 2026 · DNS Benchmark Pro Editorial · Reading time: 5 minutes

For twenty years, the practical state of DNS security has been an awkward compromise. HTTPS encrypted the payload; the destination stayed in the clear. Even after DNS over TLS and DNS over HTTPS closed the resolver leak, the Server Name Indication field in the TLS handshake kept broadcasting the hostname to anyone on the path. Android 17 closes that second gap, and it does so by default rather than as an opt-in toggle buried three screens deep.

Google published the change as one of four network security features in Android 17, alongside enforced Local Network Protection, Certificate Transparency by default, and a carrier-side switch to disable 2G at the modem level. ECH is the one that changes how networks behave.

What Encrypted ClientHello actually does

ECH, standardised as RFC 9849 earlier this year, encrypts the first flight of the TLS handshake — the ClientHello — using a public key the client retrieves ahead of time. Because the key material is published in DNS as an HTTPS resource record, the design is inseparable from name resolution: the client must complete an encrypted DNS lookup before it can build an encrypted handshake.

That ordering matters. If the HTTPS RR query travels over plaintext port 53, ECH protects the handshake but the lookup still reveals the destination, and the privacy gain is close to zero. ECH only delivers its promise when it sits on top of DoH or DoT. The two technologies are not alternatives; one is a prerequisite for the other.

Why GREASE is the important detail

Encrypting the hostname on a minority of connections would create a new signal rather than remove one — an observer could simply flag the ECH-protected sessions as interesting. Android 17 therefore enables ECH GREASE, which sends convincing but meaningless ECH extensions to servers that do not support the standard. Every handshake looks identical whether or not the far end can decrypt it. That is what turns a per-site feature into a population-wide privacy property, and it is the design decision most likely to be copied by other platforms.

The deployment evidence behind the rollout

Shipping a transport change to billions of devices without a staged proof would be reckless, and the published validation work is unusually specific. Jigsaw, Google's technology incubator, ran two measurement campaigns before the platform flag was flipped.

The first tested ECH GREASE handshakes against the top 10,000 global domains and reported no change in connection success rates versus baseline TLS. The second issued requests across 202 countries and 740 ISPs, including heavily filtered national networks, and found a virtually zero interference rate — ECH GREASE traffic reached parity with baseline connections even in environments built to inspect and block. The datasets and Jupyter notebooks are published openly, which is a materially higher standard of evidence than most protocol rollouts offer.

The honest reading is that middleboxes are not currently blocking ECH because most of them have not yet noticed it. That may change once the volume of protected traffic becomes commercially inconvenient. But the measurement baseline now exists publicly, so any future interference will be attributable rather than deniable.

What this breaks for enterprise IT security

If your organisation performs any of the following, it is time to plan rather than react.

• SNI-based egress filtering. Firewalls that categorise or block outbound sessions by reading the hostname from the ClientHello will begin seeing encrypted blobs from Android 17 handsets on guest and BYOD networks. The rule still fires; it just has nothing to match on.
• Passive asset discovery. Tools that inventory which SaaS services a device talks to by watching SNI will progressively under-report. IP-based attribution degrades quickly on shared CDN infrastructure, where thousands of unrelated domains share one address.
• Data loss prevention at the perimeter. Any DLP posture that assumes destination visibility without an interception proxy loses fidelity.

Google has provided an escape hatch for managed environments: network operators can control ECH behaviour through DNS, so schools and enterprises retain policy enforcement on networks they own. The mechanism is deliberate — it keeps governance with the party that runs the resolver, and it promotes resolver configuration from a convenience setting to a first-class DNS security control.

DNS security and server performance become one problem

The operational consequence that will surprise most teams is a performance one. Every ECH-enabled connection now begins with an additional DNS lookup for the HTTPS record. On a resolver that answers in 15 ms this is invisible. On one that adds 150 ms of network latency, or that mishandles HTTPS RR types and returns SERVFAIL, the client either stalls or silently falls back to an unprotected handshake — losing the privacy benefit without raising an error anyone will see.

Jigsaw's own guidance to developers is explicit about optimising HTTPS RR queries for performance, which is a polite way of saying that a slow or non-compliant resolver will quietly undermine the whole design. Three checks are worth running this quarter:

• Confirm your resolvers answer HTTPS (type 65) records correctly. Older forwarders and some enterprise appliances still return errors or empty answers for unknown RR types.
• Measure the resolvers you actually depend on. Comparing candidates with a network diagnostic tool takes minutes and tells you whether your encrypted lookup path adds single-digit or triple-digit milliseconds.
• Decide where DoH terminates. Our primer on DNS over HTTPS covers the visibility trade-off between client-side and network-side encrypted resolution — a decision ECH makes considerably more consequential.

What it means for the industry

Encrypted DNS already covers a substantial share of global web traffic, and ECH removes the remaining plaintext hostname. Taken together, the network path is losing its historical ability to profile users by destination — which is the point, and which also means defenders lose a cheap detection signal they have leaned on for years.

The rational response is not to fight the protocol but to move the telemetry, which is why DNS security is displacing packet inspection as the primary source of destination truth. Recursive resolver logs, endpoint agents and identity-aware proxies see what the wire no longer shows. Organisations that run their own resolvers and log them properly will barely notice this transition. Those that inferred everything from packet capture at the border will find their visibility quietly eroding over the next two Android releases.

Android moving first also sets the schedule for everyone else. Once a platform with this install base normalises ECH GREASE, server operators and hosting providers face a straightforward incentive to enable ECH on their own domains, and the remaining mobile and desktop stacks face an obvious comparison. The interesting question for the next twelve months is not whether ECH spreads, but which national networks decide that a virtually zero interference rate is no longer acceptable to them.

Sources: Google Security Blog, "4 new ways Android is protecting your network connections" (27 August 2026); Jigsaw, "Closing a Critical Internet Privacy Gap for Billions of Users: Android 17 Rolls Out ECH Support" (27 August 2026); IETF RFC 9849 (TLS Encrypted ClientHello); Android 17 developer documentation on platform ECH support; Jigsaw ECH research repository (GREASE Compatibility Report and Multi-Country ISP Analysis). This article is independent editorial analysis and is not affiliated with or endorsed by Google LLC or Jigsaw.