Change:
Based on comments in Montreal, I believe that the authors no longer intend to document the partial-split configuration.

Discussion:
In Split Mode, the provider is _not_ the origin server for private domains.  Rather the DNS records for private domains point to the <del> provider, but the provider's server just relays the connection back to the backend server, which is the true origin server.  The provider does not have access to the plaintext of the connection.  In principle, the provider might not be the origin for any domains, but as a practical matter, it is probably the origin for a large set of innocuous domains, but is also providing protection for some private domains.  Note that the backend server can be an unmodified TLS 1.3 server. </del> <ins> provider, and the provider's server relays the connection back to the backend server, which is the true origin server.  The provider does not have access to the plaintext of the connection. </ins> 3.2.

therefore allow clients to detect and recover from this situation (see esni-resolution for more details). <del> Content providers operating in Split Mode SHOULD ensure that the A and AAAA records for ESNI-enabled server names do not allow identifying the server name from the IP address.  This can for example be achieved by always returning the same records for all ESNI-enabled names, or by having the function that picks addresses from a pool not depend on the server name.  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. </del> <ins> Content providers SHOULD ensure that the A and AAAA records for ESNI- enabled server names do not allow identifying the server name from the IP address.  This can for example be achieved by always returning the same records for all ESNI-enabled names, or by having the function that picks addresses from a pool not depend on the server name.  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. </ins> The following sections describe a DNS record format that achieve these goals.

7.5.7. <del> Assuming ESNI records retrieved from DNS are validated, e.g., via </del> <ins> Assuming ESNI records retrieved from DNS are authenticated, e.g., via </ins> DNSSEC or fetched from a trusted Recursive Resolver, spoofing a server operating in Split Mode is not possible.  See cleartext-dns for more details regarding cleartext DNS. <del> Validating the ESNIKeys structure additionally validates the public name.  This validates any retry signals from the server because the client validates the server certificate against the public name before retrying. </del> <ins> Authenticating the ESNIKeys structure naturally authenticates the included public name.  This also authenticates any retry signals from the server because the client validates the server certificate against the public name before retrying. </ins> 7.5.8.