How DNS Resolution Works: Recursive Resolvers, Root Servers, TLDs and Authoritative DNS
Every time you open a website, connect to an API, send an email, or access a cloud service by name, the Domain Name System performs one of the Internet’s most important jobs: DNS resolution.
Humans prefer names such as www.example.com, while network communication ultimately depends on IP addresses. DNS provides the distributed system that connects those two worlds.
But DNS resolution is more sophisticated than simply looking up a domain in one giant database. A request may involve a stub resolver, recursive DNS resolver, root name server, top-level domain (TLD) name server, authoritative DNS server, caching, TTL values, and multiple DNS resource records before the client receives the information it needs.
This guide explains how DNS resolution works step by step, what recursive and iterative queries mean, how caching speeds up DNS, what happens when a CNAME is encountered, and how to troubleshoot the process using tools such as dig.
For a broader introduction to DNS architecture, start with our DNS Explained guide. If you specifically want to understand A, AAAA, CNAME, MX, TXT, NS, PTR, and SRV records, read our companion guide, DNS Record Types Explained.
What Is DNS Resolution?
DNS resolution is the process of obtaining DNS information associated with a domain name.
For a typical web request, the information ultimately needed is often an IP address.
A user might enter:
www.example.comwhile the network connection requires an address such as:
192.0.2.10or an IPv6 address such as:
2001:db8::10At a simplified level:
www.example.com
|
v
DNS
|
v
192.0.2.10That simplified model is useful, but it hides most of what actually happens.
There is no single central DNS database containing every Internet domain. DNS is a distributed, hierarchical naming system. Responsibility is divided among different parts of the namespace.
The architecture was defined in foundational specifications including RFC 1034 and RFC 1035.
A DNS lookup may therefore involve several different systems before an answer reaches the application.
Understanding this process is especially useful when troubleshooting websites, mail servers, cloud services, VPNs, APIs, Linux servers, and enterprise networks.
DNS Resolution in One Diagram
Consider a client attempting to resolve:
www.example.comA simplified DNS resolution path looks like this:
+------------------+
| Browser / Client |
+--------+---------+
|
v
+------------------+
| Stub Resolver |
+--------+---------+
|
v
+----------------------+
| Recursive DNS |
| Resolver |
+----------+-----------+
|
| 1. Where is .com?
v
+----------------------+
| Root Name Server |
+----------+-----------+
|
| Referral to .com
v
+----------------------+
| .com TLD Name Server |
+----------+-----------+
|
| Referral to example.com
v
+----------------------+
| Authoritative DNS |
| for example.com |
+----------+-----------+
|
| A / AAAA / CNAME answer
v
+----------------------+
| Recursive Resolver |
| caches the answer |
+----------+-----------+
|
v
+----------------------+
| Client receives |
| DNS result |
+----------------------+The resolver does not necessarily perform every step for every request.
If useful information already exists in a valid cache, DNS resolution can be much shorter.
That distinction becomes important when diagnosing why a DNS change appears immediately for one user but not another.
The Components Involved in DNS Resolution
Before following a lookup step by step, it helps to understand the major participants.
The Application
The process often begins with an application such as:
- Web browser
- Email client
- SSH client
- API client
- Mobile application
- Operating-system service
The application needs information associated with a hostname.
For example:
api.example.comThe application normally relies on the operating system’s resolver facilities rather than implementing the complete DNS hierarchy itself.
Stub Resolver
A stub resolver is the relatively lightweight resolver on the client side.
Its job is generally to send DNS queries to a recursive resolver configured for the device.
The recursive resolver address might have been configured manually or supplied automatically through network configuration mechanisms such as DHCP.
This illustrates the relationship between DNS and DHCP:
DHCP
|
+---- IP configuration
+---- Default gateway
+---- DNS resolver address
|
v
Client
|
v
DNS ResolverDNS and DHCP therefore complement one another but perform different jobs.
Recursive DNS Resolver
The recursive resolver does much of the lookup work on behalf of the client.
It may be operated by:
- An Internet service provider
- An enterprise
- A cloud provider
- A public DNS provider
- A local network
- Another managed DNS service
The resolver first checks whether it already has an appropriate cached answer.
If not, it can follow the DNS hierarchy until it obtains the necessary information.
The resolver then returns the result to the client and can cache appropriate data according to DNS caching rules.
Root Name Servers
Root name servers operate at the top of the DNS hierarchy.
They do not normally store the IP address of every website on the Internet.
Instead, they help resolvers find the authoritative name servers for top-level domains such as:
.com
.org
.net
.uk
.deTLD Name Servers
Top-level domain name servers provide information that helps a resolver move from a TLD toward the authoritative DNS infrastructure for a particular domain.
For example:
.
|
+---- com
|
+---- example.comThe .com infrastructure does not need to contain every DNS record belonging to example.com.
Instead, delegation allows responsibility to move to the authoritative servers for the domain.
Authoritative DNS Server
The authoritative DNS server holds authoritative DNS data for a zone.
It may provide records such as:
A
AAAA
CNAME
MX
TXT
NS
SOA
CAAFor example:
www.example.com. A 192.0.2.10The distinction between a recursive resolver and an authoritative server is fundamental:
| System | Primary Role |
|---|---|
| Stub resolver | Sends client DNS requests |
| Recursive resolver | Resolves requests on behalf of clients and caches data |
| Root server | Directs resolution toward the appropriate TLD |
| TLD server | Helps locate authoritative servers for delegated domains |
| Authoritative server | Provides authoritative DNS data for its zones |
How DNS Resolution Works Step by Step
Now consider what happens when a user enters:
www.example.cominto a browser.
Step 1: The Application Needs an Address
The browser needs to communicate with the server associated with the hostname.
Before an IP connection can be established, the system needs suitable address information.
Depending on the client and network, that may involve looking for:
A -> IPv4
AAAA -> IPv6The difference between these records is explained in our DNS Record Types Explained guide.
Step 2: Local Information May Be Checked
Before a full external lookup occurs, the operating system or application may have relevant cached information.
The system can also have locally configured hostname information.
The exact behavior varies by operating system, application, resolver configuration, and caching layer.
If a valid answer is already available locally, an external lookup may not be required.
Otherwise, the request proceeds toward the configured DNS resolver.
Step 3: The Recursive Resolver Checks Its Cache
The recursive resolver receives the query.
Suppose the request asks for:
www.example.com AThe resolver checks whether it already has a valid cached answer.
If it does, it may immediately return that information.
This is one of the reasons DNS can operate efficiently at Internet scale.
Instead of performing the entire hierarchy for every request:
Client
|
v
Recursive Resolver
|
v
Cached Answermay be enough.
If there is no usable cached information, the resolver must continue.
Step 4: The Resolver Consults the DNS Root
The resolver can query the root DNS infrastructure.
Conceptually, it is asking:
Where should I look for information about names beneath
.com?
The root server provides a referral that allows the resolver to continue toward the appropriate TLD servers.
The root does not normally respond with:
www.example.com = 192.0.2.10Instead, the hierarchy works more like:
Need www.example.com
|
v
Root: "Ask the .com servers"The operational root zone is coordinated through the DNS root infrastructure. Information about the root server system is available from the official IANA Root Servers resource.
What Does a Root DNS Server Do?
The root layer represents the top of the public DNS hierarchy.
A domain such as:
www.example.com.can be viewed from right to left:
. -> com -> example -> wwwThe final dot represents the DNS root.
Users rarely type the trailing dot, but DNS names are rooted in this hierarchy.
A root server helps the resolver move toward the relevant top-level domain.
Conceptually:
DNS Root
|
+----------+----------+
| | |
.com .org .net
|
example.com
|
www.example.comThis architecture distributes responsibility instead of placing the entire Internet namespace on one central server.
Are There Only 13 Physical Root Servers?
You may encounter the statement that DNS has “13 root servers.”
That description needs context.
The root system has 13 named root server identities, historically labeled A through M, but these are not merely 13 physical machines sitting in 13 locations.
Modern root service uses extensive distributed infrastructure, including anycast, allowing multiple server instances around the world to serve the same root-server identity.
The official Root Server Technical Operations Association provides current information about the root server system.
This distinction matters because oversimplified DNS diagrams can make the root infrastructure appear far more centralized than it really is.
What Does a TLD Name Server Do?
After the resolver receives a referral from the root, it can query the appropriate top-level domain name server.
For:
www.example.comthe relevant TLD is:
.comThe resolver effectively asks:
Which name servers are responsible for
example.com?
The TLD infrastructure can return delegation information pointing toward the authoritative name servers for that domain.
Conceptually:
Root
|
v
.com TLD
|
v
NS records for example.com
|
v
Authoritative DNSThe same hierarchical principle applies to other TLDs.
For example:
example.org
|
v
.orgor:
example.net
|
v
.netCountry-code domains introduce their own namespace structures, but the hierarchical delegation concept remains fundamental.
What Is an Authoritative DNS Server?
Once the recursive resolver knows which servers are authoritative for the target zone, it can query them.
Suppose the authoritative server contains:
www.example.com. 3600 A 192.0.2.10The resolver can receive that authoritative data and return the relevant result to the client.
The path is now:
Client
|
v
Recursive Resolver
|
v
Root
|
v
TLD
|
v
Authoritative DNS
|
v
192.0.2.10The client can then use the address as part of establishing network communication.
DNS resolution ends with DNS information; the actual application connection is a separate process.
For example, reaching the destination can subsequently involve routing, TCP or QUIC, TLS, and HTTP.
This is why DNS should be understood alongside the concepts covered in TCP/IP Explained and Computer Networking Explained.
Recursive vs Iterative DNS Queries
The difference between recursive and iterative DNS behavior is one of the most important concepts in DNS.
Recursive Query
In a recursive query, the client asks a resolver to provide the requested answer or an appropriate error.
Conceptually:
Client:
"What is the address for www.example.com?"
|
v
Recursive Resolver:
"I'll resolve it for you."The client does not need to individually contact the root, TLD, and authoritative servers.
Iterative Resolution
During iterative resolution, the resolver can receive referrals directing it to another server closer to the authoritative answer.
Conceptually:
Resolver -> Root
Root -> "Ask .com"
Resolver -> .com
.com -> "Ask example.com's authoritative servers"
Resolver -> Authoritative Server
Authoritative Server -> AnswerThe resolver follows the chain.
A simplified comparison is:
| Recursive | Iterative |
|---|---|
| Client delegates lookup work | Resolver follows referrals |
| Common between client and recursive resolver | Common during resolver traversal of DNS hierarchy |
| Client expects final result/error | Server can direct resolver elsewhere |
These terms describe different query behaviors and should not be confused with the difference between recursive DNS servers and authoritative DNS servers.
Recursive DNS vs Authoritative DNS
This distinction deserves special attention because it is a frequent source of confusion.
A recursive DNS resolver searches for answers on behalf of clients and caches results.
An authoritative DNS server publishes authoritative information for zones it serves.
Think of it like this:
Client
|
v
Recursive Resolver
|
| searches
v
DNS Hierarchy
|
v
Authoritative Server
|
| provides authoritative data
v
Recursive Resolver
|
v
ClientThe two systems can be implemented in different ways depending on the environment, but conceptually their roles are distinct.
For public-facing infrastructure, keeping these roles conceptually separate also helps when designing security controls and troubleshooting DNS failures.
How DNS Caching Works
Without caching, DNS resolvers would need to repeat large portions of the resolution process far more frequently.
DNS caching dramatically reduces that work.
Suppose an authoritative response contains:
www.example.com. 3600 A 192.0.2.10The TTL is:
3600 secondswhich equals one hour.
A resolver can cache the information according to the applicable DNS caching rules.
The next user requesting the same information may receive the cached result:
User A
|
v
Resolver
|
+---- Full lookup required
|
v
Cache populated
User B
|
v
Resolver
|
+---- Cache hit
|
v
Immediate DNS answerCaching improves:
- DNS response performance
- Scalability
- Authoritative-server efficiency
- Root and TLD infrastructure efficiency
But caching also explains why DNS changes are not necessarily visible everywhere immediately.
What Happens When the TTL Expires?
Once cached data is no longer valid according to its TTL, the resolver needs refreshed information when it next needs that data.
If the authoritative record has changed from:
192.0.2.10to:
192.0.2.20a fresh lookup can obtain the newer value.
This is why DNS administrators often consider TTL values when planning migrations.
A DNS record changed at 10:00 does not automatically force every recursive resolver to discard a still-valid cached copy at 10:01.
Positive and Negative DNS Caching
Caching does not apply only to successful answers.
DNS can also cache certain negative responses.
For example, a resolver may receive information indicating that a requested name does not exist.
This is important operationally.
Imagine accidentally querying:
newapp.example.combefore the DNS record exists.
A negative result may be cached.
If you immediately create the missing record, some resolvers may continue to return the previously cached negative result for an applicable period.
This can make troubleshooting confusing because:
Authoritative DNS:
Record exists now
Resolver A:
Returns new record
Resolver B:
Still has cached negative informationUnderstanding negative caching prevents administrators from assuming that every inconsistent DNS result means the authoritative configuration is still broken.
What Happens When DNS Encounters a CNAME?
DNS resolution becomes slightly more interesting when the requested name is a CNAME.
Suppose:
www.example.com. CNAME web.example.net.and:
web.example.net. A 192.0.2.50The process becomes:
www.example.com
|
v
CNAME
|
v
web.example.net
|
v
A Record
|
v
192.0.2.50The resolver needs the relevant address information for the canonical target.
This is why a CNAME does not directly mean:
Hostname -> IPInstead:
Hostname -> Hostnamewhich must ultimately lead to the information the client needs.
For a detailed comparison of CNAME, A, AAAA, MX, TXT, NS, PTR, and SRV records, refer to our DNS Record Types Explained guide.
DNS Resolution Over IPv4 and IPv6
Modern clients may need both IPv4 and IPv6 information.
DNS provides:
A -> IPv4
AAAA -> IPv6A domain can publish both:
www.example.com. A 192.0.2.10
www.example.com. AAAA 2001:db8::10A modern client may obtain both kinds of address information and use connection-selection behavior appropriate to its operating system and network environment.
It is important not to assume that publishing an AAAA record automatically makes an application fully IPv6-capable.
The entire path must work:
DNS AAAA
|
v
IPv6 routing
|
v
Firewall
|
v
Load balancer / server
|
v
ApplicationA valid DNS response cannot compensate for broken IPv6 routing or firewall configuration.
This distinction is particularly relevant in cloud networks, where IPv4 and IPv6 configuration can differ across subnets, routing policies, security controls, and load balancers.
DNS Resolution Failures and Common Errors
DNS failures can occur at several different layers.
That means “DNS is broken” is rarely a sufficiently precise diagnosis.
A useful troubleshooting model is:
Client
|
v
Local resolver configuration
|
v
Recursive resolver
|
v
Root/TLD delegation
|
v
Authoritative DNS
|
v
DNS recordEach stage can fail differently.
NXDOMAIN
NXDOMAIN indicates that the queried domain name does not exist according to the DNS response.
Possible causes include:
- Typographical errors
- Missing DNS names
- Incorrect configuration
- Querying a name before it has been created
SERVFAIL
SERVFAIL indicates that the resolver could not successfully complete the request.
Possible causes can include problems involving:
- Authoritative DNS
- DNSSEC validation
- Server availability
- Broken delegation
- Resolver-side failures
The correct diagnosis requires inspecting the actual DNS path rather than assuming one universal cause.
Timeout
A DNS timeout means the expected response did not arrive within the allowed period.
Potential causes include:
- Network connectivity problems
- Firewall rules
- Unreachable DNS servers
- Packet loss
- Resolver failure
- Authoritative-server problems
This is where DNS troubleshooting intersects with general network troubleshooting.
A firewall can block DNS traffic just as it can block other network traffic. For broader context on filtering and network policy, see Firewalls Explained.
Incorrect DNS Answer
Sometimes DNS responds successfully but returns unexpected information.
Possible reasons include:
- Stale cached data
- Incorrect authoritative record
- Split DNS
- Different DNS views
- CDN behavior
- Geo-aware DNS
- Load-balancing policies
- Different recursive resolvers
- Configuration mistakes
The fact that DNS returned an answer does not necessarily mean it returned the answer you expected.
How to Trace DNS Resolution with dig
One of the most useful DNS troubleshooting tools is dig.
A basic query looks like:
dig example.comTo request an A record explicitly:
dig example.com AFor IPv6:
dig example.com AAAATo query authoritative-name-server information:
dig example.com NSTo inspect mail-routing information:
dig example.com MXQuery a Specific Resolver
You can ask a specific resolver directly.
For example:
dig @1.1.1.1 example.com Aor:
dig @8.8.8.8 example.com AComparing different resolvers can be useful when investigating cache differences.
Trace DNS Resolution
One of the most educational commands is:
dig +trace example.comRather than relying on the normal recursive path, dig +trace shows the delegation process beginning from the root and following the DNS hierarchy.
The output helps visualize:
Root
|
v
TLD
|
v
Authoritative DNS
|
v
Final DNS dataThis makes dig +trace particularly valuable when troubleshooting delegation.
Find the Authoritative Name Servers
Use:
dig example.com NSThen query one of the authoritative servers directly:
dig @ns1.example.net example.com AYou can then compare that authoritative answer with a recursive resolver:
dig @1.1.1.1 example.com AIf the authoritative server returns the new value while a recursive resolver returns an older one, caching becomes an obvious area to investigate.
For administrators working from Linux servers, this type of troubleshooting complements the practices discussed in Linux Server Administration.
DNS Security: Why Resolution Must Be Protected
DNS was designed during an earlier era of Internet architecture, and security has become increasingly important as DNS has evolved.
Attackers may attempt techniques involving:
- DNS spoofing
- Cache poisoning
- DNS hijacking
- Malicious domain redirection
- Unauthorized DNS changes
- Compromised registrar accounts
If an attacker can alter DNS information, users can potentially be directed toward malicious infrastructure even while entering the correct domain name.
DNS therefore belongs within a broader security architecture.
Our Network Security Basics guide explains how layered defenses work across modern networks.
What Is DNSSEC?
DNSSEC, or Domain Name System Security Extensions, adds cryptographic mechanisms that allow DNS data to be validated for authenticity and integrity within the DNSSEC trust model.
DNSSEC does not encrypt DNS queries.
That distinction is critical.
A simplified conceptual model is:
Traditional DNS
Client -> Query -> Resolver -> Answer
DNSSEC validation
Client/Resolver -> DNS data + signatures
|
v
Cryptographic validationDNSSEC is intended to help a validating resolver determine whether DNS data is authentic and has not been modified in a way that breaks validation.
The standards and deployment model are more sophisticated than simply attaching one signature to every query. The trust chain can extend from the DNS root through delegated zones.
The official ICANN DNSSEC resource provides additional background on DNSSEC and its role in protecting DNS integrity.
DNSSEC vs DNS over HTTPS vs DNS over TLS
DNSSEC is frequently confused with encrypted DNS protocols.
They solve different problems.
DNSSEC
Primarily helps authenticate DNS data and protect its integrity.
DNS over HTTPS
DoH transports DNS queries using HTTPS.
DNS over TLS
DoT transports DNS queries over TLS.
Conceptually:
DNSSEC
|
+---- Authenticity / integrity of DNS data
DoH / DoT
|
+---- Encryption of DNS transportUsing encrypted transport does not automatically provide the same guarantees as DNSSEC validation, and DNSSEC does not hide the DNS query merely because signatures are present.
Modern DNS security therefore involves several complementary layers rather than one universal feature.
DNS Resolution in Enterprise Networks
Enterprise DNS is often more complex than public Internet DNS.
Organizations may operate:
- Internal recursive resolvers
- Internal authoritative zones
- Active Directory-integrated DNS
- Split DNS
- Private cloud DNS
- Forwarders
- Conditional forwarding
- DNS filtering
- Hybrid cloud DNS
For example:
Employee Device
|
v
Enterprise DNS
|
+---- Internal domain?
| |
| v
| Internal DNS
|
+---- Public domain?
|
v
External DNSAn internal hostname might resolve only while a user is connected to the corporate network or VPN.
For example:
database.internal.examplemay intentionally have no public DNS presence.
This allows organizations to maintain different naming architectures for internal and external resources.
Split DNS Explained
Split DNS, sometimes called split-horizon DNS, allows different clients to receive different DNS information depending on the DNS environment or view being used.
For example:
Inside the organization:
portal.example.com -> 10.0.10.20Outside the organization:
portal.example.com -> 203.0.113.20Conceptually:
portal.example.com
|
+---------+---------+
| |
Internal DNS Public DNS
| |
v v
10.0.10.20 203.0.113.20This architecture can be useful, but it can also complicate troubleshooting.
Two users can query the same hostname and legitimately receive different answers.
Therefore, one of the first questions during DNS troubleshooting should sometimes be:
Which resolver produced this answer?
DNS Resolution in Cloud Networks
Cloud platforms introduce additional DNS layers.
Applications may use:
- Public DNS zones
- Private DNS zones
- Managed DNS resolvers
- Cloud load-balancer hostnames
- Service discovery
- Private endpoints
- Hybrid DNS forwarding
- Kubernetes DNS
A simplified cloud architecture might look like:
Internet User
|
v
Public DNS
|
v
Cloud Load Balancer
|
v
Application
Private VM
|
v
Private DNS
|
v
Internal ServiceThis allows the same cloud environment to maintain public and private namespaces.
DNS therefore becomes a fundamental component of cloud architecture rather than merely a domain-management feature.
For a broader understanding of these environments, see Cloud Networking Explained and Cloud Computing Explained.
DNS Resolution and Load Balancing
DNS can also participate in traffic distribution.
A hostname can have multiple address records:
app.example.com A 192.0.2.10
app.example.com A 192.0.2.11
app.example.com A 192.0.2.12But DNS-level distribution should not automatically be treated as equivalent to a sophisticated application load balancer.
DNS caching means clients and resolvers may retain answers for a period of time. DNS also does not inherently understand application sessions, HTTP requests, backend health, or application-layer routing unless those capabilities are added by a DNS or traffic-management platform.
Production architectures may therefore combine:
DNS
|
v
Load Balancer
|
+---- Server A
|
+---- Server B
|
+---- Server Crather than relying only on multiple A records.
DNS Resolution and CDNs
Content delivery networks also rely heavily on DNS.
A website might use an alias that ultimately leads toward infrastructure operated by a CDN.
The DNS system can help direct clients toward infrastructure selected according to the CDN’s architecture.
A simplified model is:
User
|
v
DNS
|
v
CDN
|
v
Edge Location
|
v
Cached Content / OriginThis is another example of why DNS is more than a static hostname database.
Modern DNS frequently acts as an entry point into dynamic, distributed infrastructure.
DNS Resolution Performance
DNS is normally only one stage of loading a website.
A simplified web transaction may involve:
DNS Resolution
|
v
Network Connection
|
v
TLS
|
v
HTTP Request
|
v
Server Processing
|
v
ResponseSlow DNS can therefore add latency before the application connection even begins.
Caching helps reduce this cost.
Infrastructure engineers should nevertheless avoid diagnosing every slow website as a DNS problem. Performance can be affected by many other layers, including routing, server response time, TLS negotiation, application code, database performance, and content delivery.
Good troubleshooting measures each layer instead of guessing.
Common DNS Resolution Mistakes
Several misconceptions repeatedly appear in DNS troubleshooting.
Mistake 1: “DNS propagation always takes 24–48 hours”
This phrase oversimplifies what is usually happening.
Caching and TTL values are major factors in how quickly changed DNS data is observed. Delegation changes and provider behavior can introduce additional considerations.
Rather than automatically waiting 48 hours, inspect:
Authoritative answer
TTL
Recursive resolver answer
DelegationMistake 2: “The root server knows every website IP”
It does not work that way.
Root servers primarily help direct resolvers toward TLD infrastructure.
Mistake 3: “My DNS record is correct, so the website must work”
DNS is only one layer.
You can have:
Correct DNS
|
v
Correct IP
|
v
Blocked firewall
|
X
Website unavailableOr:
Correct DNS
|
v
Server reachable
|
v
Application errorDNS success does not guarantee application success.
Mistake 4: “Changing the authoritative record clears every cache”
It does not.
Resolvers may retain previously cached information until it expires according to applicable caching behavior.
Mistake 5: “CNAME is an HTTP redirect”
It is not.
CNAME operates in DNS.
HTTP redirects occur at the application layer after a client reaches an HTTP server.
A Practical DNS Troubleshooting Workflow
When DNS resolution fails, avoid randomly changing records.
Use a structured workflow.
Start by checking the requested name:
dig example.com AThen inspect the authoritative name servers:
dig example.com NSTrace the delegation:
dig +trace example.comQuery an authoritative server directly:
dig @ns1.example.net example.com ACompare that with a recursive resolver:
dig @1.1.1.1 example.com AThen evaluate:
1. Does the name exist?
2. Is delegation correct?
3. Are the authoritative servers reachable?
4. Does the authoritative server return the expected record?
5. Is the recursive resolver returning stale data?
6. Is DNSSEC validation involved?
7. Is the client using the resolver you think it is?
8. Does the IP route correctly?
9. Is a firewall blocking traffic?
10. Is the application itself healthy?This approach separates DNS failures from network and application failures.
DNS Resolution: Complete Example
Let’s put everything together.
A user requests:
www.example.comThe operating system needs an address.
The process might be:
1. Browser requests www.example.com
2. Operating system checks relevant local information
3. Stub resolver asks configured recursive resolver
4. Recursive resolver checks cache
5. No cached answer exists
6. Resolver queries root DNS
7. Root refers resolver to .com TLD
8. Resolver queries .com TLD
9. TLD refers resolver to example.com authoritative DNS
10. Resolver queries authoritative DNS
11. Authoritative server returns:
www.example.com A 192.0.2.10
12. Resolver caches applicable information
13. Resolver returns 192.0.2.10 to client
14. Client begins network communication with 192.0.2.10The important point is that steps 6–11 do not necessarily occur for every user request.
If the resolver already has valid cached information:
Client
|
v
Recursive Resolver
|
v
Cache Hit
|
v
AnswerThe lookup can be much shorter.
That combination of hierarchy + delegation + caching is central to DNS scalability.
Frequently Asked Questions About DNS Resolution
What is DNS resolution?
DNS resolution is the process of obtaining DNS information associated with a domain name, often including the IP address needed to reach a host.
What happens when you type a domain name into a browser?
The system resolves the hostname, often through a recursive DNS resolver. If the answer is not cached, the resolver may follow the DNS hierarchy through root, TLD, and authoritative name servers before returning the required information.
What is a recursive DNS resolver?
A recursive resolver performs DNS resolution on behalf of clients and caches appropriate DNS information.
What is an authoritative DNS server?
An authoritative DNS server provides authoritative DNS information for zones it serves.
What is the difference between recursive and authoritative DNS?
A recursive resolver searches for answers for clients. An authoritative server publishes authoritative data for its DNS zones.
What does a root DNS server do?
Root DNS infrastructure directs resolvers toward the authoritative infrastructure for top-level domains.
What does a TLD DNS server do?
A TLD server provides delegation information that helps resolvers locate authoritative DNS servers for domains beneath that TLD.
Does the root DNS server know the IP address of every website?
No. Root servers primarily provide referrals toward TLD infrastructure rather than storing every website’s address.
What is DNS caching?
DNS caching stores DNS information temporarily so repeated queries can be answered without performing the complete lookup again.
What is TTL in DNS?
TTL, or Time to Live, controls how long DNS data can generally remain cached before it must be refreshed according to DNS caching rules.
What is NXDOMAIN?
NXDOMAIN indicates that the queried DNS name does not exist according to the DNS response.
What is SERVFAIL?
SERVFAIL indicates that a DNS server could not successfully complete the query. The underlying reason requires further troubleshooting.
What is dig +trace?
dig +trace follows the DNS delegation hierarchy and is useful for observing resolution from the root toward authoritative servers.
Is DNSSEC encrypted DNS?
No. DNSSEC provides mechanisms for authenticating DNS data and validating integrity. It does not itself encrypt DNS queries.
What is DNS over HTTPS?
DNS over HTTPS, or DoH, transports DNS queries over HTTPS.
What is DNS over TLS?
DNS over TLS, or DoT, transports DNS queries through TLS.
Can DNS return multiple IP addresses?
Yes. A hostname can have multiple A or AAAA records.
Why does DNS work for one user but not another?
Different users may use different recursive resolvers, cached information, DNS views, networks, or local configurations.
Why does an old IP still appear after changing a DNS record?
A recursive resolver or client may still have the previous record cached according to its applicable TTL.
Is DNS responsible for routing packets?
No. DNS provides naming and resource information. IP routing determines how packets travel through networks toward their destinations.
Conclusion
DNS resolution is one of the fundamental processes that makes the Internet usable.
When a client needs to reach a hostname such as www.example.com, it can rely on a recursive DNS resolver to obtain the necessary DNS information. If the answer is not already cached, the resolver can move through the hierarchical DNS system—from the root, to the appropriate TLD, and finally to an authoritative DNS server.
The resulting process can be summarized as:
Client
|
v
Recursive Resolver
|
v
Root
|
v
TLD
|
v
Authoritative DNS
|
v
DNS Answer
|
v
ClientBut the real strength of DNS comes from the combination of delegation, distributed authority, caching, and standardized resource records.
Understanding this architecture makes it much easier to troubleshoot problems involving websites, cloud services, Linux servers, email infrastructure, VPNs, enterprise networks, and distributed applications.
Continue with DNS Explained for the broader foundation, DNS Record Types Explained for A, AAAA, CNAME, MX, TXT, NS, PTR, and SRV records, TCP/IP Explained to understand the networking stack underneath DNS, and Computer Networking Explained for the wider network architecture.