Recursive resolution - how a name becomes an IP

When you query your local resolver for a name, it does not know the answer. It walks a chain from the root servers down to the authoritative answer. Understanding this chain - and being able to observe it - is the foundation of DNS diagnosis.

The hierarchy

                . (root)
                |
       +--------+--------+
       |        |        |
      com      net      org    (TLDs)
       |
   +---+---+
   |       |
example  shopify   (second-level domains)
   |
   |
www       api      (hosts)

There are 13 logical root servers (a.root-servers.net through m.root-servers.net), each with many physical instances operated by different organisations (Verisign, Cogent, etc.). They serve the TLD list.

Two query types

Iterative query: “give me what you have, or tell me who to ask next”. The server returns either the answer or a referral to a more specific server. This is what resolvers use.

Recursive query: “find the answer and bring it back”. The server does all the work. This is what clients use to talk to their recursive resolver.

The split exists because end-client machines do not have the state to do iterative resolution; recursive resolvers do.

Walk the chain

When the resolver receives www.example.com:

1. Query a.root-servers.net for www.example.com
   Reply: "I do not know, but ask the .com servers: a.gtld-servers.net"
2. Query a.gtld-servers.net for www.example.com
   Reply: "I do not know, but ask example.com\'s servers: ns1.example.com"
3. Query ns1.example.com for www.example.com
   Reply: "www.example.com is an alias for example.com.
           example.com has address 93.184.216.34"

The resolver caches each response (for the TTL of the response). Subsequent queries for example.com are answered from cache.

Observe with dig +trace

dig +trace www.example.com

Output:

; <<>> DiG 9.18.24 <<>> +trace www.example.com
;; global options: +cmd
.            3600    IN    NS    a.root-servers.net.
.            3600    IN    NS    b.root-servers.net.
...
com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
...
example.com.    172800    IN    NS    ns1.example.com.
example.com.    172800    IN    NS    ns2.example.com.
...
www.example.com.    300    IN    A    93.184.216.34

The output shows every step:

1. The root servers (the . records).
2. The TLD servers (the com. records).
3. The authoritative servers for example.com.
4. The answer for www.example.com.

If any step is slow, the chain is slow. dig +trace shows where.

Observe the round trips

dig +trace +stats www.example.com

The +stats option shows timing for each query.

Common patterns

Slow upstream: if the resolver has a slow link to the root or TLD servers, every first-time lookup is slow. Fix: use a resolver closer to the host, or one with good peering (Google, Cloudflare, your ISP).

CNAME chain: www.example.com may be a CNAME to example.com, which is a CNAME to something.example.net. The resolver follows the chain and reports the final answer. Long chains slow down resolution and increase cache load.

Missing glue records: the TLD servers return NS records without the corresponding A records (glue). The resolver has to make an extra query to resolve the NS name. Most authoritative servers publish glue to avoid this.

Caching and TTL

Each record in the chain has a TTL. The resolver caches for the TTL. Common TTLs:

A TTL change in the authoritative zone does not propagate instantly. Existing caches serve the old TTL.

Negative caching

When a name does not exist (NXDOMAIN), resolvers cache the “non-existence” for a shorter TTL (the SOA record’s MINIMUM field). This is called negative caching. It prevents overloading authoritative servers with repeated queries for non-existent names.

dig +trace nonexistent.example.com

The chain returns NXDOMAIN, and the resolver caches it.

Operational concerns

• Resolver location: a recursive resolver on the same network as the host (e.g. the company DNS) is faster than reaching Google over the internet.
• Resolver redundancy: configure at least two. If one fails, the other continues serving.
• Resolver capacity: a resolver that is slow or overloaded becomes a bottleneck for the whole network.
• Privacy: queries to public resolvers (Google, Cloudflare) leak your DNS activity. For sensitive workloads, use an internal resolver or DNS-over-TLS.

Knowledge check