How DNS Resolution Works: Root, TLD, and Authoritative Servers

When you type a domain into a browser, a DNS resolver works out its IP address for you. Most of the time that happens in milliseconds and out of sight, often from a cache. A DNS trace slows the process down and shows each step: which server was asked, what it said, and where it pointed next.

In this guide: the players · the delegation chain · root servers · a real trace · anatomy of a DNS message · glue · CNAMEs · caching · trace vs. lookup · reading a trace · why answers vary · privacy and DNSSEC · troubleshooting · command line · FAQ

The Players in a Lookup

Four kinds of server take part, and it helps to keep them apart. Only the last one holds any records.

Two words describe how a query travels. A recursive query says "get me the final answer, whatever it takes": that is what your device sends to its resolver. An iterative query says "tell me what you know, or who to ask next": that is what the resolver sends to the root, TLD, and authoritative servers, and what a DNS trace sends too.

The Delegation Chain

DNS is a hierarchy, and no single server knows every answer. Each level only knows who to ask next:

• Root servers — 13 named server identities (a.root-servers.net through m.root-servers.net), each served from many machines worldwide. A root server does not know example.com, but it knows which servers run .com, and says so.
• TLD servers — the servers for a top-level domain such as .com, .org or .uk. They do not hold the domain's records either, but they know which nameservers the domain's owner delegated it to.
• Authoritative nameservers — the servers the domain owner (or their DNS provider) runs. They hold the real records and answer with the authoritative flag set.

A response that says "I don't know, ask these servers instead" is called a referral. Following referrals from the root to a final answer is what iterative resolution means, and it is what a DNS trace shows.

The Root Servers

The root zone (written .) sits at the top of DNS, and its nameservers are the root servers: thirteen named identities, a.root-servers.netthrough m.root-servers.net. Every trace starts at one of them. A root server holds no records for ordinary domains. All it knows is which servers run each top-level domain, and a query for any name it answers with a referral to the right TLD servers, exactly as the first hop of a trace shows.

The country is where each operator is based. Because every letter is served from many sites worldwide, a query is answered by whichever instance is closest to you, not necessarily one in that country.

• Thirteen addresses, not thirteen machines. Each letter is served from many sites around the world using anycast, so a query reaches a nearby instance. Across all letters that is well over a thousand server instances. The number thirteen dates from the original 512-byte limit on DNS replies, which was enough to list thirteen servers and their addresses in one packet.
• Twelve independent operators. Verisign runs two letters (A and J); the rest are run by universities, research networks, government labs, and non-profits, so no single organization controls the root. They all serve the same root zone, whose contents are managed through IANA.
• Resolvers find them from a built-in list. The root hints file (named.root, published by IANA) ships with resolver software and holds these addresses. It is the one thing a resolver has to be given rather than discover. DNS Trace starts from the same addresses, trying a.root-servers.net first and the other letters if one does not answer.
• You rarely see them on a normal lookup. A TLD's nameservers are cached for about two days, so a resolver almost never needs to ask the root again. A trace deliberately skips the cache and asks the root every time.
• A root referral is not an answer. Because the root is only pointing you onward, its reply does not carry the authoritative flag. In a trace that is why the root step shows no aa flag, while the final nameserver does.

A Real Trace, Step by Step

Here is an actual DNS Trace of example.com (record type A), run from NetSH's check server. Three servers were asked, in order, and the whole walk took well under a second:

Two things are worth noticing. The delegation records have a TTL of two days while the answer itself has five minutes, which is why resolvers almost never need to ask the root or TLD again but re-ask the domain's own nameserver often. And the times are one run from one location: the first two steps were slow here because those servers were far from the check server, while the final nameserver was close. Yours will differ.

Anatomy of a DNS Message

Every query and response has the same structure: a header of flags and a response code, then up to four sections. Knowing the vocabulary makes a trace, or the raw output of a tool like dig, far easier to read.

Glue Records

A delegation names nameservers by hostname, and hostnames need IP addresses. That is a problem when the nameserver lives inside the very domain being delegated: to find ns1.example.com you must first ask example.com's nameservers, which requires ns1.example.com. The way out is glue: the parent zone includes the nameserver's address in its referral, in the additional section, so the resolver can move on without a second lookup.

When the nameservers belong to another domain (a domain hosted at ns4.eurodns.com, say), no glue is needed or supplied, and the resolver has to look those hostnames up separately before it can continue. A trace shows this as an extra step, and it is one reason some cold lookups take more queries than the minimum of three.

Following a CNAME

A CNAME record says "this name is an alias for another name". A resolver that receives one has to start over for the new name. In a real trace of www.github.com, the authoritative nameserver answered with a CNAME pointing to github.com (TTL 3600) and, in the same reply, the A record for that target (TTL 60), so no restart was needed. When the target lives at a different provider, the trace begins again at the root for the new name. A CNAME chain can be several links long, and every link adds lookup time, which is one more reason a chain is worth keeping short.

DNS Caching: Where Answers Are Kept

Doing the full walk for every lookup would be slow and would swamp the root and TLD servers, so DNS answers are cached at several layers between you and the authoritative nameserver. Each layer keeps a copy of the answer and reuses it until it expires, and any one of them can be the reason you see an old value.

Every record carries a TTL (time to live), in seconds. Each cache counts down from the moment it fetched the record and throws the copy away when the TTL reaches zero. A 300-second TTL means at most five minutes of staleness; a 86400-second TTL means up to a day. Because caches keep the old TTL, lowering a record's TTL only helps once the previous, longer TTL has run out, so lower it well before a planned change.

