How a DNS Lookup Works, Step by Step

Step 1: the application and the stub resolver

Most programs never speak DNS themselves. They call an operating system function such as getaddrinfo() and let the system's stub resolver handle it. The stub is deliberately simple. It checks local sources first, usually the hosts file (/etc/hosts on Linux and macOS) and any local DNS cache, and then sends a query with the recursion desired (RD) flag set to the resolver addresses it was configured with. Those addresses usually arrive through DHCP or router advertisements, or are set by hand or by a VPN client.

For a web request, the stub typically asks for both an A record (IPv4) and an AAAA record (IPv6) at about the same time, so the browser can try whichever family connects first. Some browsers bypass the operating system entirely and send DNS over HTTPS to a resolver of their own choosing, which is one reason a site can resolve in one browser and fail in another on the same machine. Why does DNS work on one network but not another? covers those split paths.

Step 2: the recursive resolver checks its cache

The recursive resolver might be run by your ISP, your employer, your home router's upstream, or a public DNS service. Its first move is always to check its cache. If it holds an unexpired A record for www.example.com, it answers immediately and the lookup is over. How long that record stays valid is set by its TTL, explained in DNS TTLs and Caching Explained.

Even when the final answer is not cached, parts of the path usually are. A busy resolver almost always has the .com name servers cached, so it can skip the root and start at the TLD. It may also hold a cached negative answer, in which case it returns "does not exist" without asking anyone.

A resolver that starts with an empty cache needs a way in. It ships with a root hints file listing the names and addresses of the root servers, and on startup it sends a priming query to learn the current root server set, as described in RFC 8109, Initializing a DNS Resolver with Priming Queries. IANA publishes the list of root server operators.

Step 3: walking down the hierarchy

On a cold cache, the resolver walks from the top of the namespace down, one zone at a time. Each server either answers or refers the resolver to the next zone down.

1. Root servers. The resolver asks a root server. The root does not know www.example.com, but it knows who runs com, so it returns a referral: the NS records for com plus glue addresses.
2. TLD servers. The resolver asks a .com server, which returns another referral: the name servers that the domain's owner registered for example.com, with glue if those servers are inside the zone. DNS Delegation and Glue Records explains exactly what a referral contains.
3. Authoritative servers. The resolver asks one of the example.com servers. This server is authoritative, so it returns the A record with the authoritative answer (AA) flag set.

You can watch this happen with dig +trace, which makes dig act as its own iterative resolver and print each referral. The output below is trimmed, and the example zone uses documentation addresses.

$ dig +trace www.example.com A

.                       518400  IN  NS  a.root-servers.net.
.                       518400  IN  NS  b.root-servers.net.
;; Received 239 bytes from 192.0.2.53#53(192.0.2.53) in 4 ms

com.                    172800  IN  NS  a.gtld-servers.net.
com.                    172800  IN  NS  b.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms

example.com.            172800  IN  NS  ns1.example.net.
example.com.            172800  IN  NS  ns2.example.net.
;; Received 650 bytes from 192.5.6.30#53(a.gtld-servers.net) in 20 ms

www.example.com.        3600    IN  A   203.0.113.10
;; Received 60 bytes from 198.51.100.53#53(ns1.example.net) in 31 ms

Each block is one step. Modern resolvers also apply query name minimisation, defined in RFC 9156, DNS Query Name Minimisation to Improve Privacy: instead of sending the full name to the root and the TLD, they reveal only as much as each server needs, such as asking the root only about com.

What makes a lookup longer

The three-step walk is the simple case. Several things routinely add queries.

• CNAME records. If www.example.com is a CNAME to site.example-cdn.net, the resolver restarts the lookup for the new name, which may mean a new walk through a different TLD.
• Name servers without glue. When the delegated servers are named under another domain, the resolver must resolve those server names first, then return to the original question.
• DNSSEC validation. A validating resolver also fetches DS and DNSKEY records at each level to build a chain of trust from the root key to the answer.
• Large responses. If a UDP response is too large and comes back truncated (the TC flag), the resolver retries the same query over TCP.
• Slow or dead servers. Resolvers track response times and retry other name servers for the zone when one does not answer, which hides failures at the cost of latency.

Step 4: the answer comes back and is cached

The resolver caches everything useful it learned: the final record, the referrals, and the glue. It then returns the answer to the stub with the recursion available (RA) flag set, and the stub hands the address to the application. The next user who asks the same resolver for the same name gets it straight from cache, with no queries to the root, TLD or authoritative servers.

Not every lookup ends with an address. The response code tells you how it ended. NOERROR with records is a normal answer. NOERROR with no records means the name exists but has no data of that type, or that a CNAME led to a name with no such data. That can be the correct answer, such as an AAAA lookup for an IPv4-only host. NXDOMAIN means the name does not exist. SERVFAIL means the resolver could not get a usable answer, often because of a broken delegation or a DNSSEC validation failure. NXDOMAIN vs NODATA vs REFUSED explains each one, and negative answers are cached too, as described in Negative Caching and the SOA Minimum.

Where lookups go wrong

Mapping a failure to the step where it happens is the fastest way to fix it.

• Step 1: a stale hosts file entry, a VPN that changed the configured resolver, or a browser using its own DNS-over-HTTPS resolver.
• Step 2: a resolver holding an old or negative answer, or applying a filtering policy that blocks the name.
• Step 3: a delegation pointing at servers that no longer serve the zone, missing glue, or a DNSSEC chain that does not validate. These usually surface as SERVFAIL; see DNS SERVFAIL Explained.
• Authoritative data: the record really is missing or wrong in the zone.

How DNS Panopticon helps

Domain Visualizer runs the lookup from the public side: it resolves a domain's records live through Cloudflare and Google DNS-over-HTTPS resolvers and shows each record with its TTL. If the two resolvers return different answers for the same name and type, it reports resolver variance, which points at caching or a recent change. Comparing its view with what your own network returns is a quick way to tell a local Step 1 or Step 2 problem from a problem in the zone itself.

Website Recon resolves A, AAAA, CNAME, NS, MX and TXT records for a hostname, then looks up each resolved IP address in RDAP to show the network and autonomous system number (ASN) that announces it. That shows where the lookup actually lands, including when a CNAME hands the name to a CDN.