How a DNS lookup travels from root to answer

On a cache miss, a recursive resolver can follow the DNS hierarchy from the root toward the server authoritative for the queried name. The root server does not normally return the website address; it returns a referral that helps the resolver take the next step.

The actors

• A stub resolver is the client-side component that asks a recursive resolver for an answer.
• A recursive resolver performs resolution for the client and caches responses.
• An authoritative server serves data for a zone and answers from that authority.
• A referral points the resolver toward servers for a delegated child zone.

These roles are defined by DNS architecture and current DNS terminology [1] [2].

A complete cache-miss path

Suppose a client needs the A record for www.example.com. A simplified iterative path is:

1. Client to recursive resolver. The stub sends one recursive query to its configured resolver.
2. Cache check. The resolver checks whether it already has a usable positive or negative cached response. If it does, the hierarchy may not be queried.
3. Root query. On a cold cache, the resolver asks a root server. The root zone refers it to authoritative servers for com.
4. TLD query. The resolver asks a com server. The com zone refers it to the authoritative servers for example.com.
5. Authoritative query. The resolver asks an example.com authoritative server for www.example.com type A.
6. Answer processing. The server returns an answer, an alias that requires more resolution, a referral, or a negative response.
7. Validation and caching. A validating resolver checks DNSSEC where applicable and caches eligible data according to DNS rules and TTLs.
8. Response to the client. The recursive resolver returns its result to the stub.

This is a mental model, not a promise that every query creates exactly three upstream packets. Cached referrals, multiple addresses, retries, aliases, qname minimisation, DNSSEC records, transport fallback, and local policy can change the observed exchange.

Root servers are a distributed service

The root zone is served as 13 named authorities, from a.root-servers.net through m.root-servers.net. Those identifiers represent a network of many server instances operated in many locations, not 13 physical machines [3].

Recursive resolver software uses root hints to bootstrap contact with the root service. It does not download a universal final answer from a central DNS database.

Referrals move down the namespace

A referral says, in effect, “ask the servers authoritative for the delegated child.” For www.example.com, the path moves from:

.  →  com.  →  example.com.  →  www.example.com.

The parent publishes the child delegation. The child authoritative service publishes records within its zone. Comparing these two viewpoints is essential when nameserver changes fail.

The final response may not be an address

The authoritative response can contain:

• the requested RRset;
• a CNAME or another form of aliasing that requires additional work;
• a referral to a deeper delegated zone;
• NXDOMAIN, meaning the queried name does not exist in that DNS context; or
• a no-data response, meaning the name exists but lacks the requested type.

SERVFAIL is different: it indicates that the resolver could not complete the request successfully. DNSSEC validation failure is one possible cause, not the only cause.

Cache observations are scoped

A TTL limits how long eligible data may remain in a cache; it is not a global countdown shared by the Internet. Different resolvers can cache an answer at different times. They can therefore refresh at different times.

When recording a lookup, include:

• exact query name, class, and type;
• resolver or authoritative server queried;
• response code and answer;
• TTL at observation time; and
• observation timestamp.

One resolver’s response is evidence from that resolver at that time. It is not a global propagation percentage.

Follow the evidence

If the recursive answer is surprising, compare it with the authoritative answer. If the authoritative answer is wrong, inspect the DNS host. If the parent referral is wrong, inspect the registrar or registry path. If DNS is correct, move to the next protocol layer rather than changing DNS again.

Next step

Explore the three bundled cache states in the root-to-answer path lab, then compare recursive resolvers and authoritative servers without treating either one as “the DNS server.”