skip to content

With every DNS cache empty, which servers take part in resolving www.example.com, and in what order is each one asked?

level: juniorimportance: must knowfreq 78%

answer

  1. one question, several askers
  2. the host hands the work off
  3. start at the top of the tree
  4. each level names the next
  5. only the last server answers

basics

~20 s

The stub resolver asks a recursive resolver; that resolver asks a root server, then a com server, then example.com's authoritative server. The first two refer it onward, the last answers, and the recursive resolver returns the address to the stub.

solid answer

~40 s

A cold-cache lookup involves four roles. The application calls the host's **stub resolver**, which sends a query with recursion desired to its configured **recursive resolver**. That resolver starts from its root hints: it asks a **root server** about `www.example.com` and gets a referral to the `com` servers; it asks a **`com` TLD server** and gets a referral to the name servers of `example.com`; it asks an **authoritative server for `example.com`**, which returns the `A` record with the AA bit set. The recursive resolver caches what it learned and hands the answer back to the stub. The stub sends one query per record type it needs and waits; the recursive resolver sends at least three, and more when a name server's address was not supplied and has to be resolved first.

go deeper

for a junior

Recall the four roles in order: stub, recursive resolver, then root, TLD and authoritative servers. Say that the first two servers refer and only the last one answers.

for a middle

Explain what a referral carries, why the walk must start at the root when nothing is cached, and why the stub never sees any referral.

for a senior

Show where a cold walk gets slower than three round trips: name servers without glue, an alias into another zone, or an unresponsive server costing a full timeout.

for a principal

Frame the design trade-off: the hierarchy keeps every zone small and independently operated, and the price is a multi-hop cold path that only caching makes cheap.

## The four roles in a lookup The Domain Name System splits the work of turning a name into data between parties with very different jobs. RFC 9499 gives the current vocabulary: | Role | What it does | Example in this lookup | |---|---|---| | **Stub resolver** | Cannot resolve on its own; forwards the question to a recursive resolver and waits | The resolver library on the user's laptop | | **Recursive resolver** | Pursues the question on the client's behalf, caches what it learns | The resolver the laptop is configured to use | | **Root server** | Authoritative for the root zone, which is mostly delegations to top-level domains | Any server listed for `.` | | **TLD server** | Authoritative for a top-level domain such as `com` | A server listed for `com` | | **Authoritative server** | Holds the zone that actually contains the name | A server listed for `example.com` | A name is read **right to left** for resolution: `www.example.com.` sits under `example.com`, which sits under `com`, which sits under the root (the empty label after the final dot). ## The walk, step by step Assume every cache on the path is empty and the user wants the IPv4 address of `www.example.com`: 1. The application calls the host's **stub resolver**, which sends one query (`www.example.com`, type `A`) to its recursive resolver with the **RD** (recursion desired) bit set. 2. The **recursive resolver** has nothing cached, so it falls back to its **root hints**: a configured list of root server names and addresses, used to learn the current root server set (RFC 9499 calls this **priming**). 3. It asks a **root server** for `www.example.com`. The root zone does not contain that name; it contains a delegation for `com`, so the root server returns a **referral**: the `com` NS records in the authority section and their addresses in the additional section. 4. It asks one of those **`com` servers** the same question. The `com` zone holds the delegation for `example.com`, so the reply is another referral naming the `example.com` name servers, with addresses for any whose names lie inside `example.com` (glue). 5. It asks an **authoritative server for `example.com`**. This server holds the zone that contains `www`, so it returns the `A` record with the **AA** (authoritative answer) bit set. 6. The recursive resolver caches the delegations and the answer, then sends the answer back to the stub, which hands the address to the application. The stub never sees steps 3 to 5. RFC 1034 section 4.3.1 says a server working in recursive mode returns "either an error or the answer, but never referrals". ## What each reply carries - **Root and TLD replies** answer nothing about `www.example.com`; they say "ask these servers next". Each one moves the resolver one zone cut closer to the name. - **The authoritative reply** is the only one that contains the requested record, and the only one flagged as authoritative for it. - **The same question** (`www.example.com`, type `A`) goes to every server in a traditional walk; QNAME minimisation (RFC 9156) changes that by sending each server only as much of the name as it needs. ## Why the order is top-down No server knows the whole namespace. Each zone only knows its own data and **where its children were delegated**. The root is the one starting point every recursive resolver is configured with, through its root hints, so a cold walk must begin there and descend one delegation at a time. Once the resolver has cached the `com` delegation, later lookups of other `com` names skip the root entirely; that cache behaviour is the subject of DNS caching and TTLs. ## Where a cold walk gets longer The three-hop walk is the best case. It grows when: - **A name server has no address in the referral.** If `example.com` were served by `ns1.example.net`, the `com` referral need not carry its address, and the resolver must first resolve `ns1.example.net` through the root and `net` servers. - **The answer is an alias.** A CNAME pointing into another zone makes the resolver restart at the target name, possibly with a second walk. - **A server does not respond.** RFC 1034 section 5.3.3 has the resolver cycle through the addresses of all listed servers with a timeout between tries, so one dead name server can add a full timeout. - **The zone is delegated deeper.** A name like `www.eu.example.com` can meet one more cut and one more referral. ## Summary Stub to recursive resolver, recursive resolver to root, TLD and authoritative servers, then back. The stub asks once; the recursive resolver does the walking; the root and TLD servers only point the way; the authoritative server alone answers.

  • Where does a recursive DNS resolver with an empty cache get the root servers' addresses?
    From configuration: a root hints list of root server names and addresses, usually shipped with the resolver software. It uses those to ask a root server for the current root NS set, which RFC 9499 calls priming, and caches the result. The hints only need at least one reachable root server to be correct.
  • Does a DNS root server know the address of www.example.com?
    No. The root zone holds the delegations to top-level domains, so a root server can only say which servers serve `com`. It answers from its own zone data without asking anyone else, which is why its reply is a referral rather than an answer.
  • Does the stub resolver ever see the referrals from the root and TLD servers?
    No. The stub sent a recursive query, and RFC 1034 says a server in recursive mode returns an error or the answer, never referrals. The referrals stay inside the recursive resolver, which caches the delegations so later lookups under `com` or `example.com` start lower in the tree.

saying these in an interview costs you the question

  • The laptop contacts the root servers itself on every lookup.
  • The root server forwards the query down to the com servers for you.
  • A com TLD server can return the address of www.example.com.
  • Resolution starts from the leftmost label, www, and works rightwards.
  • Even with warm caches every lookup walks root, then TLD, then authoritative.