Encrypted DNS hides the lookup. The TLS handshake that follows still names the site, so the destination is not actually private yet.
Encrypting DNS and encrypting the site name are two different jobs. Doing the first without the second leaves the most revealing detail, which site, in plain view.
Why the name is sent in the clear
It is not an oversight. A single IP address often hosts thousands of different sites behind a CDN or shared host. When your browser connects, the server has to know which site you want so it can present the right certificate, and it has to know this before the encrypted channel exists. So the browser announces the hostname in the very first message of the TLS handshake, a field called SNI (Server Name Indication), in the clear.
That solves the server's problem and creates yours. Your DNS query was encrypted, the page content is encrypted, but the one line that says where you are going travels unprotected. A network in the middle, your ISP, a workplace, an airport, does not need to break any encryption to log the sites you visit. It just reads the SNI.
From ESNI to ECH
The first attempt, ESNI, encrypted just the SNI field. It helped, but the rest of the handshake still leaked clues, and it was retired. Its successor, Encrypted Client Hello (ECH), takes the whole opening message of the handshake, the part that carries the SNI and more, and encrypts it with a public key that belongs to the server's front-end.
To an observer the handshake now starts with a generic, shared outer name instead of your real destination. Everyone connecting through the same front-end looks the same on the wire. The real site name is sealed inside, readable only by the server.
The key that makes ECH possible is published in DNS. That is why encrypted DNS and ECH belong together.
Why ECH needs encrypted DNS
Notice where the ECH key comes from: a DNS record (the HTTPS, or SVCB, record) for the site. Your browser has to look that up before it can build the protected handshake. If that DNS lookup happens in the clear, an observer watching it can often infer the destination anyway, which undoes much of what ECH set out to protect.
So the two are a pair. Encrypted DNS hides the lookup; ECH hides the handshake. Run one without the other and you have only closed half the gap. If you have not encrypted your DNS yet, that is the first step, our setup guide covers it, and the protocols comparison explains the options.
What ECH still does not hide
ECH hides the name, not the address. Your browser still opens a connection to an IP, and the observer still sees that IP. Whether that gives the site away depends entirely on who else is behind it. On a large shared front-end where thousands of sites sit on the same address, the IP reveals almost nothing, the crowd is the protection. On a dedicated IP that hosts a single site, the IP alone still identifies the destination, and ECH buys you little on its own.
In other words, ECH is most effective when many sites share an address, and weakest when a site stands alone. It is a real improvement, not an invisibility cloak. What an IP does and does not reveal is covered in what your IP address reveals.
Where ECH stands today
Browser
Chrome and Firefox support ECH, switched on when encrypted DNS is in use. It is on by default in recent versions.
Server
The site must publish an ECH key in its DNS HTTPS record and support it at the TLS layer. Large CDNs do this already; self-hosting is still early.
Both needed
ECH only happens when browser and server both support it. If either side does not, the handshake falls back to plaintext SNI.
For most people there is nothing to configure: use an up-to-date browser with encrypted DNS, and ECH happens automatically on sites that support it. ECH protects the name in the handshake; post-quantum key exchange protects the session key behind it, so a recording cannot be decrypted later.
Close the first half of the gap
ECH needs encrypted DNS to mean anything. Start there: encrypt your lookups, then a modern browser handles the rest.
Encrypt your DNS