03 · How a DNS lookup works, step by step

You type www.your-website.com and press enter. Before the first byte of the page comes back, four or five different machines have answered questions about that name. This note follows the whole sequence once, slowly, then shows it happening in a real dig +trace.

Part three of the Learn DNS series. It assumes you have read part two: root, TLD, apex, subdomain.

The five roles

• Stub resolver - the tiny client built into your operating system. It does no walking; it asks one server and waits.
• Recursive resolver - the workhorse. Your ISP runs one; so do 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google). It does the walking and keeps a cache.
• Root servers - know where every TLD lives, nothing more.
• TLD servers - one set per TLD (the .com servers, the .uk servers). Know which nameservers each registered domain is delegated to.
• Authoritative servers - the nameservers you chose for your-website.com. Hold the actual records.

The sequence, on a cold cache

1. Stub asks the recursive. Your OS reads its configured resolver (from DHCP, /etc/resolv.conf, or a VPN), and sends it one question: "A record for www.your-website.com?" with the recursion desired flag set. Then it waits for a single final answer.
2. Recursive checks its cache. If it already has a non-expired answer - or even a non-expired "where are the .com servers" referral - it uses that and skips ahead. On a truly cold cache, it starts at the top.
3. Recursive asks a root server. "Where is www.your-website.com?" The root does not know, and does not try. It returns a referral: the NS records for com and their addresses (this is glue). In effect: "I don't know, but ask the .com servers."
4. Recursive asks a .com server. Same question. The .com server does not have the address either, but it knows the delegation: it returns the NS records for your-website.com - your chosen authoritative nameservers - plus glue if needed. Another referral, one level down.
5. Recursive asks your authoritative server. This one has the zone. It answers with the A record and a TTL, and sets the aa (authoritative answer) flag. This is the first reply in the chain that is an answer rather than a referral.
6. Recursive caches everything and replies. It stores the final record and every referral it collected along the way, each with its own TTL, then hands the stub the answer it has been waiting for. The stub passes it to the browser, which opens the connection.

On a cold cache that is four round trips out to the internet. Warm, it is often zero - the recursive already had the answer, and step 2 was the whole story. Most real lookups land somewhere between: the root and TLD referrals are cached (they change rarely), only the final authoritative hop is actually made.

Iterative vs recursive, in one line

Your stub makes a recursive query - "get me the final answer, do whatever it takes". The resolver then makes iterative queries outward - "just tell me the next step" - to the root, the TLD, and the authoritative server in turn. Doing that iteration on your behalf, and caching the result for everyone else it serves, is the recursive resolver's entire job.

A modern refinement is QNAME minimisation: instead of sending the full www.your-website.com to the root, the resolver asks the root only about com, asks the .com servers only about your-website.com, and sends the full name just to the authoritative server. The upstream servers only ever learn the part of the name they are responsible for.

Watch it happen

dig +trace makes the resolver's iterative walk visible - it does the referrals itself instead of asking one recursive resolver:

dig +trace www.your-website.com

The output comes in blocks, one per level. Trimmed to the essentials:

# 1. the root, reached via a root hint. It answers with the .com delegation.
com.        172800  IN  NS  a.gtld-servers.net.
com.        172800  IN  NS  b.gtld-servers.net.
;; Received ... from 198.41.0.4#53(a.root-servers.net) ...

# 2. a .com server. It answers with your-website.com's delegation.
your-website.com.   172800  IN  NS  ns1.exampledns.net.
your-website.com.   172800  IN  NS  ns2.exampledns.net.
;; Received ... from 192.5.6.30#53(a.gtld-servers.net) ...

# 3. your authoritative server. This block has the answer, not a referral.
www.your-website.com.   300  IN  A   203.0.113.10
;; Received ... from 198.51.100.53#53(ns1.exampledns.net) ...

Two things to notice. The referral TTLs are 172800 - 48 hours - so a resolver that has walked this path once will not re-ask the root or .com for two days. The final A record TTL is 300 - five minutes - because that is what the zone owner set, and it is the value that governs how quickly an edit to that record is seen.

What each cache means for propagation

Every hop in that walk is cached independently, on every recursive resolver, with its own timer:

• Change your nameservers and the stale thing is the .com-level referral - up to 48 hours in caches that already had it.
• Change an A / MX / TXT record and the stale thing is that record, bounded by its own TTL - the 300 above.

A change is only "done" everywhere once the relevant cache entry has expired on every recursive resolver a visitor might use. A single dig from your laptop only ever tells you about one resolver. That is exactly why checking propagation properly means asking many resolvers from many places at once - what the monitor on this site does - and why the command-line version queries the authoritative server directly to see the change before any cache reflects it.

Common surprises

• No aa flag in a dig answer means you are talking to a cache, not the authoritative server. Query the nameserver directly (dig www.your-website.com @ns1.exampledns.net) to get the authoritative view.
• Negative answers are cached too. Ask for a name that does not exist and the NXDOMAIN is remembered for the duration set by the zone's SOA - which is why a record you just created can still look missing for a few minutes.
• A CNAME is a second lookup. If www.your-website.com is a CNAME to cdn.example.net, the resolver has to go resolve that name too, walking its delegation from the root.
• Serve-stale. If your authoritative servers are unreachable, many resolvers will keep handing out the last known answer past its TTL rather than fail. Good for resilience, occasionally confusing during a migration.

The shape of it

• Stub → recursive → (root → TLD → authoritative) → cache → you.
• Root and TLD answers are referrals ("ask down there"); only the authoritative server gives an answer, with the aa flag.
• The recursive resolver does the iteration and caches every hop, each on its own TTL.
• You only ever measure one resolver at a time - which is why a global picture needs many vantage points.

That closes the three-part foundation. The series continues with the record types themselves - A, CNAME, MX, TXT, NS - and with TTL strategy for a clean migration.