Change:
key schedule.  It MUST also select an appropriate cipher suite from the list of suites offered by the server.  If the client is unable to select an appropriate group or suite it SHOULD ignore that ESNIKeys <del> value and MAY attempt to use another value provided by the server (recall that servers might provide multiple ESNIKeys in response to a ESNI TXT query).  The client MUST NOT send encrypted SNI using groups or cipher suites not advertised by the server. </del> <ins> value and MAY attempt to use another value provided by the server. (Recall that servers might provide multiple ESNIKeys in response to a ESNI record query.)  The client MUST NOT send encrypted SNI using groups or cipher suites not advertised by the server. </ins> When offering an encrypted SNI, the client MUST NOT offer to resume any non-ESNI PSKs.  It additionally MUST NOT offer to resume any

Discussion:
Subsumes and .
lgtm
NAME NAME NAME What the... So all already working eSNI in Cloudflare is already outdated? Do you understand how difficult it will be to get new IN ESNI in Bind and Knot and even in dig utility? Do you understand that while IN txt is working in all OS, IN ESNI will not work in any of them (system resolver, I mean)? Do you understand that you use for ESNI RR 0xff9f (which is 65439), so it is reserved for private use in IANA? Solution for this. Can you please use both of them?
this is good for wiretapping for easy to drop all ESNI with DPI for SNI downgrade
PR from NAME implements the ESNI RRType, but there doesn't seem to be another issue currently open to track discussion of it. a new RRType allows the removal of the _esni prefix ( and ) reusing TXT has the potential for conflicts with other uses even with the prefix. (imagine the definition of a TXT record that simply applied to all DNS entries) while both TXT and ESNI are 8 bit clean, some people are surprised to learn that about TXT so using a new type may be more robust. Some generic tools processing TXT records would benefit from this. TXT is a set of <= 255 byte strings, defining a new type removes that complexity and reduces overhead There was initially concern about the viability of new RRTypes, but I believe people are more comfortable with that now than when the text was drafted.
Fixed in .
issue briefly discussed the choice of a esni DNS prefix for the TXT record. I think we should revisit that. My primary concern is that using 2 different names for the addressing and key information makes DNS aliasing un-necessarily complicated. Consider the case where URL is a customer of URL and URL is deploying ESNI for all its customers. A classic way to do this is to have URL be a CNAME for URL unfortunately to use URL's new ESNI infrastructure URL would need to add a CNAME record for URL as well. So the ESNI deployment requires DNS changes outside of the org deploying ESNI, which is going to limit its deployment, which in turn is going to limit the breadth of its anonymity pool.

