How DNS root resolution works

When a recursive resolver has no cached answer, it starts at the root. This guide follows the full resolution path from a DNS query to the root and back.

Resolver Behavior 7 min read Reviewed 19 Sep 2026

The big picture

A recursive resolver walks the DNS hierarchy — root, TLD, authoritative — to turn a domain name into an answer. Each step narrows the search.

Queryexample.com
A record?

RootReferral to
.com servers

TLDReferral to
example.com NS

Answer93.184.216.34

Introduction

Every domain name lookup ultimately depends on the root of the DNS hierarchy. When a recursive resolver encounters a query it cannot answer from cache, it begins the resolution process at the root zone and works its way down through the namespace.

This guide walks through each step of that process — from the initial query to the final answer — explaining what happens at the root, what the root returns, and how caching makes subsequent queries faster.

The recursive resolution process

Consider a user looking up www.example.com. Here is what happens when the recursive resolver has an empty cache:

Step 1: Stub query — The user's device sends a DNS query for www.example.com A to its configured recursive resolver.
Step 2: Root query — The resolver has no cached data, so it selects a root server from its root hints and sends a query for www.example.com A to that root server.
Step 3: Root referral — The root server does not know the answer, but it knows who is responsible for .com. It returns a referral: the NS records for the .com TLD along with glue A/AAAA records for those name servers.
Step 4: TLD query — The resolver follows the referral and queries a .com TLD server for www.example.com A.
Step 5: TLD referral — The .com server returns another referral: the NS records for example.com and any available glue records.
Step 6: Authoritative query — The resolver queries the authoritative name server for example.com.
Step 7: Final answer — The authoritative server returns the A record for www.example.com. The resolver caches the answer and returns it to the user's device.

Priming and root hints

Before a recursive resolver can query the root, it needs to know where the root servers are. This bootstrap information comes from two sources:

Root hints file — A static file (typically named.root or db.root) shipped with resolver software. It contains the hostnames and IP addresses of the 13 root server identities. This file provides the initial set of addresses the resolver uses to reach the root.
Priming query — On startup (or when the root NS cache expires), the resolver sends a priming query: an NS query for the root zone (. NS) to one of the root servers listed in the hints file. The root server responds with the current, authoritative list of root server NS records and their addresses.

After a successful priming query, the resolver uses the primed data — not the static hints — for subsequent root queries. This ensures the resolver works with up-to-date root server information even if its hints file is slightly outdated.

Root referrals

When a root server receives a query, it does not attempt to resolve the full domain name. Instead, it examines the TLD portion and returns a referral. A referral consists of:

Authority section — NS records for the queried TLD (e.g., com. NS a.gtld-servers.net.).
Additional section — Glue records: A and AAAA records for those TLD name servers, so the resolver can reach them without a separate lookup.

The root server sets the AA (Authoritative Answer) flag to false in its response, signaling that this is a referral, not a final answer. The response code is NOERROR, and the answer section is empty.

If the queried TLD does not exist in the root zone, the root server returns an NXDOMAIN response, telling the resolver that no such TLD is delegated.

Caching and TTLs

Caching is what makes DNS fast. Without it, every single lookup would require a full walk from root to authoritative — an enormous and unnecessary load on the root server system.

Each DNS record in a referral or answer carries a TTL (Time To Live) value. The resolver caches the record for that duration:

Root NS records — The NS records for the root zone itself typically have a TTL of 518,400 seconds (6 days). Once primed, the resolver won't re-query the root for its own NS records for almost a week.
TLD NS records — The NS records for TLDs like .com are cached as received from the root referral, typically for 172,800 seconds (2 days).
Final answers — The A/AAAA records from authoritative servers have TTLs set by the domain owner, ranging from seconds to days.

Because of caching, most DNS queries never reach a root server. The root is only contacted when the resolver has no cached referral for the relevant TLD — which, for popular TLDs like .com, is rare after the first lookup.