Two standards that overlap with what VPNs are sold for
VPN marketing often claims to hide the sites a person visits from the local network. Two Internet standards address parts of the same problem without a VPN: DNS over HTTPS (DoH) in RFC 8484, published in 2018, and Encrypted Client Hello (ECH) in RFC 9849, a Standards Track document dated 2026. This article summarises what each document says it protects, and what the documents say remains visible. Both are IETF standards, so they describe protocol behaviour and not any product or provider. The article does not cover how widely browsers or sites have deployed them. It is technical information for a general reader.
What TLS 1.3 leaves visible
RFC 9849 begins from the position that, although TLS 1.3 encrypts most of the handshake, including the server certificate, an on-path attacker can still learn private information about the connection. It says the plaintext Server Name Indication (SNI) extension in ClientHello messages, which leaks the target domain of a connection, is perhaps the most sensitive information left unencrypted in TLS 1.3.
That matters for the common statement that HTTPS already hides what a person does online. According to RFC 9849, the destination domain can still leak through the SNI field, so a network observer may learn which site a person is connecting to even when the content of the page is encrypted.
What Encrypted Client Hello does
ECH lets a client encrypt its ClientHello to the TLS server, which protects the SNI and other potentially sensitive fields such as the Application-Layer Protocol Negotiation list. The RFC describes an anonymity set formed by co-located servers with consistent externally visible TLS behaviour. Using ECH reveals that a client is connecting to a particular service provider, but does not reveal which server in the set terminates the connection.
The RFC is clear about the limits. It says ECH is not in itself sufficient to protect the identity of the server, because the target domain may also be visible through plaintext client DNS queries or visible server IP addresses. It notes that encrypted DNS mechanisms, including DNS over HTTPS, DNS over TLS and DNS over QUIC, let clients conceal DNS lookups from network inspection, and that many TLS servers host multiple domains on one IP address. In environments where private origins sit behind a common provider, the SNI remains the main signal for observers.
What DNS over HTTPS does
RFC 8484 defines DoH as sending DNS queries and responses over HTTPS, so that TLS provides integrity and confidentiality. It names two primary use cases: preventing on-path devices from interfering with DNS operations, and letting web applications access DNS information through browser APIs. On privacy, it says DoH encrypts DNS traffic and requires authentication of the server, which mitigates passive surveillance and active attacks that divert DNS traffic to rogue servers. It adds that using the HTTPS port 443 and mixing DoH with other HTTPS traffic can deter on-path devices from interfering and make traffic analysis more difficult.
What stays visible: the server and the address
RFC 8484 also covers privacy “in the server”. It says the client’s IP address provides obvious correlation information, and that this can be mitigated by a NAT, proxy, VPN or address rotation over time. It says the problem may be aggravated when a DNS server and a DHCP server are run by the same entity, because addressing information can be correlated with personal identifiers. It also notes that HTTP features such as cookies, request headers and session resumption can be used to link queries to an identity.
The DNS resolver chosen therefore matters. The resolver operator sees the queries, and the resolver still sees the client address unless something masks it. RFC 8484 says DoH is not known to introduce new concerns beyond those of HTTPS.
Where a VPN differs
The two standards work at the level of individual protocols, protecting DNS lookups and the TLS handshake. A VPN works differently: it carries the device’s traffic to the VPN server through an encrypted tunnel, so the local network sees a connection to the VPN server rather than to each site. The RFC 8484 text cited above confirms that a VPN is among the ways to address the client-address problem. Neither RFC evaluates commercial VPN providers or their practices, and neither says a VPN is required or sufficient.
A person using DoH and ECH without a VPN still shows the destination IP address to the local network and to the ISP, and the destination still sees the person’s IP address. A person using a VPN without encrypted DNS depends on the VPN app to send DNS through the tunnel, which is the issue the site’s article on DNS leaks covers. A VPN also changes who can observe the traffic: the provider sits in the path, which is why the claims about logging discussed in the audit article matter.
The bottom line
RFC 9849 says that the destination domain in TLS 1.3 is visible through the SNI field unless ECH is used, and that ECH alone does not protect the server’s identity if DNS lookups or IP addresses expose it. RFC 8484 says DoH encrypts DNS traffic between client and resolver, while the client address remains visible to the resolver unless masked by, among other things, a VPN. The standards and VPNs address overlapping problems in different ways, and neither replaces the other.