For context: SNI is a header in the TLS session which indicates which service you intend to communicate with on the other side. Why? Usually, you reach a reverse proxy and firewall) terminating the TLS connection on the publicly-routable IP of the remote server, and from there follow a route on a local network unencrypted.

However, in some situations it’s not very practical for your architecture, and you have a single public IP for many services/servers each with their own domain names and TLS keys, so you need to be able to route the TLS traffic to its intended destination. That’s why your browser sends a “SNI” header indicating it would like to reach “foobar.com”, and that header is not encrypted because it’s meaningful before the TLS connection is terminated.

Lately, there’s been a push for encrypted SNI. The idea is by establishing an encrypted session with the reverse proxy specifically for SNI-based proxying, that header can be concealed to its intended destination without being readable by any person-in-the-middle on the network.

If you’re looking for an anti-tampering mechanism, DNSSEC signatures is what you’re looking for. DNS Over HTTPS establishes a “reasonably-secure” [1] connection to the DNS resolver. Not accounting for [1], that resolver (Cloudflare or other) can still lie to you consciously, or propagate unconsciously a malicious answer it received, because recursive resolution (i believe) still has no standard for secure transport: DNS over TLS is slowly getting traction, but it’s far from deployed on every primary nameserver.

[1] HTTPS is somewhat-secure because it’s an effective defense against script kiddies and malicious ISPs. However, it’s a very weak threat model where dozens of actors (the Certificate Authorities) can impersonate (almost) any server. And they do just that. It’s crazy how many CAs over the years have been caught misbehaving, often with little consequence except in the most egregious cases where Mozilla/Google pushed for their revocation as part of BrowserCA.