Articles / Privacy

866 words

  • dns
  • privacy
  • https
  • metadata
  • dns-over-https
  • networking

What Your DNS Resolver Sees Even When the Page Is HTTPS

The padlock in your browser covers the conversation with the web server. It does not cover the question you asked just before it: "where is this site?" That question goes to your resolver, usually in plain text, and it contains the hostname.

So a resolver can build a fairly complete diary of your browsing without ever touching an HTTPS connection. Here is what is in that diary, why it is richer than most people assume, and which parts you can shrink.

Watch it happen on your own machine

Run a capture in one terminal and a lookup in another:

sudo tcpdump -ni any -A port 53
dig example.org AAAA

With classic DNS over UDP port 53, the capture shows example.org in readable form, in both the query and the reply. Anyone on the path between you and the resolver sees the same thing, not just the resolver.

What is in a single query

A query is small, but it carries more than a name. The resolver gets:

  • the full name you asked for, such as mail.example.org
  • the record type, which hints at intent (MX suggests mail, HTTPS suggests a browser wants connection hints)
  • your source IP address, because that is where the reply goes
  • the time, to the millisecond
  • optional EDNS extras, such as a client subnet

The name is the whole point. The path and query string of a URL never reach DNS, but the hostname often says nearly as much. A lookup for a clinic, a union, a support forum or a dating site tells the story on its own.

One page load is many lookups

You rarely ask for one name. A single page pulls in fonts, scripts, images and analytics, each from its own hostname, and the browser resolves them all within a second or so.

That burst is a fingerprint. Even if you ignored the names, the pattern of "these six hostnames, together, in this order" tends to identify a specific site or page. Quick detour on why that matters: it means hiding one name does not hide the visit if its companions are still visible.

Quick detour: the cache is not a shield

Hang on, doesn't caching mean the resolver only sees each name once? Partly. A shared resolver caches answers for the record's TTL, so repeat lookups inside that window are answered locally.

But the cache sits at the resolver, and the resolver is the party you are worried about. It sees every query that reaches it, and a cache hit still arrives as a query first. Your own browser and operating system caches are what actually reduce what leaves your machine.

The upstream leak: client subnet

Your resolver usually does not know the answer, so it asks authoritative servers on your behalf. That could be a second place your information leaks, and it is the part most people never think about.

EDNS Client Subnet (RFC 7871) lets a resolver attach a truncated version of your address, commonly a /24 for IPv4, so a CDN can pick a nearby server. It is optional, and resolver operators differ on whether they send it. If you care, check your provider's documentation rather than assuming.

What reduces the exposure

  • Encrypted transport: DNS over TLS or DNS over HTTPS (RFC 8484) hides queries from the network path. It does nothing about the resolver itself, which still sees everything.
  • QNAME minimisation (RFC 9156): the resolver sends only the labels each upstream server needs, so the root and TLD servers see .org rather than mail.example.org.
  • Choosing who the resolver is: your ISP, a public provider, or one you run yourself. This decides who holds the diary.
  • Padding: EDNS padding evens out message sizes, which makes length-based guessing on encrypted DNS harder.

If you self-host, you can run a recursive resolver such as Unbound at home. Then no single third party sees your whole list of names; instead, each authoritative server sees only the part relevant to it. The catch is that your home IP address now appears directly to those servers.

What encryption still leaves visible

Encrypted DNS closes one door, not all of them. After the lookup, you connect to an IP address, and that address often identifies the site, especially if it is not shared with thousands of others.

The TLS handshake can also carry the server name in the clear, via SNI, unless Encrypted Client Hello is in use. Hiding the DNS query while sending the name in the handshake is a bit like whispering your destination to the taxi controller and then shouting it to the driver.

A fair summary of the trade

You are not removing the observer; you are choosing one. Moving from your ISP to a public resolver changes who sees the diary, and may change what they are permitted or inclined to do with it. That is a policy question, so read the provider's privacy statement rather than guessing.

For most people, the sensible move is cheap: encrypt the transport, pick a resolver deliberately, and know that the name still leaves your device in some form. The page may be HTTPS, but the address book lookup was never part of it.

← All articles