How does DNS resolution work, step by step?
Your device asks a recursive resolver, which checks its cache and, if needed, asks a root server, then the TLD server (like .com), then the domain's authoritative server, which returns the IP address. Every answer carries a TTL, so resolvers and devices cache it and skip most of these steps next time.
Explain it simply
Suppose you want the phone number of a particular professor at IIT Bombay. You ask your college's helpful office clerk (the recursive resolver). If the clerk already has it written down, you get it at once. If not, the clerk calls a national directory that only knows "for IITs, call this ministry number" (root). The ministry says "for IIT Bombay, call their main office" (TLD). The main office actually has the professor's number (authoritative). The clerk writes it down with a note "valid for one day" (TTL) so the next student gets it instantly.
You made one request. The clerk did all the running around.
Example
You can watch the whole chain with dig:
dig +trace www.example.comA simplified view of what happens:
1. Browser/OS cache: no entry for www.example.com
2. Stub resolver -> recursive resolver (say 1.1.1.1): "A record for www.example.com?"
3. Resolver -> root server: "Ask the .com servers: a.gtld-servers.net ..."
4. Resolver -> .com TLD server: "Ask example.com's servers: ns1.example-dns.net ..."
5. Resolver -> authoritative NS: "www.example.com 300 IN A 93.184.215.14"
6. Resolver caches it for 300 seconds and returns it to youThe 300 is the TTL in seconds. For the next five minutes, anyone using that resolver gets the answer from cache.
How it works
The players.
- Stub resolver: the small DNS client in your OS. It knows only one thing: the address of a recursive resolver, usually given by your router or ISP, or set manually (such as 8.8.8.8 or 1.1.1.1).
- Recursive resolver: does the full lookup for you and caches results.
- Root servers: 13 named server identities (a to m), each run on many machines worldwide using anycast. They do not know any domain's IP; they point to the right TLD servers.
- TLD servers: for
.com,.in,.organd so on. They point to the domain's authoritative name servers. - Authoritative servers: hold the real records for a domain, managed by whoever runs the domain's DNS (Cloudflare, Route 53, the registrar).
Recursive vs iterative. Your device sends a recursive query: "give me the final answer". The resolver then makes iterative queries: each server replies with either the answer or a referral to someone closer to it.
Caching at every level. The browser, the OS, sometimes the home router, and the resolver all cache answers until the TTL runs out. Resolvers also cache the referrals, so they rarely need to ask the root at all. Failed lookups are cached too (negative caching), based on the zone's SOA record.
Common record types. A (IPv4 address), AAAA (IPv6), CNAME (alias to another name), MX (mail servers), NS (name servers for a zone), TXT (text, used for domain verification and email security like SPF).
DNS normally uses UDP on port 53 because queries are small. It switches to TCP when a response is too large or for zone transfers between servers.
Real-world use
When you move a site to a new server, you lower the TTL a day in advance (say from 86400 to 300 seconds), so caches pick up the new IP quickly after the switch. CDNs and big services use DNS to send users to a nearby data centre. Many college and office networks block sites by making their resolver return nothing, which is why changing the resolver sometimes "fixes" access.
Common mistakes
- Saying the root server returns the IP address. It only refers you to the TLD.
- Thinking a DNS change is instant everywhere. Old answers stay cached until their TTL expires; "propagation" is really cache expiry.
- Confusing the registrar (where you bought the domain) with the DNS host (where the records live).
- Putting a CNAME at the root of a domain (
example.com). Standard DNS does not allow it alongside the required NS and SOA records; providers offer ALIAS or CNAME flattening instead.
What to say in the interview
"The OS stub resolver sends a recursive query to a recursive resolver, such as the ISP's or 1.1.1.1. If the answer is not cached, the resolver queries iteratively: a root server refers it to the TLD servers, the TLD server refers it to the domain's authoritative name servers, and the authoritative server returns the record, like an A record with the IP. Each record has a TTL, and the browser, OS and resolver cache it for that long, so most lookups never leave the cache. DNS mostly uses UDP port 53, falling back to TCP for large responses."
Follow-up questions
- What is the difference between a recursive and an iterative query?
- What is a TTL and how would you plan a DNS migration around it?
- What is the difference between an A record and a CNAME?
- What are DNS over HTTPS and DNSSEC?
Go deeper
Read these once the basics above feel easy.
Glue records solve a chicken-and-egg problem: if example.com's name server is ns1.example.com, the resolver cannot look it up without already knowing it. So the .com TLD server includes the name server's IP address alongside the referral. Anycast lets one IP address, such as a root server's or 1.1.1.1, be announced from many locations, and routing sends you to the nearest one.
Plain DNS is unencrypted and unauthenticated. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the path between you and the resolver, hiding queries from the local network. DNSSEC solves a different problem: it signs records so a resolver can verify they came from the real zone owner, which defends against cache poisoning, but it does not encrypt anything. A full answer distinguishes privacy (DoH, DoT) from authenticity (DNSSEC).