How DNS Resolution Works: Step-by-Step Guide

How DNS Resolution Works: Step by Step

When you type www.example.com into a browser, the browser cannot connect to that name directly. It needs a network address, usually an IPv4 or IPv6 address, before it can contact the destination server. DNS resolution is the process that finds the DNS data associated with that domain name.

The important detail is that this is not necessarily one request to one global database. DNS is distributed. If the answer is not already cached, a recursive resolver may follow referrals through several parts of the DNS hierarchy until it reaches a server authoritative for the requested name. (rfc-editor.org)

Direct Answer

DNS resolution translates a domain-name query into the DNS records needed by an application. Your device usually sends the request to a recursive resolver. If the resolver has a valid cached answer, it can return it immediately. Otherwise, it can query the DNS hierarchy—typically starting with information about the root, then the relevant top-level domain, and finally an authoritative name server—to obtain the answer and cache it for later use. (rfc-editor.org)

Key Facts

Current DNS terminology distinguishes a stub resolver, which depends on another resolver to perform the full resolution process, from a recursive resolver, which performs recursion for the client. (rfc-editor.org)

What Is DNS Resolution?

The Domain Name System is a distributed naming system. Different name servers hold authoritative information for different parts of the domain namespace. A resolver hides much of that distribution from applications: the application asks a question, while the resolver handles the work required to find the relevant DNS records. (rfc-editor.org)

For example, a browser may need addresses for:

www.example.com

It can request an A record for IPv4, an AAAA record for IPv6, or both. An AAAA record stores a single IPv6 address. (rfc-editor.org)

DNS can also return other data, including CNAME aliases, mail-routing records, name-server records, and many other record types.

How Resolution Works

Assume a user wants to open:

www.example.com

and no useful answer is already cached.

1. The Application Requests a Lookup

The browser or application asks the system's resolver for DNS information about www.example.com.

In many systems, this local component behaves as a stub resolver. It does not independently walk through the entire DNS hierarchy. Instead, it sends the request to a recursive resolver configured by the operating system, network provider, enterprise, VPN, or DNS service. (rfc-editor.org)

2. The Recursive Resolver Checks Cache

Before contacting other DNS servers, the recursive resolver can check whether it already has a valid cached answer.

If it does, resolution can end here.

This is why a real DNS lookup does not necessarily contact root, TLD, and authoritative servers every time. Previously obtained addresses, delegations, or other records may still be cached.

3. The Resolver Uses the Root

If the resolver needs to perform the lookup itself and lacks sufficient cached information, it can start from the DNS root.

The root does not normally respond with the final IP address for www.example.com. Instead, it directs the resolver toward servers responsible for the relevant top-level domain—in this case, .com.

This referral model is a fundamental part of DNS resolution. RFC 1035 describes how a resolver may receive either the requested information or a referral to another name server. (rfc-editor.org)

4. The Resolver Queries the TLD

The resolver then asks an appropriate .com name server about example.com.

Again, the TLD server does not normally host the website's final address record. It provides delegation information identifying the authoritative name servers for the domain.

The resolver now knows where to ask the domain-specific question.

5. The Authoritative Server Answers

The resolver queries an authoritative server for the relevant zone.

If that server has the requested data, it can return the record. For example:

www.example.com.  3600  IN  A  192.0.2.10

The actual values depend on the domain configuration.

The response can also contain a CNAME. DNS uses CNAME records to identify one name as an alias of another canonical name. The resolver may then need to continue resolving that target. (rfc-editor.org)

6. The Answer Is Cached

DNS resource records carry a TTL—time to live—which controls how long cached data may be reused before the source should be consulted again. (rfc-editor.org)

If the resolver caches the answer, later users querying the same record may receive it without repeating the full lookup path.

The result is returned to the client, and the application can continue with the next network step, such as establishing a TCP or QUIC connection.

Why TTL Matters

TTL explains much of what people informally call DNS propagation.

DNS updates are not generally pushed simultaneously into every resolver cache worldwide. If a resolver still holds an older record whose TTL has not expired, it may continue returning that cached value. Another resolver without that cached record may already retrieve the new value.

So after a DNS change, two users can temporarily receive different answers without either resolver necessarily being broken.

INTERNAL LINK: DNS Propagation Explained

TTL is therefore a tradeoff. Longer caching can reduce repeated DNS work and authoritative query load, while shorter TTLs allow changes to become visible to caches sooner.

Negative Answers Are Cached Too

DNS caching is not limited to successful answers.

An authoritative server can report that a name does not exist, commonly through an NXDOMAIN response. DNS standards define negative caching so resolvers can temporarily cache these answers instead of repeatedly asking authoritative infrastructure about the same missing name. (rfc-editor.org)

This has an operational consequence: if a hostname was recently nonexistent and is then created, some resolvers may temporarily continue returning a cached negative response.

DNS and Performance

DNS resolution happens before an application can connect to a host whose address it does not yet know. A slow or unreliable DNS path can therefore delay the start of later connection work.

However, measuring "DNS speed" requires context. A cached lookup may be dramatically different from an uncached lookup, and the resolver may already have cached delegation information even when it does not have the final record.

For web-performance analysis, distinguish between:

• browser or operating-system caching,
• recursive-resolver caching,
• authoritative DNS response time,
• network latency to the chosen resolver,
• and uncached resolution through the DNS hierarchy.

A single DNS benchmark does not automatically represent what every real user experiences.

INTERNAL LINK: DNS Performance and Website Speed

How to Inspect Resolution

