Here is the small deception the padlock icon performs every day. You type a domain, the browser negotiates a TLS session, the address bar goes green, and you get on with your life believing the whole transaction is private. The page contents are private. The fact that you asked for the page is not.
Before your browser can encrypt anything, it has to know where to send the traffic. That means asking a Domain Name System resolver — usually the one your internet provider hands you over DHCP — to translate example.com into an IP address. And that question, by default, goes out over UDP port 53 as plain text. Anyone sitting on the wire between your device and the resolver can read it. Your ISP certainly can, because it is the resolver. The IETF’s own analysis of the problem, RFC 7626, is blunt about it: nearly all DNS traffic is sent in the clear, and the single best place to eavesdrop is precisely the stretch between your device and the resolver (RFC 7626).
So HTTPS solves a specific problem — the content of your session — and leaves an older one intact. The metadata leak isn’t a bug in TLS; it’s a layer TLS was never designed to cover.
It gets worse when you look at what a resolver log actually contains. Every domain you touch. Every background sync from an app you forgot you installed. Every tracker pixel embedded in an email preview. Every smart bulb phoning home. The Electronic Frontier Foundation has warned that unencrypted metadata like this gives ISPs the raw material to build detailed profiles of their users, and domain names are semantically rich in a way that IP addresses are not. Seeing that you connected to 172.217.x.x tells someone very little. Seeing that you resolved plannedparenthood.org, then aa.org, then a job board at 2am tells them a story.
People assume a VPN fixes this. Sometimes it does. Often it just moves the problem. If your VPN client hands DNS queries to the tunnel’s own resolver, then yes, your ISP is out of the loop — but the VPN provider now sees everything the ISP used to. And plenty of setups leak. Mullvad keeps a running guide to DNS leaks that catalogues the ways an operating system, browser, or security tool can end up routing queries to a resolver outside the tunnel, including several Windows-specific culprits. The padlock is still green. The leak is invisible.
The fix the industry landed on is to encrypt DNS itself. DNS over HTTPS (DoH), specified in RFC 8484, wraps each query in a normal-looking HTTPS request to a resolver like Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8. DNS over TLS (DoT), from RFC 7858, does the same thing over a dedicated port. Firefox began rolling DoH out by default to US users in 2020, and Chrome, Edge, and both major mobile operating systems now support one flavour or the other. Turn it on and your ISP stops seeing the domain names. That’s a real improvement.
It is not, however, total privacy, and this is where the padlock myth simply reappears one level up. Two other leaks still exist even with encrypted DNS.
The first is the Server Name Indication field. When your browser opens a TLS connection to a server that hosts many sites — which is most of the modern web — it has to say which hostname it wants a certificate for. Historically that hostname went across the wire in the clear at the very start of the handshake, before encryption kicked in. So even with DoH on, a network observer could read the SNI and know you were fetching somebank.com. There is a fix, called Encrypted Client Hello, that Cloudflare and Mozilla have been pushing since the ESNI experiments in 2018 and which is slowly turning on in browsers. Coverage is partial. Assume for now that SNI is still readable on many of your connections.
The second is the IP address itself. Even if nobody sees your DNS query and nobody sees your SNI, your packets still have to be routed somewhere, and the destination IP is on the outside of every TLS packet. In the days when one server hosted one site, that IP was as good as a domain name. Today, with content delivery networks fronting huge fractions of the web, an IP might belong to Cloudflare or Fastly and reveal nothing specific. But for self-hosted services, small sites, or anything on a dedicated address, the IP alone still identifies the destination.
The honest summary, then, is that HTTPS does exactly what it claims and nothing more. It protects the payload. Around that protected payload sits a halo of metadata — DNS queries, SNI, destination IPs, timing, packet sizes — that leaks information about where you’re going without saying what you did there. Researchers have shown that even encrypted DNS traffic can be fingerprinted to reveal which sites you visit, using nothing but patterns in packet sizes and timing. Encryption of content is not the same thing as anonymity of behaviour.
What can you actually do about it? A few things, in rough order of effort. Turn on encrypted DNS in your browser or OS; Cloudflare, Quad9, and NextDNS all publish DoH and DoT endpoints, and the switch is usually one toggle in settings. Pick a resolver whose logging policy you trust more than your ISP’s — that’s the whole game, since you’re moving the metadata, not deleting it. If you use a VPN, test it for leaks with something like dnsleaktest.com rather than assuming the marketing page is correct. Enable Encrypted Client Hello where your browser exposes the option. For anything genuinely sensitive, use Tor, which was designed from the start to break the link between who you are and where you’re going.
None of this is exotic. It’s the sort of thing that got quietly built into infrastructure over the past decade because the original web protocols were designed in an era when nobody thought hard about metadata. Email had the same lineage — Ray Tomlinson picking the @ symbol in 1971 for the first networked message wasn’t sketching a threat model — and it took decades to bolt encryption onto SMTP. DNS is following the same arc, just slower and with less public attention, because most users have never heard of it and the padlock in the address bar keeps telling them everything is fine.
The padlock isn’t lying. It’s just answering a smaller question than the one you thought you asked.
— Justin
