How does DNS actually work?
You type google.com into your browser… and within a fraction of a second, the page loads.
No directions. No map. Just a name.
Feels simple, right?
But here’s what most people don’t see: your browser doesn’t actually know where google.com is.
So how does your browser figure out where to go?
Who does it ask first?
And how does the internet always seem to find the right place, every single time? Here’s what actually happens.
First — why does DNS exist at all?
Every device on the internet has an IP address. Google’s servers? 142.250.80.46. Your favourite news site? Another string of numbers. Everything, underneath, is a number.
But humans are terrible with numbers and great with names. So someone had to build a translation layer — something that converts google.com into 142.250.80.46 so your browser knows where to go.
Before DNS existed, there was literally a text file. A single file, called HOSTS.TXT, maintained by a research institute in California. Every computer on the internet downloaded it periodically. It listed every hostname and its IP address.
This worked fine when the internet had a few hundred machines.
Then the internet grew. And the file became unmanageable. And in 1983, a computer scientist named Paul Mockapetris invented DNS (Domain Name System) — a distributed, hierarchical, automatic system that could scale to billions of devices.
It’s been running ever since. Mostly unchanged.
Step 1: Your browser checks its own memory first
Before anything goes to the internet, your browser asks itself: “Have I looked this up recently?”
Every DNS response comes with a timer attached — called a TTL (Time To Live). It says: “This answer is valid for X seconds. After that, ask again.”
If you visited Google five minutes ago and the TTL is an hour, your browser already knows the answer. No lookup needed. Done.
This is called caching — and it’s happening constantly, invisibly, on every device you own. Your browser has a cache. Your operating system has a cache. Your router has a cache. They all try to answer DNS questions locally before bothering the internet.
But let’s say it’s a fresh lookup. Nobody has the answer. Now things get interesting.
Step 2: Your device asks its “favourite contact” — the Recursive Resolver
Your device forwards the question to a server called a recursive resolver. This is usually run by your ISP, or by Google (8.8.8.8), or Cloudflare (1.1.1.1) if you've changed your DNS settings.
The resolver’s entire job is to go find the answer for you. Think of it as a very motivated research assistant. You give it a question, it goes and figures it out, it comes back with an answer.
It does this by climbing a hierarchy. And the hierarchy is where DNS gets genuinely elegant.
Step 3: The hierarchy — it starts at the root
Here’s how the internet is organised, from the top down:
. → .com → google.com → mail.google.com
That single dot at the top? That’s the root zone — the very top of the DNS hierarchy. It’s managed by an organisation called IANA, and it’s served by 13 sets of servers distributed around the entire world.
These root servers don’t know where google.com is. But they know who does.
The resolver asks a root server: “Where can I find out about .com domains?"
The root server replies: “Talk to Verisign. They handle .com."
Step 4: The TLD nameserver — one level down
The resolver now talks to Verisign’s nameservers — the TLD (Top Level Domain) nameservers for .com.
These servers don’t know where google.com is either. But they know who Google told to handle their DNS.
They reply: “Google’s own nameservers handle google.com. Go talk to ns1.google.com."
One more step.
Step 5: The authoritative nameserver — the source of truth
The resolver finally reaches Google’s own nameservers — the authoritative nameservers for google.com. These are the servers Google controls. They have the actual answer.
“The IP address for google.com is 142.250.80.46."
Get Simran’s stories in your inbox
Join Medium for free to get updates from this writer.
This is called an authoritative answer — it came directly from the source, not from a cache somewhere.
The resolver takes that answer, caches it for the duration of the TTL, and sends it back to your device. Your browser connects to 142.250.80.46. The page loads.
The entire journey — root → TLD → authoritative — took maybe 50 milliseconds.
The whole thing, visualized as a conversation:
- Your browser: Hey resolver, what’s the IP for
google.com? - Resolver: No idea, let me find out. [asks root server] Who handles
.com? - Root server: Verisign does. Go ask them.
- Resolver: [asks Verisign] Who handles
google.com? - Verisign: Google’s nameservers do. Go ask them.
- Resolver: [asks Google’s nameserver] What’s the IP for
google.com? - Google’s nameserver:
142.250.80.46. - Resolver: [back to your browser] It’s
142.250.80.46. - Your browser: Got it. [loads the page]
The elegant part? None of those servers had to know everything. Each one only needed to know who to ask next. The knowledge is distributed across thousands of servers worldwide, and the system still finds any answer in milliseconds.
DNS record types — it’s not just IP addresses
DNS stores more than just “where is this website.” Different questions need different record types.
- A record — maps a domain to an IPv4 address. The classic lookup.
- AAAA record — same thing, but for IPv6 addresses.
- MX record — tells you which server handles email for a domain. When you send an email to
someone@company.com, your MTA looks up the MX record. (Sound familiar? It's what we covered in the email article.) - CNAME — an alias. Points one name to another.
www.google.commight be a CNAME forgoogle.com. - TXT record — free-text field. Used for SPF, DKIM, DMARC — the email authentication standards. Also used to prove domain ownership to third-party services.
Every type is a different question DNS can answer.
The thing nobody tells you about DNS changes
Ever updated a DNS record and wondered why it takes hours to “propagate”?
Here’s why: every resolver that looked up your domain cached the old answer. They’ll keep using it until the TTL expires. If your old record had a TTL of 24 hours and you just changed it, some resolvers will keep serving the old answer for up to 24 hours — because that’s what you told them to do.
This is why developers lower their TTL to 5 minutes before making a DNS change. Then change it. Then raise the TTL back. The window of incorrect answers shrinks from hours to minutes.
It’s one of those things you only learn after it bites you.
The short version
Every time you visit a website, your device:
- Checks its own cache first
- Asks a recursive resolver if it doesn’t know
- The resolver climbs the hierarchy: root → TLD → authoritative nameserver
- Gets the IP address
- Caches the answer until the TTL expires
- Repeats this thousands of times a day without you ever noticing
The entire internet’s naming system runs on a protocol from 1983. It handles trillions of queries a day. And it almost never fails.
Not bad for something most people have never heard of.
Next time you type a URL, you’ll know: your browser isn’t finding a website. It’s asking a question. And the internet has built an extraordinarily clever system just to answer it.
In under a hundred milliseconds. Every single time.
This is part of a series on the invisible infrastructure behind everyday technology. Next up: how TLS keeps everything encrypted — and why the padlock in your browser means more than you think.
