How a DNS lookup actually works

24 August 2026 · Grace

Most DNS problems are easier to diagnose once you can picture where an answer comes from. The path is short, it is the same every time, and almost every failure you will meet belongs to one specific step on it.

The four places an answer can come from

When something asks for www.example.com, the lookup walks outwards, stopping at the first place that already knows:

1. The application's own cache. Browsers keep their own, independently of the operating system, and often for longer than you expect.
2. The operating system's cache. One per machine, shared by everything on it.
3. The recursive resolver. Your ISP's, or one you chose — 1.1.1.1, 8.8.8.8, or one your company runs. This is the one doing the real work.
4. The authoritative nameservers. The servers that hold the zone. They are the only place the answer genuinely lives; everything else is a copy with an expiry date.

If any of the first three has a fresh copy, nothing further happens. That is the whole reason a change you just made is not visible yet.

What the resolver does when nothing is cached

The resolver does not know where example.com lives. It finds out by asking down the tree, one label at a time.

It asks a root server. There are 13 root server identities — letters A through M — served from a great many physical machines worldwide. The root does not know about example.com. What it knows is who runs .com, so it answers with a referral: ask these servers instead.

It asks a .com nameserver. The TLD does not know the addresses in your zone either. It knows which nameservers you delegated the domain to, so it returns another referral — the NS records for example.com.

This is the delegation. It lives in the parent zone, at the registry, and it is what your registrar changes when you switch DNS provider. It is not in your zone, which is why you cannot edit it from your DNS panel.

It asks one of your nameservers. These are authoritative: they hold the zone and answer from it rather than referring. Back comes the A record, with a TTL.

The resolver caches the answer for the length of that TTL, and hands it back. The next person asking the same resolver gets it immediately.

Why this matters when things break

Each step has its own characteristic failure, and knowing the shape tells you where to look.

SERVFAIL is worth dwelling on because it is so often misread as "the server is down". It usually means the resolver did get an answer and refused to use it — most commonly because DNSSEC validation failed. A domain whose DS record no longer matches its keys is the classic cause, and it is the reason a DNSSEC-signed domain must never be migrated casually.

Asking each step yourself

You can query any level directly, which turns guessing into checking:

dig +trace www.example.com

That walks the whole path and prints every referral, so you can see exactly where it stops. To skip straight to the truth — the authoritative server, bypassing every cache:

dig www.example.com @ns01.example-dns.com

If that returns the right answer and a public resolver does not, you have a caching question and the only cure is time. If the authoritative server itself is wrong, no amount of waiting will help.

Two things people assume that are not true

"DNS is slow." An uncached lookup is a handful of round trips, typically tens of milliseconds. A cached one is microseconds. What is slow is a failing lookup, because the resolver waits for timeouts before giving up — which is why a broken secondary nameserver feels like a slow site rather than a broken one.

"My domain is down." Usually it is not. The zone is fine, the nameservers are answering, and something one layer up — an expired registration, a changed delegation, a DNSSEC mismatch — means resolvers never reach them. Checking dig +trace tells you which, in about ten seconds.

Once the path is familiar, most DNS incidents stop being mysterious and become a question of which step to check first.