When an application needs to reach a service by name, it does not know where to start on the network. DNS exists to answer a single question: given a name, where should traffic go next?
This article walks through how DNS resolution actually works. It avoids record-level detail and focuses on the sequence of decisions that turn a name into a usable answer.
If you have read the introductory article on what DNS is and why it exists, this is the next step: how that system actually produces an answer in practice.
Names versus addresses
Computers communicate using IP addresses, not names. Humans and applications prefer names because they are stable, readable, and independent of network location.
DNS acts as a translation system between these two worlds. This translation is not performed by a single server. It is the result of coordinated behavior across multiple components.
The main actors in DNS resolution
A DNS lookup involves several distinct roles. They often get blurred together, especially in documentation that uses the term “DNS server” loosely.
- Client: The application that needs a name resolved, such as a browser or mail server.
- Stub resolver: A small resolver built into the operating system. It forwards questions rather than resolving them fully.
- Recursive resolver: A server that performs the full resolution process on behalf of the client.
- Authoritative servers: Servers that publish answers for specific domains.
Only the recursive resolver actually walks the DNS hierarchy. Clients almost never do.
Step 1: The client asks a local resolver
Resolution starts when an application asks the operating system for an answer. The operating system does not contact root servers or authoritative infrastructure directly.
Instead, the stub resolver sends the query to a configured recursive resolver. This is usually provided by the local network, an ISP, or a manually configured DNS service.
At this point, the client is done. Everything that follows happens elsewhere.
Step 2: Cache checks happen first
Before asking anyone else, the recursive resolver checks its cache.
If it already has a valid answer, it returns that immediately. This is the most common outcome on the internet.
Caching is not an optimization layered on top of DNS. It is a core design assumption. Without it, DNS would not scale.
Step 3: Walking the DNS hierarchy
If no cached answer exists, the recursive resolver begins a process called iterative resolution.
It starts at the root of the DNS hierarchy. Root servers do not know the answer for most names. Instead, they point the resolver toward the next level.
The process looks like this:
- Ask a root server where to find the servers responsible for the top-level domain
- Ask those servers which ones handle the specific domain
- Ask the authoritative servers for the final answer
Each step returns a referral, not the final destination, until the resolver reaches a server that is authoritative for the name.
Step 4: The authoritative answer
Authoritative servers publish the data for a domain. When a recursive resolver reaches the correct authoritative server, it receives an answer that is considered final for that domain.
This answer includes metadata that tells the resolver how long it may cache the result.
The resolver stores the answer and returns it to the client.
Step 5: The client uses the result
The stub resolver passes the answer back to the application. DNS resolution is complete.
From the application’s perspective, this is a single request and response and the complexity is intentionally hidden.
What a successful lookup does not guarantee
A DNS lookup can succeed and still leave work to be done. DNS answers questions about names, but it does not establish network connections, verify application identity, or guarantee reachability or performance. If a DNS answer exists, it only means that someone published it and the resolver could retrieve it.
Real-world variations
The basic flow described here is consistent, but real systems add complexity. Operating systems may consult local files or special name systems before reaching out to a resolver. Browsers increasingly use their own resolvers or encrypted DNS transports. Networks may intercept or redirect DNS queries entirely. These variations change where the query goes, not the fundamental resolution model.
Why this model matters
Understanding DNS resolution as a sequence of referrals and cache decisions helps explain why changes take time to propagate, why different users may see different results, and why DNS failures can be intermittent and hard to reproduce. DNS is not a lookup table. It is a distributed decision process.
Summary
DNS resolution turns a name into an answer by:
- Delegating responsibility down a hierarchy
- Caching aggressively at each step
- Separating clients from the resolution process
Once you understand that flow, many DNS behaviors that seem unpredictable start to make sense.