Change:
The TLS server name (and thus SNI) is the HTTP origin name, however it is not necessarily the same as the host name of the TLS server. HTTP Alternative Services is the obvious way that happens - but Alt-Svc never changes the origin name. When fetching the ESNI key, do we fetch it from URL or URL I think origin-name makes more sense - keeping everything that is an expiicit protocol element in terms of origin eliminates confusion. the counter argument is that you can use alt-svc to do fine grained fanout to providers with different keys (using cdn specific names for them in alt-svc) in a way that is harder to do through the origin name dns controls.
My view is that the base name that is used to lookup the ESNI value (i.e. the name excluding the prefix) must be the same as the hostname that is carried by the ESNI extension. ESNI is a replacement for SNI, and I think that the design should allow the TLS stack to obtain the ESNI key by itself (i.e. by querying ).
PS. To give an example, golang's TLS API to establish a new connection looks like below. As is obvious from the example, name resolution happens inside the TLS stack. I'd assume that we would want to handle ESNI record lookup within the stack as well. Therefore, the name used to lookup the ESNI record cannot be the origin name, which is specific to the behavior defined in HTTP (alt-svc), which operates above the TLS stack. It needs to be the hostname that is used for the name resolution (or a name that is derived from that). My understanding is that TLS stacks on other programming language often has the same abstraction; i.e. handle name resolution inside in the TLS connection establishment call (or the TCP connection establishment call).
This matches my opinion, and also what firefox nightly is currently doing.. but I'm confused by your next comment afaict the SNI information actually comes from tls.Config (Falling back to URL only if not provided).. this is no doubt also the information used to authenticate the cert.. URL The TLS stack is going to need both pieces of information. So which should it use? no - the origin name is the SNI name even with alt-svc. It might not be the host name. If a stack can't support alt-svc, then this isn't a problem - the name is the same everywhere :) If a stack does support alt-svc then it has 2 names to deal with.. one is the name used for SNI and auth, and the other is the one used for TCP. (or perhaps it doesn't do TCP on its own). All this issue is trying to do is decide whether the name we lookup for ENSNI/TXT is the same as the name we lookup for A/AAAA.. I'm going to say that they don't necessarily have to match. (i.e. your A could be for the alt-svc but your txt/esni is always going to be for the origin - which is the same thing you put in your CH. I'll make a pr.

Discussion:
normal A or AAAA queries, and SHOULD block TLS handshakes until they complete, perhaps by timing out. <ins> In cases where the domain of the A or AAAA records being resolved do not match the SNI Server Name, such as when RFC7838 is being used, the SNI domain should be used for querying the ESNI TXT record. </ins> Servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they service.  This yields an anonymity set of cardinality equal to the