In any case, it's hard for a client to determine if a TXT record is not present, or unavailable because the authoritative server has no such record, or because something in the middle has blocked it (due to network incompetence or active malice), so if you want that to work, you're going to need to specify dns over https to a trusted third party, and de-decentralize DNS.
That said, from a brief look at the spec, the ESNI extension includes a digest of the key record, so while an observer can't directly read the SNI, given a sufficient effort to find the keys, they could correlate the digests with matching hostnames.
Reaching key agreement to exchange identity information without disclosing the identities in the clear is somewhere between really hard and impossible.
I think you've probably misunderstood what's going on here
ESNIKeys, the data structure you're talking about, isn't a key for a specific name, it's the key for the frontend server that's agreed to do ESNI and can be used for ALL names offered on that frontend server.
Whatever name you're asking about, you get the same ESNIKeys values, whether you wanted cat-photos.example.org or nazi-death-squad.example.net or boring-corporate.example.com if they are all hosted on 10.20.30.40 (or that's a TLS load balancer for perhaps different backends that don't face the outside world) they all have the same ESNIKeys.
The fact they're shared is why there's a length field. We can only safely protect names by padding them. Otherwise it doesn't take a genius to spot that this-very-long-name.subdomains-matter-too.example.com encrypt to a far larger structure than short.example. The length field says I promise all the names I'm protecting with ESNI will fit in a name structure this long, just pad the shorter ones.
The digest is in the ESNI setup because this way a server can go "Oh, you've got last week's keys somehow. No, those won't work" or equally "Those are my Cloudflare keys! We only use Cloudflare in North America, this is a European server, we do AWS here, why have you got those?". Without a digest you have no clue why this idiot client is sending you gibberish and you can't do diagnostics.
QUIC uses the TLS 1.3 client hello (and its extension mechanism) for the handshake, so evolutions to TLS 1.3 like ESNI will be automatically valid in QUIC too as they come down the pike.
If I understand it correctly, I think that countries might start to block ESNI altogether. If it is not widely implemented, websites/apps using it will standout which sadly could limit its adoption. For instance, if Signal decided to use ESNI, it will probably get blocked in those countries, but this can change if big companies wanted to use it. However, I still don't know how it will work exactly.
Anyways, since QUIC is being touted everywhere as being very secure:
> [QUIC] protects both the data and the transport protocol itself
It seems like missing ESNI as a required feature is a bit of a glaring omission. Does anyone have a better understanding? To me, it seems like a great opportunity to make ESNI required for HTTP/3. Much like how browsers made TLS required for HTTP/2. I would love further insights if anyone has any.