ESNI (Encrypted Server Name Indication)

ESNI was an IETF draft design that encrypted the SNI extension of a TLS 1.3 ClientHello with a public key the server published in a DNS TXT record under _esni.<domain>. Cloudflare and Firefox experimented with it around 2018, but it never became an RFC. The TLS working group redesigned it as ECH, which encrypts the entire ClientHello and was published as RFC 9849 in March 2026.

Why it matters

Today ESNI matters mainly as history and as a source of confusion. Encrypting only the SNI turned out to be too narrow: other ClientHello extensions, such as the ALPN list, could still leak information about the destination, and a client holding a stale key had no robust way to recover. ECH addresses both with an inner/outer ClientHello structure and a retry mechanism. Firefox removed ESNI in favour of ECH, and servers no longer offer it, so documentation or software that still talks about enabling ESNI is describing an obsolete draft.

Example

The two designs publish their keys differently:

; ESNI (obsolete draft): key in a TXT record
_esni.example.com.  IN TXT    "<base64 ESNIKeys>"

; ECH (RFC 9849): config in an HTTPS record
example.com.        IN HTTPS  1 . alpn="h2" ech="<base64 ECHConfigList>"

Common misconceptions

• ESNI and ECH are interchangeable names. ESNI encrypted one extension; ECH encrypts the full inner ClientHello and is the only standardized design.
• Turning on ESNI in a browser still adds privacy. Mainstream browsers no longer implement ESNI and servers do not accept it; the setting to look for is ECH.
• ESNI was needed because TLS 1.3 sends the certificate in plaintext. TLS 1.3 already encrypts the server certificate. The remaining plaintext hostname was the SNI itself, which is why TLS 1.3 alone did not hide the destination.