• Negative answers are cached too. A "this name does not exist" (NXDOMAIN) or "no such record" answer is remembered for a period set by the domain's SOA record, so a record you just created can keep looking missing for a while.
• Resolvers can adjust TTLs. Some enforce a minimum or maximum, so a very short TTL may be honored less precisely than the number suggests.
• A trace skips every cache. It asks the authoritative nameserver directly, so it shows what is live at the source right now. If a trace shows the new value but your device shows the old one, one of the caches above is still holding it. DNS Propagation shows which public resolvers have already picked up the change.

Trace vs. Lookup

A normal DNS Lookup asks a recursive resolver to do all of this and return only the result. A trace sends every query itself, directly to the server for that step, with recursion turned off. The two answer different questions: a lookup tells you what the resolver currently believes, a trace tells you what the authoritative servers are saying right now and whether the delegation leading to them is intact.

Reading a Trace

A delegation that points at a nameserver that is down, or that no longer hosts the zone (a lame delegation), is a classic cause of intermittent failures: resolvers that happen to pick a working nameserver succeed, while others fail.

Why the Same Name Can Resolve Differently

Two people looking up the same name at the same moment can legitimately get different answers, and none of these cases is a fault:

• Different caches. Right after a change, resolvers that fetched the old record still serve it until its TTL runs out, while others already have the new one.
• Geographic and CDN routing. Large sites often answer with the address of the closest data center. The answer depends on where the resolver, or in some cases the user's network, appears to be. Some resolvers pass part of the client's network address to the authoritative server (EDNS Client Subnet) to make this more precise; others deliberately do not, for privacy.
• Round robin. A name with several A records may have them returned in a rotating order, so different lookups start with different addresses.
• Split-horizon DNS. Organizations sometimes serve internal addresses to their own network and public addresses to everyone else.
• Anycast. The same nameserver address is served from many places, so two asks of one address can be answered by different machines.

The DNS Propagation checker asks major public resolvers in parallel, which is the quickest way to see this variation for your own domain.

Privacy, Encryption, and DNSSEC

• Transport. DNS normally uses UDP on port 53. A reply too large for one packet is marked truncated, and the query is repeated over TCP. Modern resolvers advertise a larger UDP size through EDNS0 to avoid most of those retries.
• Encrypting the hop to your resolver. DNS over TLS (port 853), DNS over HTTPS, and DNS over QUIC encrypt the traffic between your device and its recursive resolver, so anyone on the network path cannot read or tamper with your queries. The resolver itself still sees them, and the traffic from a resolver to authoritative servers is mostly still unencrypted.
• Query minimization. A privacy-minded resolver sends each server only what it needs: the root gets asked about com, not the full name, and only the final nameserver sees the complete question.
• DNSSEC. Zones can sign their records so a resolver can prove an answer is genuine, building a chain of trust from the root down. Validation happens in the resolver, which is why a signing mistake shows up as SERVFAIL there while the authoritative servers look perfectly healthy. DNS Trace shows what each server says and does not validate signatures; the DNSSEC Test checks the chain of trust, and the DNSSEC guide explains it in depth.

Troubleshooting Playbook

Match what you see to the likeliest cause, then use the trace to confirm it:

Command-Line Equivalents

Everything a trace does can be reproduced from a terminal, which is handy when you want to check from your own network:

When the Trace and the Resolver Disagree

If the authoritative servers answer but a recursive resolver does not, the problem is on the resolver side of the chain. A resolver that validates DNSSEC returns SERVFAIL when a signature fails to verify, even though the authoritative servers respond normally. Stale cached data after a change looks different: the resolver answers, but with the old value. The DNS Propagation Checker shows which public resolvers have caught up.

Frequently Asked Questions

Why does a trace take longer than a normal lookup?

A resolver usually answers from its cache. A trace deliberately starts from the root every time and sends each query in sequence, so it reflects a cold lookup rather than a cached one.

Why are there only 13 root servers?

There are thirteen root server names, not thirteen computers. Early DNS replies had to fit in 512 bytes, which limited a list of nameservers to thirteen. Each name is now served from many locations worldwide, so the real number of machines is far higher.

Why do I still see the old IP after changing a DNS record?

Something between you and the authoritative nameserver is still holding the old answer: your browser, your operating system, your router, or your ISP's resolver. Each keeps it until the old TTL expires. A DNS Trace confirms whether the change is already live at the source, and flushing your own device and router clears the layers you control.

Does the trace use IPv6?

The trace queries nameservers over IPv4. A nameserver that is reachable only over IPv6 is not queried and is reported as such rather than guessed at.

What is the difference between recursive and iterative resolution?

In a recursive query the asker wants the final answer and the server does whatever work is needed to get it, which is what your device asks of its resolver. In an iterative query the server answers only with what it knows itself, an answer or a referral to the next server, and the asker follows the referrals. Resolvers use iterative queries to walk the hierarchy, and so does DNS Trace.

How many queries does a lookup take?

A lookup from a cold cache needs at least three: one each to a root server, a TLD server, and the domain's authoritative nameserver. It can take more when a nameserver needs its own address looked up, when a CNAME points to another name, or when DNSSEC validation fetches keys. With a warm cache it can be zero: the resolver answers straight from memory.

Is DNS encrypted?

Not by default. Plain DNS travels unencrypted, so networks along the way can see and alter it. DNS over TLS, DNS over HTTPS, and DNS over QUIC encrypt the hop between your device and its resolver. DNSSEC is a different thing: it proves answers are genuine but does not hide them.

What is glue?

The address of a nameserver, supplied by the parent zone in a referral so the resolver does not have to look it up. See Glue Records above.

Trace any domain with DNS Trace.