A DNS lookup starts when an application sends a query for a name. An answer often comes back within milliseconds, but resolving that name can involve four different DNS roles. The application usually communicates with only one of them.
Understanding those roles and how the query moves between them makes the record types easier to understand later.
The four actors in a lookup
Documentation tends to say “DNS server” as if that were one thing. A lookup actually involves four distinct roles:
- Client: the application that needs a name resolved, such as a browser or a mail server.
- Stub resolver: a small forwarder built into the operating system. It hands questions off rather than resolving them itself.
- Recursive resolver: the server that performs the full resolution on the client’s behalf.
- Authoritative servers: the servers that publish answers for specific domains.
Only the recursive resolver walks the DNS hierarchy, and clients almost never do it themselves.
Step 1: The client asks a local resolver
Resolution starts when an application asks the operating system for a name. The OS doesn’t contact root servers or authoritative infrastructure. Its stub resolver forwards the query to whichever recursive resolver the system is configured to use, typically one from the local network, an ISP, or an explicitly chosen DNS service.
At this point the client has done its part. Everything until the answer comes back happens elsewhere.
Step 2: The cache answers most lookups
Before asking anyone else, the recursive resolver checks its cache. A valid cached answer goes straight back to the client, and on a busy resolver that’s how the large majority of lookups end.
Caching isn’t an optimization bolted onto DNS but a core design assumption, and without it the system wouldn’t scale.
Step 3: Walking the hierarchy
With no cached answer, the resolver resolves the name iteratively, starting at the root of the DNS hierarchy.
For a name like www.example.com, the walk has three stops:
- A root server, which answers with the servers responsible for
.com - The
.comTLD servers, which answer with the servers responsible forexample.com - The authoritative servers for
example.com, which hold the actual records
Every step until the last returns a referral rather than an answer, not “here is the address” but “ask them instead.”
Step 4: The authoritative answer
When the resolver reaches a server that is authoritative for the name, it finally gets an answer rather than a referral. The answer arrives with a time-to-live that tells the resolver how long it may cache the result. The resolver stores it and sends it back to the client.
Step 5: The client uses the result
The stub resolver hands the answer to the application, which connects and gets on with its work. The application saw one request and one response. The machinery in between is intentionally invisible.
What an answer actually proves
A successful lookup proves less than you might hope. It means the resolver returned a record, usually because someone published it. It doesn’t establish the connection, verify who is on the other end, or promise the destination is reachable or fast. Those jobs belong to other layers, and attackers work the gap between “resolved” and “trustworthy” constantly.
Real-world variations
Real systems complicate the clean flow. Operating systems consult hosts files and local discovery protocols before or alongside DNS, and each OS wires this differently. Browsers increasingly bring their own resolvers and encrypted transports. VPNs can split resolution across several resolvers at once, and some networks intercept queries outright. All of it changes where, or whether, a DNS query travels, and none of it changes the resolution model.
Why this model matters
Seen as a sequence of referrals and cache decisions, DNS behavior stops looking mysterious. Changes take time to appear because caches expire on their own schedules. Different users get different answers because they sit behind different resolvers. Failures come and go because any hop in the chain can misbehave independently. DNS isn’t a lookup table but a distributed decision process.
Summary
Resolution is delegation plus caching. A stub resolver hands the question to a recursive resolver, the resolver answers from cache or walks root, TLD, and authoritative servers, and the answer flows back with a lifetime attached. Keep that flow in mind and many DNS behaviors that look unpredictable become predictable.