Checking for an ECH key, and the Windows blind spot

Encrypted Client Hello puts its key in a DNS HTTPS record, so one dig command tells you whether a site supports it. Of eight names checked, three publish a key and cloudflare.com is not among them. Neither DNS tool that ships with Windows can retrieve the record at all: PowerShell has no HTTPS type in its enum, and nslookup quietly queries A and AAAA instead, printing an address as though it answered the question.

TL;DR

ECH's key is published in DNS, so dig <name> HTTPS +short tells you whether a site can do ECH at all. Of eight names checked, three publish a key, three publish the record without one, and two have no HTTPS record at all.
cloudflare.com is in the middle group. Its own test host crypto.cloudflare.com publishes a key; the main name does not.
Neither DNS tool shipped with Windows can fetch an HTTPS record. PowerShell has no HTTPS or SVCB in its record-type enum. nslookup warns once and then queries A and AAAA instead, printing an address as though it answered.
Decoding the key shows the public name in cleartext. That is by design - it is the cover story, not a secret.

The one command that settles it

ECH depends on a key the site publishes in its DNS HTTPS record, which makes the server half of it checkable without a browser, a capture, or any trust in what a vendor claims. Asking eight names the same question produced a three-way split rather than the yes/no most write-ups imply: dnsdoh.art, crypto.cloudflare.com and defo.ie publish a key; cloudflare.com, google.com and example.com publish an HTTPS record with no key in it; github.com and wikipedia.org publish no HTTPS record at all. Four different resolvers were asked, so this is not one resolver's view.

The full walk-through, including decoding the key by hand, is in the ECH guide. It previously said large CDNs "do this already". That was too generous and has been replaced with the measurement.

Windows cannot ask the question

This was the surprise. Resolve-DnsName rejects the query outright, and helpfully prints its entire record-type enum while doing so - a list that ends at NSEC3PARAM, type 51. HTTPS is type 65 and SVCB is 64. Neither exists in the cmdlet, and the numeric form is refused the same way.

nslookup fails less visibly. Given -type=65 it prints unknown query type: 65, then sends ordinary A and AAAA queries and prints the address it gets back. The debug mode makes this unambiguous: the two SendRequest() blocks name type = A and type = AAAA, and type 65 never reaches the wire. The single warning line sits above a screenful of output, and when the same command was redirected to a file the warning did not appear in it - only the address did. Someone checking whether a site supports ECH could easily read that as an answer.

What we could not demonstrate

Confirming that ECH was actually used on a connection is still a browser job. curl lists an --ech option but most builds are not compiled with it, and ours reports exactly that. What the command line does show, in one line, is the problem ECH exists to solve: a tshark filter prints the server name your browser sends in plaintext on every TLS handshake, before any encryption is negotiated.