DNS (Domain Name System): What It Is and How Query Resolution Works
DNS resolution (recursive vs iterative) explained
The DNS (Domain Name System) is the Internet’s hierarchical naming system. It lets you use human-readable hostnames (e.g., example.com) while applications ultimately need IP addresses (e.g., IPv4 or IPv6) to connect to servers. DNS turns a name into the right resource record, most commonly an A/AAAA record.
At a high level, DNS lookups are handled by a chain of servers:
- A resolver (often provided by your ISP or OS)
- [Root servers]{def="Top-level DNS servers; direct resolvers to TLD servers}
- TLD servers
- Authoritative servers
This chain enables the system to find the correct authoritative source for the name and obtain the answer, while also improving performance via caching. Key parts of the process are standardized in classic DNS specifications (RFCs).2
Footnotes
-
DNS (Domain Name System) — Overview - High-level description of DNS hierarchy (root/TLD/authoritative) and naming purpose. ↩
-
RFC 1035 — Domain Names — Implementation and Specification - Defines DNS message format and resource record concepts (A/AAAA, NS, etc.). ↩
Key DNS terms (for the query-resolution story)
- Zone: e.g., the DNS zone for
example.com - Resource record (RR): answer entries in DNS
- TTL: controls how long answers may be cached before refresh
- Recursive query: typical for stub resolvers
- Iterative query: common between resolvers and DNS servers
Footnotes
-
Time to live (TTL) — DNS caching concept - Explains TTL semantics for caching and expiration behavior (applied to DNS records by resolvers). ↩
-
RFC 1034 — Domain Names — Concepts and Facilities - Core DNS concepts including query/resolution model and referrals/iterative behavior. ↩
How DNS query resolution works (worked example)
Consider a browser (or app) that needs to connect to www.example.com. The browser asks the system’s DNS resolver: “What is the IP address for www.example.com (type A or AAAA)?”
Below is the standard resolution flow an operating-system resolver may use (recursion from the perspective of the client, iterative referrals behind the scenes). The exact details can vary by configuration (e.g., recursion available or not), but the conceptual chain remains: root → TLD → authoritative → answer.2
Footnotes
-
RFC 1034 — Domain Names — Concepts and Facilities - Core DNS concepts including query/resolution model and referrals/iterative behavior. ↩
-
DNS (Domain Name System) — Overview - High-level description of DNS hierarchy (root/TLD/authoritative) and naming purpose. ↩
Step-by-step: resolving a hostname like www.example.com
- 1Step 1
The client asks its configured resolver for the DNS A/AAAA record for
www.example.com.Footnotes
-
RFC 1034 — Domain Names — Concepts and Facilities - Core DNS concepts including query/resolution model and referrals/iterative behavior. ↩
-
- 2Step 2
If the resolver has a cached RRset and the cached entry is still valid via its TTL, it can answer immediately without contacting upstream DNS servers.
Footnotes
-
Time to live (TTL) — DNS caching concept - Explains TTL semantics for caching and expiration behavior (applied to DNS records by resolvers). ↩
-
- 3Step 3
If not cached, the resolver performs iterative resolution: it queries a root server to locate the correct TLD server for
.com.2Footnotes
-
DNS (Domain Name System) — Overview - High-level description of DNS hierarchy (root/TLD/authoritative) and naming purpose. ↩
-
RFC 1034 — Domain Names — Concepts and Facilities - Core DNS concepts including query/resolution model and referrals/iterative behavior. ↩
-
- 4Step 4
The resolver queries the
.comTLD server. The TLD server responds with a referral to the authoritative servers for theexample.comzone.2Footnotes
-
DNS (Domain Name System) — Overview - High-level description of DNS hierarchy (root/TLD/authoritative) and naming purpose. ↩
-
RFC 1034 — Domain Names — Concepts and Facilities - Core DNS concepts including query/resolution model and referrals/iterative behavior. ↩
-
- 5Step 5
The resolver queries the authoritative server for
example.comforwww.example.com’s record(s). The authoritative server returns the resource record answer and a TTL value.2Footnotes
-
RFC 1035 — Domain Names — Implementation and Specification - Defines DNS message format and resource record concepts (A/AAAA, NS, etc.). ↩
-
Time to live (TTL) — DNS caching concept - Explains TTL semantics for caching and expiration behavior (applied to DNS records by resolvers). ↩
-
- 6Step 6
The resolver supplies the final A/AAAA result to the client and caches it for the TTL duration, so future lookups are faster.
Footnotes
-
Time to live (TTL) — DNS caching concept - Explains TTL semantics for caching and expiration behavior (applied to DNS records by resolvers). ↩
-
Example walk-through (what each server effectively provides)
For www.example.com, the resolver ultimately needs the RRset for the exact name and the desired type.
- Client → Resolver: asks for
A(IPv4) orAAAA(IPv6) forwww.example.com. - Resolver → Root: obtains which TLD servers handle
.com. - Resolver → .com TLD: obtains where the authoritative servers for
example.comlive. - Resolver → Authoritative server: obtains the actual IP address answer(s) for
www.example.com. - Caching: resolver stores the answer for the record’s TTL, reducing future latency.
This is consistent with the DNS resolution model described in foundational DNS RFCs.2
Footnotes
-
Time to live (TTL) — DNS caching concept - Explains TTL semantics for caching and expiration behavior (applied to DNS records by resolvers). ↩
-
DNS (Domain Name System) — Overview - High-level description of DNS hierarchy (root/TLD/authoritative) and naming purpose. ↩
-
RFC 1034 — Domain Names — Concepts and Facilities - Core DNS concepts including query/resolution model and referrals/iterative behavior. ↩
Pro Tip: caching changes the observed “server hops”
If a resolver has the answer cached (and TTL hasn’t expired), your DNS lookup may complete without contacting root/TLD/authoritative servers. The process is still the same conceptually—caching just short-circuits upstream queries.
Footnotes
-
Time to live (TTL) — DNS caching concept - Explains TTL semantics for caching and expiration behavior (applied to DNS records by resolvers). ↩
Warning: DNS answers can be multiple records and may vary by query type
Lookups can return multiple resource records (e.g., several IPv4 A records). Also, asking for A vs AAAA changes the outcome, and resolvers may return different results depending on caching and record freshness.2
Footnotes
-
RFC 1035 — Domain Names — Implementation and Specification - Defines DNS message format and resource record concepts (A/AAAA, NS, etc.). ↩
-
Time to live (TTL) — DNS caching concept - Explains TTL semantics for caching and expiration behavior (applied to DNS records by resolvers). ↩
DNS resolution stages (conceptual cost when uncached)
If uncached, resolution typically traverses root → TLD → authoritative; caching can reduce this.
DNS resolution lifecycle (for one lookup)
Client asks resolver
1) Query initiatedClient requests A/AAAA for the hostname."
Resolver may answer from cache
2) Cache checkIf TTL-valid cached data exists, the chain ends."
Root → TLD referrals
3) Name discoveryResolver learns where the zone is managed."
Authoritative server returns RRset
4) Authoritative answerResolver receives final answer and TTL."
Client gets IP and resolver caches
5) Cache and respondFuture requests can be faster."
Common confusions
Knowledge Check
In typical DNS resolution, which server’s job is to point resolvers to the correct TLD servers?