Resolving a Name, Step by Step

The question you never see being asked

In the last two guides you learned why the DNS exists — names are kind to humans, addresses are kind to routers — and how its names are organized into a tree: a root at the top, top-level domains like com and org beneath it, and below those the authoritative servers that hold the real answers for each zone. That gives you a map of the territory. This guide is about the journey: when you type www.example.com, who actually walks that tree, and in what order, to come back with an address like 93.184.216.34?

Here is the surprising part. Your laptop, your phone, the browser itself — none of them do this walking. They are too small and too forgetful to know the whole tree. Instead they hand the whole problem to a single helper and wait for one tidy answer. That helper is the resolver (often called the recursive resolver), and understanding the division of labour between you and it is the key that unlocks everything else in this guide.

Recursive versus iterative: two kinds of asking

There are two ways to ask a question, and DNS uses both — at different points in the same lookup. The first is the recursive query: 'Go and get me the full answer; do not come back until you have it.' This is what you do to your resolver. You ask it for www.example.com and you expect a finished address in return, not a hint or a referral. It is like asking a diligent librarian for a fact and trusting them to do whatever digging it takes while you wait at the desk.

The second is the iterative query: 'Tell me what you know, even if it is only where to ask next.' This is what the resolver does to the servers up in the tree. When the resolver asks a root server about www.example.com, the root does not know the answer and does not go find it. It simply replies, in effect, 'I don't know, but here are the servers responsible for com — go ask them.' That reply is called a referral. The resolver takes the hint, walks one step down the tree, and asks again.

So the labour splits cleanly. You make one recursive request and then relax. The resolver, to honour that request, runs a patient chain of iterative queries on your behalf — root, then TLD, then authoritative — each one handing back not the answer but a pointer to the next place to look. The resolver does the legwork precisely so your device does not have to. That single design choice is why a tiny phone can resolve a name on the far side of the planet without knowing anything about the tree's shape.

Tracing one lookup, root to authoritative

Let us follow a single fresh lookup all the way down, assuming the resolver has no useful memory yet (we will fix that assumption in a moment, because in real life memory changes everything). Watch how the name www.example.com is read right-to-left, one label at a time, with each server handing the resolver one step closer to the answer.

1. Your browser asks the operating system, which asks your configured resolver, one recursive question: 'What is the address of www.example.com?' Then you wait.
2. The resolver asks a root server. The root reads the rightmost label and replies with a referral: 'For anything ending in com, ask these TLD name servers.' It gives their names and addresses (this is the NS information you will meet next guide).
3. The resolver asks one of the com TLD servers. It does not know the final address either, but it knows who runs example.com, so it refers the resolver down again: 'For example.com, ask these authoritative name servers.'
4. The resolver asks an authoritative server for example.com. This server actually holds the zone's records, so it gives a real answer at last: 'www.example.com is 93.184.216.34.' This is the bottom of the climb.
5. The resolver hands that finished address back to your operating system, which gives it to your browser. Only now does your browser open a connection to 93.184.216.34. The whole tree-walk was invisible to you.

  YOU --(recursive: "www.example.com?")--> RESOLVER

  RESOLVER  --iterative-->  ROOT server
            <--referral---  "ask the .com servers"

  RESOLVER  --iterative-->  .com TLD server
            <--referral---  "ask example.com's servers"

  RESOLVER  --iterative-->  example.com AUTHORITATIVE
            <--answer-----  "www.example.com = 93.184.216.34"

  RESOLVER --(answer: 93.184.216.34)--> YOU

Why this does not melt the root servers

Your first honest reaction to that trace should be alarm. Billions of lookups happen every minute. If each one really started by pestering a root server, the root would be the busiest, most overloaded machine in history. The reason it is not is the single most important idea in making DNS work at planetary scale: caching. The resolver remembers every answer and every referral it learns, for a while, and reuses them instead of asking again.

Walk the trace again, but as the second visitor of the day. The resolver already learned, from someone earlier, which servers run com — so it skips the root entirely and goes straight to the com TLD. If it also still remembers example.com's authoritative servers, it skips the TLD too. And if it cached the final address itself only minutes ago, it answers you immediately without leaving home at all. The cold, full root-to-authoritative walk is the rare case; warm, partial lookups are the overwhelming norm. (How long each fact may be cached is governed by a value called the TTL — the whole subject of the next guide, so we will leave the timer there.)

What you have, and what to watch out for

Step back and the whole mechanism fits in one sentence: you ask your resolver one recursive question, the resolver answers it by running iterative queries down the tree — root, then TLD, then authoritative — and caching plus anycast keep that from ever becoming slow or centralized. That is genuinely most of how a name becomes an address. The remaining guides only add detail: what kinds of records the authoritative server can return, how long answers live, and how to make the whole conversation trustworthy.

Two honest cautions before you climb on. First, none of this is secure by default. The referrals and the final answer arrive as plain, unsigned, unencrypted messages — usually over UDP for speed — so anyone on the path can read what names you look up, and a well-placed attacker could even forge a reply and send you to the wrong address. The resolver believes what it is told. Patching that gap is exactly what the final guide on DNSSEC and encrypted lookups is for; for now, simply hold the fact that the system you just learned is fast and scalable but trusting.

Second, do not confuse the resolver with the authoritative server. They sound similar but play opposite roles: the authoritative server is the one true source that owns a zone's records and never guesses, while the resolver owns no records at all — it merely fetches, caches, and re-serves what authoritative servers told it. The resolver works for you; the authoritative server works for the domain. Keep those two apart and the recursive-versus-iterative split, the caching, and even the security story all stay crisp in your head.