:( Additionally, I've been told that anecdotally putting names under a CNAME is legal but error prone. RFC 1912 seems to have some language that suggests its not even legal (though that is informational). If the ESNI information were instead stored without a prefix then the alias would automatically apply as the CNAME applies to all the RR's of a hostname. Part of the reason for choosing the prefix was to avoid collisions in the TXT space, so it makes sense to also reopen and use a non TXT RR type if we drop the prefix. I think the consensus is moving towards that being fine. This would also to harmonize esni with existing dns deployments.
I forgot to acknowledge the downside here is with apex records. You can't cname an apex record, so the normally annoying second cname with the prefix is actually the only thing the apex can use natively as an alias and this proposal gives that up. otoh apex records inline someone's A records (usually a single provider's anycast) already so they can do the same thing with esni.. and/or we could allow some kind of delegation explicitly as part of the new rrtype (i.e. delegation within the new rrtype data, not via cname)
also see pr
I am not sure if I agree with the problem statement. To me it seems that the argument is based on the assumption that URL is the one to decide if ESNI should be applied for URL I am not sure if all of us would be happy with that assumption. The alternative approach here is to give the owner of each hostname the freedom of deciding whether the hostname should be covered by ESNI. Current design allows the hosting companies to adopt that model, by using the DNS configuration that the hostname owner controls as the switch.
ESNI is already a property of the server not the origin name.. in the same way the version of TLS or the cipher suite set is a property of the server.. or the level of http. All necessarily under the control of URL because it reflects whatever is available on their infrastructure. bighoster may commonly allow their customers to configure this stuff on a per customer or service basis, but that's a bit of a different take and not incompatible with the approach here.
NAME While that might be true, I am not sure if removing the prefix and introducing ESNIInclude () is worth the additional complexity and overhead.

Assuming that we merge , becomes a non-issue. Because a wildcard will much all names with the designated type, including the prefix. For example, the following configuration will support ESNI for all the hostnames under URL, like , , because any query for resolves to . So the only downside is that using prefix and a dedicated RR type at the same time might look strange. But it's practical. I am not sure if we would prefer to require alias resolution for every ESNI client. Implementation wise, it's about reimplementing what DNS recursor usually does in the stub resolver. You need to do things like detecting too many redirects and/or loops. There would also be a performance degradation, because each client needs to do the recursive lookup, while with the prefix we can rely on the recursive resolvers to do it and cache it for other clients. To reiterate, I wonder if there is any practical reason to reinvent the wheel.
Stretching the bounds of my DNS knowledge here, but I think this makes divergence between the A/AAAA and ESNIKeys records much less likely. That is, when URL is served by both CDN A and CDN B, the DNS will return or . If both things are record types on the same hostname, then the divergence only happens when the queries happen on opposite sides of a cached CNAME record expiring and getting the opposite answer the next time around. But if they're separate hostnames, as in the current doc, it's entirely possible to get opposite CNAME records cached, and you've diverged for all clients of the caching resolver for the TTL of the shorter CNAME record. That's a far worse probability of divergence.
Fixed in . Closing.
if you dynamically syntehsize a whole bunch of names in URL you would probably use a URL a/aaaa configuration to do so and give them all the same addresses. but you can't do the same things for TXT records with the esni prefix.. basically URL doesn't do the trick (rfc 4592). initially I viewed this as a configuration and implementation issue because queries and responses do not carry the * at all - the records are synthesized on demand from this config. however, the wildcard is part of AXFR which forms an open interface between resolvers so its syntax and meaning is quite reasonably standardized and should be considered.

Minor point but I am not sure if AXFR is something that is exposed to the resolvers. My understanding is standardized interface for synchronizing authoritative servers. So this will be an issue only for websites that use a DNS that either depends on AXFR (or in other ways depend on the vocabulary of the AXFR). I agree that it would be preferable to address the issue.
my thought here is that axfr represents an interface between, potentially, different implementations so we should try and respect that to whatever extent is possible.
My view of the issue is that we can support all the models that we need to support if we adopt so that ESNIKeys will be distributed using a dedicated type with a prefix. The patterns we need to consider are the combination of three types of DNS records (i.e. single-host, APEX, wildcard) and a boolean indicating if DNS is maintained by someone other than the CDN. The table below illustrates how you could configure the DNS on each case. There are certain cases in which you could use CNAME instead of A / ESNI. 1: You will be required to create _esni records for all hosts that you specify explicitly, if it is necessary to disable ESNI for those hosts (or if those hosts use different ESNI keys).
Fixed in .
dns records are 8 bit clean and rfc 6763 is an example of a TXT record carrying arbitrary data
:+1: Base64 is not only complication. It is a space overhead for a large object like ESNIKeys. Seeing corruption of binary will be rare; we can detect them by validating the checksum and fallback to non-ESNI in such case. So why not go for binary? FWIW, base64 was introduced in .
This is solved in which removes base64 with new ESNI RR type.
We only added this since TXT records were claimed to not work well with binary, per Christian’s suggestion. I’m fine either way.
Thanks for the info. I found URL, in which NAME asks: We know that we can store more than 128 octets in TXT record, and that we have a precedent that uses TXT to store binary data, as NAME has pointed out.

Regarding configurability, my understanding is that RFC 1035 defines how binary TXT records can be specified in a zone file, and therefore many DNS server "softwares" support having such records. Googling also tells me that managed DNS services like Route 53 and Azure DNS provide the capability, although surprisingly they use different escape sequences ( uses + 3 octal, uses + 3 decimal).
I do not think it’s a complication, and I’m not convinced space is an issue as per your comment above.
only tangentially related - NAME do you know why your URL txt record is broken into 127 char strings instead of 255? Is there a bug being worked around somewhere?
NAME Oh I did not notice that. I am using tinydns (of djbdns), and it seems like tinydns works that way (see URL).
NAME The issue about the size is that with base64 we might hit the 512-octet threshold when publishing keys of multiple strengths. As an example, query for URL currently returns a 186-byte response, which contains just secp256r1 key. If we add secp384r1 and secp521r1, I'd assume that the size will come near to 490 octets. In other words, for longer hostnames we will hit the 512-octet threshold if we publish three keys. If we avoid the base64 encoding, we will have enough room to store 3 ECDH keys that can provide 128-, 192-, 256-bit-level security. I do not think this argument is strong enough to prohibit the use of base64 for the following reasons: we will be using DoH / DNS over TLS between the client and the resolver we might be using DNS over UDP that has the 512-octet threshold between the resolver and the authoritative server, but we would want that to migrate to DNSSEC or something even better we might be just fine with publishing only two keys: X25519, X448 But it does make me prefer not to have the overhead of base64, if that is possible.
Fixed in .
:+1: