How a name resolves — Domain Security Fundamentals

How a name resolves

After this lesson you can

Trace a lookup from the root down and name what each step contributes.

Assumes you have read The hierarchy, and who the three parties are.

Nobody holds a copy of the whole DNS. A resolution is a walk down the tree, asking each level where to ask next, and understanding that walk is what lets you say which server is lying when an answer is wrong.

Two kinds of server

	Recursive resolver	Authoritative server
Job	Finds the answer on a client’s behalf, walking the tree.	Holds a zone’s data and answers for it directly.
Caches	Yes — that is most of its value.	No.
Examples	Your ISP’s resolver, 1.1.1.1, 8.8.8.8, your office resolver.	The nameservers listed for a domain.
Why you care	What it tells you may be stale.	It is the source of truth. Ask it when you need to know what you actually published.

The walk

For www.example.com, with nothing cached:

resolver -> a root server:   "who handles www.example.com?"
         <- "ask the com servers, here they are"

resolver -> a com server:    "who handles www.example.com?"
         <- "ask example.com's nameservers, here they are"

resolver -> example.com's NS: "who handles www.example.com?"
         <- "here is the A record"

Three round trips. Each upper level answers with a referral, not the answer.

Neither the root nor the com servers know anything about www. They know only who to ask next. The answer comes from the nameservers the domain’s registration points at, which is why controlling that pointer is the same as controlling the domain.

Watching it happen

dig +trace performs the walk itself, showing each step, instead of asking a resolver to do it:

$ dig +trace example.com

.                517409  IN  NS  a.root-servers.net.
.                517409  IN  NS  b.root-servers.net.
...
com.             172800  IN  NS  a.gtld-servers.net.
...
example.com.     86400   IN  NS  ...
example.com.     69      IN  A   104.20.23.154

Checked 2026-09-12, abridged. Each block is one level answering with a referral to the next.

This is the single most useful diagnostic command in DNS, because it shows you where an answer came from. A resolver gives you an answer; +trace gives you the provenance.

Thirteen root server addresses, far more machines

There are thirteen root server names because thirteen addresses was the most that fit in an early DNS response. Each name is served by many physical servers worldwide using anycast — the same address announced from many locations, with routing sending you to a near one. The thirteen is a protocol artefact, not a count of machines.

Answers that are not answers

NXDOMAIN — the name does not exist. An authoritative statement, and a cacheable one.
NOERROR with no answer — the name exists but has no records of the type you asked for. Different from NXDOMAIN, and telling them apart matters when diagnosing SPF void lookups.
SERVFAIL — the resolver could not produce a valid answer. Could be a broken server, could be a DNSSEC validation failure. The DNSSEC module returns to this.
REFUSED — the server declined to answer. Usually you asked a server about a zone it does not serve.

Last reviewed 2026-09-12