How DNS Resolution Works, Step by Step

Before your device can connect to a website it has to turn the hostname into an IP address, and that lookup is a separate errand from the connection itself. It passes through a series of caches, then a resolver, then a chain of servers that each know a little more about where the answer lives.

Understanding the sequence matters for privacy because the lookup can take a completely different path from your actual traffic — which is how a VPN can be working correctly while your name lookups go somewhere else entirely.

The caches come first

Nothing queries the network until the local caches have been checked.

The application’s own cache. Browsers keep a short-lived internal cache of hostname-to-address mappings, separate from the operating system’s.

The hosts file. A plain text file on the machine that maps names to addresses directly. If an entry exists, it wins and no lookup happens at all.

The operating system cache. Answers from previous lookups, held for as long as the record’s time-to-live allows.

Only if all three miss does anything leave the device. This layering is efficient, and it is also why a configuration change can appear to have no effect until the caches expire — the reasoning behind flushing the DNS cache as a troubleshooting step.

The resolver does the actual work

Your device does not chase the answer itself; it asks a recursive resolver to do it. By default that resolver is whatever your router advertised when your device joined the network, which in turn is usually your internet provider’s.

The resolver has its own cache, shared across everyone who uses it, so popular names are answered instantly. When it does not have the answer, it walks the hierarchy on your behalf.

Which resolver you use is a consequential choice, because that server sees every name you look up. That is the subject of who runs your DNS resolver, and it is the single most important variable in the whole process from a privacy standpoint.

Walking the hierarchy

The resolver asks a chain of servers, each of which narrows the answer. For a name like example.com:

1. A root server is asked. It does not know about example.com, but it knows which servers are authoritative for .com and says so.
2. A .com server is asked. It does not hold the address either, but it knows which nameservers are authoritative for example.com.
3. The authoritative nameserver for the domain is asked, and it returns the actual address record.

The resolver caches each step, so the next lookup for anything under .com skips step one, and a repeat lookup of the same name skips everything.

Two details are worth noticing. The resolver may receive answers for both an old-style address and a newer IPv6 one, and your operating system typically prefers IPv6 when it looks usable — which is why IPv6 handling affects which family your traffic actually uses. And the whole chain is normally unencrypted unless you have specifically arranged otherwise.

Where the tunnel enters the picture

A VPN can carry your lookups or leave them behind, and both happen.

When it works properly, the VPN client replaces your system’s resolver settings with a resolver reachable only through the tunnel — often one the provider runs. Your queries travel inside the encrypted path, your provider sees an encrypted stream to the VPN server rather than a list of names, and the authoritative servers see the query arriving from the VPN’s resolver.

When it does not work properly, your queries go to the resolver your router advertised, in the clear, while your traffic goes through the tunnel. Your provider gets a complete list of the hostnames you visited even though it cannot see the traffic. That is a DNS leak, and it is a serious one, because the list of names is most of what people are trying to keep private.

The usual causes are an operating system that queries multiple resolvers in parallel, a client that sets the tunnel resolver but leaves the physical adapter’s in place as a fallback, or an application with its own resolver settings that ignores the system entirely.

What each participant learns

Being specific about who sees what is more useful than a general warning.

• Your resolver sees every name you look up, with timestamps, tied to whatever identifies you to it — your address, at minimum.
• Anyone on the network path to an unencrypted resolver sees the queries too, including the operator of a public Wi-Fi network.
• The root and top-level servers see only the portion of the name they are responsible for, plus the resolver’s address rather than yours — so they learn that someone using that resolver asked about .com, not who.
• The authoritative nameserver sees the full name and the resolver’s address. If you use a large shared resolver, your own address is not part of the query.
• The destination site learns nothing from the lookup; it only sees your connection when you make it.

That distribution is why the resolver choice dominates. Everything else in the chain sees either a fragment of the name or an address that is not yours.

The lookup is not the only name disclosure

Even a perfectly private lookup does not fully hide which site you visited. When your browser opens an encrypted connection, it usually names the host it wants in the opening handshake so the server knows which certificate to present, and that name has historically been sent before encryption begins. Anyone watching the connection can read it.

Inside a VPN tunnel this is not visible to your provider, because the whole conversation is encrypted. But it means DNS privacy and connection privacy are two separate problems, and solving one does not solve the other — the point developed further in what still names the sites you visit.

The practical takeaway

Treat name resolution as a separate system with its own path, its own cache, and its own failure modes. When a VPN behaves oddly, ask two questions rather than one: is my traffic going through the tunnel, and are my lookups going through it as well.

They are answered by different tests, they fail independently, and a clean result on the first says nothing at all about the second.