Change:
4. <del> SNI Encryption keys can be published in the DNS using the ESNIKeys structure, defined below. </del> <ins> Publishing ESNI keys in the DNS requires care to ensure correct behavior.  There are deployment environments in which a domain is served by multiple server operators who do not manage the ESNI Keys. Because ESNIKeys and A/AAAA lookup are independent, it is therefore possible to obtain an ESNIKeys record which does not match the A/AAAA records.  (That is, the host to which an A or AAAA record refers is not in possession of the ESNI keys.)  The design of the system must therefore allow clients to detect and recover from this situation. 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 number of ESNI-enabled server domains supported by a given client- facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client- facing server can guess the correct SNI with probability at least 1/ K, where K is the size of this ESNI-enabled server anonymity set. This probability may be increased via traffic analysis or other mechanisms. The following sections describe a DNS record format that achieve these goals. 4.1. SNI Encryption keys can be published using the following ESNIKeys structure. </ins> The version of the structure.  For this specification, that value SHALL be 0xff02.  Clients MUST ignore any ESNIKeys structure with

Discussion:
This change does the following: Add support for mandatory extensions, which are those that clients must process else reject the ESNIKeys record. Add a mandatory extension carrying a set of v4/v6 addresses, which is effectively the combined record mode. Add text describing how clients ought to resolve ESNI and A/AAAA records, and use the results to initiate TLS connections.
That's fair. However, it seems to be the price to get this sort of simplicity. Moreover, as an extension, it's not pressed upon all clients for all providers. Also true! I'm hoping that folks who are in the position and capable of vending these records can comment on this design's cost.
Given that there was no serious objection to this change and that it works for at least one operator, I'm merging this PR. We can continue to iterate on as needed in parallel.
issues and advocate for the removal of the _esni prefix. A significant side effect of that is that it becomes impossible to use a CNAME at the apex of a zone in order to refer to ESNIKeys of a server operated elsewhere. Inlining keys, as is often done with A/AAAA at the apex, is not plausible due to key rotation. The issue can largely be mitigated with the introduction of an inclusion mechanism directly in the TXT/ESNI record.
This should be fixed by and follow up changes. Closing as such. Please reopen if necessary!
I don't believe resolves this. 136 effectively requires the address and ESNI information to be stapled together (which I still find objectionable). The issue here is that the apex cannot use a CNAME to delegate to the actual third party provider's ESNI record.. typically it just includes an A/AAAA record at the apex and hopes the pointer doesn't go stale. That's bad enough for A/AAAA but it would be terrible for ESNI because it means copying keying information and hoping it doesn't go stale between two different entities. NAME can you reopen?
Sure! Sorry for the misunderstanding. We can probably update this PR to make use of the new DNS-specific extensions.
Fixed by .
This is a substantial step in the right direction, but the fact that A/AAAA records are basically ignored makes me uneasy. The fact that A/AAAA results are essentially fully embedded would imply that all logic involved in selectively returning those responses has to be duplicated for ESNIKeys, which is also sub-optimal.