Original text:
SNI Encryption keys can be published in the DNS using the ESNIKeys structure, defined below.  The first four (4) octets of the SHA-256 message digest RFC6234 of the ESNIKeys structure starting from the first octet of "keys" to the end of the structure. This structure is placed in the RRData section of a TXT record as a base64-encoded string.  If this encoding exceeds the 255 octet limit of TXT strings, it must be split across multiple concatenated strings <del> as per Section 3.1.3 of RFC4408. </del>  The name of each TXT record MUST match the name composed of _esni and the query domain name.  That is, if a client queries example.com, the

Reviewer comments:
Do we need it.
For ESNIKeys (the DNS record) I do not think we need a version for the following reasons: I think we would prefer adding extensions rather than making incompatible changes we always have the freedom to pick a new prefix (e.g. ) or a new RR type when making incompatible changes an incompatible change will require the client to query for two DNS records anyways For the ESNI extension, I also do not think that we need a version field. When we define an extension sometime in the future, we could the advertise the support as an extension in the ESNIKeys to instruct the clients that support that extension to send a CH extension that uses a different extension ID than the ESNI extension.
A lot of other TXT records have a version in them. It turns out that if you do that you can query for TXT records and get multiple answers back. Then, you pick those with the version you like. That's one query. I'm tempted to suggest that the first octet (or two) be used for a version number. It's cheap.
I'm concerned about how we iterate on these in the field. They're not tied to TLS version, so what if we decide to change the formats, as we are discussing in
a magic number (including version) is a pretty decent idea. right now _esni is in its own namespace but you can imagine someone doing a txt record that applies to every dns response so we would want to disambiguate that as well. take note to update the "concat multiple records" rule if we go down this path..
I think that having version is a good idea in sense that it allows to do experiments before the standardization completes.

Revised text:
SNI Encryption keys can be published in the DNS using the ESNIKeys structure, defined below. <ins> The version of the structure.  For this specification, that value SHALL be 0x0000.  Clients MUST ignore any ESNIKeys structure with a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]] </ins> The first four (4) octets of the SHA-256 message digest RFC6234 of the ESNIKeys structure starting from the first octet of "keys" to the end of the structure. This structure is placed in the RRData section of a TXT record as a base64-encoded string.  If this encoding exceeds the 255 octet limit of TXT strings, it must be split across multiple concatenated strings  <ins> as per Section 3.1.3 of RFC4408.  Servers MAY supply multiple ESNIKeys values, either of the same or of different versions.  This allows a server to support multiple versions at once. </ins> The name of each TXT record MUST match the name composed of _esni and the query domain name.  That is, if a client queries example.com, the