How DNS Resolution Actually Works

Why this matters

DNS is one of the first things support engineers and sysadmins learn to distrust — not because it's unreliable, but because it's invisible right up until something breaks, at which point it looks exactly like every other kind of failure ("the site won't load"). Understanding the actual lookup chain turns "is it DNS?" from a guess into a five-minute check.

What you'll learn

The full path a hostname takes from your browser to an IP address, the different layers of caching involved (and why they cause "it works for me but not for you"), and the specific commands that let you inspect each step independently.

The lookup chain, step by step

When you type iamravi.com into a browser, here is what actually happens, in order:

1. Browser cache — the browser checks if it already resolved this hostname recently and cached the answer.
2. OS resolver cache — if not, the operating system checks its own local DNS cache (on Windows, this is what ipconfig /displaydns shows you).
3. Recursive resolver — if still not found, the OS asks a configured recursive resolver (often your ISP's, or a public one like Google's 8.8.8.8) to go find the answer.
4. Root servers — the recursive resolver asks one of the internet's 13 root server clusters, "who handles .com?"
5. TLD servers — the root server points to the .com TLD nameservers, which are asked "who handles iamravi.com?"
6. Authoritative nameserver — the TLD server points to the domain's actual authoritative nameserver (set by whoever manages the domain's DNS), which finally returns the real IP address.
7. The answer travels back down the chain, getting cached at each layer along the way (recursive resolver, OS, browser) for as long as the record's TTL allows.

This entire chain, on a cold cache, typically takes well under a second — but every layer that caches an answer is also a layer that can serve you a stale one after a record changes, which is the single most common source of "I updated the DNS record but it's still pointing to the old server" confusion.

Why TTL matters more than people expect

A DNS record's TTL (in seconds) tells every resolver in the chain how long they're allowed to keep serving their cached answer before checking again. A low TTL (say, 300 seconds) means changes propagate fast but every resolver has to re-check more often. A high TTL (say, 86400 seconds / 24 hours) is more efficient day-to-day but means a change you just made might not be visible to some users for a full day. The practical operational habit: lower a record's TTL well in advance of a planned change, then raise it again afterward once you've confirmed the new value is stable — this is a standard, low-risk technique for reducing the blast radius of a DNS cutover.

Commands to inspect each layer yourself

nslookup iamravi.com
nslookup iamravi.com 8.8.8.8
ipconfig /displaydns
ipconfig /flushdns

Running nslookup against a specific server (like 8.8.8.8 above) bypasses your own configured resolver, which is a fast way to check "is this a DNS problem specific to my network, or is it everywhere?" ipconfig /flushdns clears the local Windows resolver cache — often the actual fix for "I changed the record and it's still wrong on my machine specifically."

What's next

Once a hostname resolves to an IP address, the next layer is the actual HTTP request that IP address receives — covered in HTTP Status Codes You'll Actually See in Production. If you're troubleshooting a specific "can't reach the site" incident right now, jump straight to Isolating "Is It the Network or the App?".

Part of: Freshers, First Year

Mark this article as read

← Back to Guides

Next → How to Learn a New Technology on Your Own The single most valuable skill in a fast-moving field: teaching yourself a new tool or language without a course. A repeatable method that beats aimless tutorial-hopping.