The dig utility is useful for examining DNS responses.

A normal lookup:

dig example.com A

An IPv6 lookup:

dig example.com AAAA

To inspect the delegation path:

dig +trace example.com A

BIND's documentation states that +trace starts from the root and follows referrals using iterative queries, displaying the servers involved in resolving the name. (bind9.readthedocs.io)

This makes it useful when diagnosing problems such as:

Root works
→ TLD delegation works
→ authoritative server fails

or:

Authoritative server returns the correct record
→ recursive resolver still has an older cached answer

One limitation is important: dig +trace does not necessarily reproduce the exact path used by a browser. Browsers, operating systems, VPNs, enterprise networks, or encrypted DNS configurations may use different resolvers.

Common Misconceptions

"DNS always contacts the root first." No. Cache may provide the final answer or enough delegation information to start farther down the hierarchy.

"The root server stores every website's IP address." No. DNS is distributed. Root servers primarily help direct resolution toward the appropriate TLD infrastructure.

"Changing DNS means everyone immediately sees the new value." Not necessarily. Existing cached answers may remain usable until their applicable TTLs expire.

"DNS normally returns only an IP address." No. DNS supports many resource-record types. Even address resolution may involve CNAME records before an A or AAAA answer is reached.

DNS Security and Privacy

DNSSEC and encrypted DNS solve different problems.

DNSSEC provides mechanisms for authenticating DNS data and checking its integrity. It does not provide confidentiality; the DNSSEC specification explicitly distinguishes authentication and integrity from secrecy. (rfc-editor.org)

DNS over TLS (DoT) uses TLS to provide privacy for DNS transport, while DNS over HTTPS (DoH) maps DNS queries and responses into HTTPS exchanges. (rfc-editor.org)

These technologies therefore should not be treated as interchangeable.

INTERNAL LINK: DNSSEC vs DoH vs DoT

DNS implementations also need to support both UDP and TCP. RFC 7766 updated the core requirements so general-purpose DNS implementations must support both transports. (rfc-editor.org)

SeoNest Recommendation

When diagnosing DNS problems, do not stop at "the domain resolves" or "the domain does not resolve."

Identify exactly which layer is producing the result:

Client
→ configured recursive resolver
→ cached data
→ root/TLD delegation
→ authoritative DNS
→ final A/AAAA/CNAME response

Then inspect TTLs, delegation, authoritative answers, and cached responses separately.

This approach is more reliable than repeatedly changing DNS records and waiting, because it shows whether the problem is in the zone itself, the delegation path, a resolver cache, or the client environment.

FAQ

What does DNS resolution do?

It retrieves DNS information associated with a domain name. For web traffic, that commonly includes discovering an IPv4 or IPv6 address that the browser can use to contact the host.

Does every DNS lookup reach an authoritative server?

No. A valid cached response can satisfy the request without another authoritative lookup.

What is a recursive DNS resolver?

It is a resolver that performs recursive service for a client, finding an answer rather than simply returning referrals when recursion is available. (rfc-editor.org)

What is the difference between recursive and authoritative DNS?

A recursive resolver finds answers for clients. An authoritative server serves authoritative DNS data for zones for which it is responsible.

Why can old DNS records still appear?

A resolver may still have an earlier answer in cache. TTL determines how long a resource record may normally remain cached before its source needs to be consulted again. (rfc-editor.org)

Does DNSSEC encrypt DNS queries?

No. DNSSEC provides DNS data-origin authentication and integrity mechanisms, but not confidentiality. Encrypted transports such as DoT and DoH address DNS transport privacy. (rfc-editor.org)

Final Takeaway

DNS resolution is best understood as a distributed lookup process, not a simple domain-to-IP conversion performed by one central server.

The client usually asks a recursive resolver. Cache may answer immediately. If more information is required, the resolver follows the DNS hierarchy and its referrals until it obtains authoritative data, then caches that result according to DNS caching rules.

Once you understand where the answer came from—client cache, recursive cache, delegation, or authoritative DNS—DNS performance problems and configuration errors become much easier to diagnose.

Sources

1. Paul Mockapetris — RFC 1034: Domain Names — Concepts and Facilities, November 1987. RFC Editor. RFC 1034
2. Paul Mockapetris — RFC 1035: Domain Names — Implementation and Specification, November 1987. RFC Editor. RFC 1035
3. Paul Hoffman, Kazunori Fujiwara — RFC 9499: DNS Terminology, March 2024. IETF / RFC Editor. RFC 9499
4. Mark Andrews — RFC 2308: Negative Caching of DNS Queries, March 1998. RFC Editor. RFC 2308
5. Roy Arends et al. — RFC 4033: DNS Security Introduction and Requirements, March 2005. IETF / RFC Editor. RFC 4033
6. Susan Thomson et al. — RFC 3596: DNS Extensions to Support IP Version 6, October 2003. RFC Editor. RFC 3596
7. John Dickinson et al. — RFC 7766: DNS Transport over TCP — Implementation Requirements, March 2016. IETF / RFC Editor. RFC 7766
8. Z. Hu et al. — RFC 7858: Specification for DNS over Transport Layer Security (TLS), May 2016. IETF / RFC Editor. RFC 7858
9. Paul Hoffman, Patrick McManus — RFC 8484: DNS Queries over HTTPS (DoH), October 2018. IETF / RFC Editor. RFC 8484
10. Internet Systems Consortium — BIND 9 dig documentation, BIND 9.20 documentation. BIND 9 Manual Pages