The system that converts a domain name (tiffinbox.com) into the IP address of the server that hosts it. Browsers can only connect to numbers; DNS is the lookup that happens before any page loads.
Why it exists
Every server is reachable only at a numeric IP address, and those numbers are impossible to remember and change whenever the site moves to a new machine. If people had to type the number, one server migration would break every saved link, printed card, and bookmark. DNS exists so people and links can use a stable name while machines still get the number they need, and so you can repoint that name at a new server without anyone having to relearn it.
How it actually works
When someone types tiffinbox.com, the browser first checks whether it already knows the answer: its own cache, then the operating system's. If not, it asks a resolver, usually run by the ISP or a public one like Google's 8.8.8.8. If the resolver has no cached answer, it walks a hierarchy. It asks a root server, which points it to the servers responsible for .com. The .com servers point it to your domain's authoritative nameserver, the one machine holding the real records for tiffinbox.com. That server returns the IP. The whole chain usually finishes in tens of milliseconds.
Every answer carries a TTL (time to live), an instruction saying "you may remember this for N seconds." Caching at every layer is what makes DNS fast, and it is also why changes are slow: when you point your domain at a new server, resolvers worldwide keep serving the old cached answer until their TTLs expire. That is what "DNS propagation" means.
Before you step through, predict how many places get asked before an answer comes back.
shop.tiffinbox.com · not started
1
Browser cache (on your machine)
The browser checks its own memory of recent lookups first. This name is not there, so it asks the operating system.
2
OS cache (on your machine)
The operating system keeps a small cache of its own. Also empty for this name, so the request leaves your machine for a resolver.
3
Recursive resolver (your internet provider)
The resolver takes over the hunt. It holds no record for this name, so it starts at the top of the hierarchy.
4
Root nameserver (top of the tree)
The root does not know the address, but it knows who runs every .com name. It points the resolver at the .com servers.
5
.com nameservers (the .com registry)
The .com servers do not know the address either, but they know which nameserver is authoritative for tiffinbox.com. They hand back that pointer.
6
Authoritative nameserver (holds the record)
This server actually holds the record for tiffinbox.com. It returns the answer the resolver has been hunting for.
7
IP returned (back to your browser)
The address travels back down the chain and your browser opens a connection to it. The answer carries a TTL of 300 seconds, so every cache along the way keeps it for that long.
A record shop.tiffinbox.com → 203.0.113.42 TTL 300s
Names resolve to numbers through a short, cached hierarchy, which is why changes are fast to make but slow to propagate.
Subtopics
A senior PM walks you through it
A junior PM, stuck
It is launch day for the new site. It loads fine on my phone over mobile data, but the same URL does not load on the office wifi, and half the team sees the old site. The dev just said "propagation, check the TTL" and moved on. I cannot tell if this is a real outage I should escalate or something that fixes itself.
Nothing is down, and the record set proves it, so this is a five minute read that saves you an escalation. Below is TiffinBox's DNS record set as it looks mid-migration, the actual rows that got edited an hour ago. The one number that explains why your phone and the office disagree is the TTL column, and once you can read it you will know exactly when it clears.
tiffinbox.com DNS records, mid-migration
zonerecords (name TTL type value)
1tiffinbox.com. 86400 A 203.0.113.42
2# was A 198.51.100.10 until the switch an hour ago
3store.tiffinbox.com. 86400 CNAME tiffinbox.com.
4tiffinbox.com. 86400 TXT "v=verify vendor-9f2a"
Click a step to see the lines it points at.
Mistakes I've seen
Escalating "the site is down for some users" as an outage during a migration. If the server is healthy and only some networks see the old site, it is propagation on the TTL, a wait, not an incident.
Promising a clean cutover time without reading the TTL. An 86400 TTL means some users hold the old IP for a full day; the TTL is the honest ETA.
Editing the wrong record type. Repointing the site is the A record; the TXT is only ownership verification, so changing it does nothing for a migration.
Forgetting to lower the TTL before the switch. Dropping it to 60 seconds a few days ahead is what makes a cutover feel instant instead of dragging for a day.
Tell the team: "The A record was repointed an hour ago, but the TTL is 86400, 24 hours, so networks that cached the old IP will keep hitting the old server until tomorrow. It's propagation, not an outage. For the next migration, let's drop the TTL to 60 seconds a few days ahead so the switch is near-instant." You read a record set, found the TTL, and told an outage apart from a wait.
Where a PM meets this
Launch day for a new domain and the site works for some people but not others: that is propagation, not a bug.
"The site is down but the server is healthy" is often a DNS problem, not an application one.
A vendor asks you to verify domain ownership: that is a TXT record, and the ticket usually goes to whoever controls DNS, not your product engineers.
Hear it in a meeting
"We flipped DNS an hour ago, but TTL was 24 hours, so some users hit the old server until tomorrow."