Follow a DNS lookup

Let’s follow one lookup from start to finish. A resolver needs the address of www.example.com, and its cache is empty.

Your laptop doesn’t do the full search. It has a tiny stub resolver that hands the question to a recursive resolver and waits for the final answer. The recursive resolver does the walking.

The referral chain

With nothing cached, the recursive resolver asks in three steps:

1. It asks a root server. The root doesn’t know www.example.com. It answers “ask the com nameservers, here they are.”
2. It asks a com nameserver. That server doesn’t know the address either. It answers “ask the example.com nameservers.”
3. It asks an example.com nameserver. This one is authoritative, so it returns the actual record.

Each answer that says “go ask someone else” is a referral. The root and the TLD servers delegate. They don’t store every address on the internet. They only know who to send you to next.

Glue records

A referral carries NS records, the names of the next servers to ask. Sometimes it also carries glue: the IP addresses of those servers.

Why? Suppose the nameserver for example.com is ns1.example.com. To find its address you’d have to ask… ns1.example.com. That’s a loop. Glue breaks it by putting the address right in the referral.

Glue helps the lookup continue. It’s not the website answer.

When the name is an alias

If www.example.com is a CNAME, the resolver isn’t done yet. It has to resolve the target name too, possibly in a different zone.

Notice one thing here. The authoritative DNS server is not the web server. Authority means “who publishes the DNS data”, nothing more.

Watch it happen

dig can perform this walk itself instead of asking your resolver:

dig +trace www.example.com A

You’ll see the root servers first, then the com servers, then the example.com servers, then the answer. Each block of output is one step of the chain.

Try this on a hostname you use. Find the root referral, the TLD referral, the authoritative nameserver, and the final answer or alias.