How does DNS work? A friendly walkthrough
Type a domain, see a website. In between, DNS does a quiet 50-millisecond dance through several specialized servers. Here's exactly how every name turns into an IP.
Type cloudflare.com into your browser. The page appears. In between, DNS — the Domain Name System — quietly translated that name into an IP address your computer could connect to. It happens billions of times a second worldwide, and almost nobody thinks about it until it breaks.
Here's the entire process, simplified.
Why DNS exists
Computers don't speak names — they speak IP addresses (104.16.132.229). Humans don't remember IPs — we remember names. DNS is the bridge.
Without DNS:
- You'd have to remember IPs for every site you visit.
- IPs change occasionally (servers move, hosting providers swap), so any saved bookmark would constantly break.
- Sharing a website would mean sharing a number that's meaningless to anyone trying to remember it.
DNS solves all three. You give it a name; it gives you back the current IP.
The four kinds of DNS server
When you ask "what's the IP of cloudflare.com," your request bounces through up to four specialized servers, each with a specific job.
1. The stub resolver (your device)
Tiny piece of software in your operating system. When an app asks for an IP, the stub resolver formats a DNS query and sends it to the next stop. It also caches recent answers, so visiting the same site five times doesn't trigger five new lookups.
2. The recursive resolver (your DNS server)
The big workhorse. This is the address you set in your network settings — your ISP's resolver, or a public one like 1.1.1.1.
It receives your query and either:
- Returns a cached answer if it has one (fast — under a millisecond), or
- Goes out and asks the rest of the system if it doesn't.
Most queries hit the cache. Recursive resolvers are doing the hard part of DNS for the entire internet.
3. The root nameservers
Thirteen logical servers (operated by different organizations, mirrored to hundreds of physical locations via anycast) that know where to find the TLD nameservers for every top-level domain — .com, .org, .uk, .io, etc.
When the recursive resolver doesn't have a cached answer, it asks a root nameserver: "Where are the nameservers for .com?"
The root replies with a list. The resolver picks one and continues.
4. The TLD nameservers
These know which authoritative nameservers handle each individual domain inside their TLD. The .com TLD nameservers know the authoritative nameservers for every .com domain — cloudflare.com, google.com, example.com, all of them.
The resolver asks: "Where are the nameservers for cloudflare.com?"
The TLD nameservers reply with a list — typically ns1.cloudflare.com and ns2.cloudflare.com for that domain.
5. The authoritative nameservers
The final hop. The resolver asks the authoritative nameserver: "What's the A record for cloudflare.com?"
The authoritative server is the source of truth — it returns the IP address that the domain owner has configured. Done.
The resolver caches the answer for the lifetime specified by the TTL (time to live) in the response, then returns it to your stub resolver, which returns it to your app.
The whole flow in one diagram
Your browser
↓ "what's the IP of cloudflare.com?"
Stub resolver (in your OS)
↓
Recursive resolver (1.1.1.1, 8.8.8.8, your ISP, etc.)
↓ "Where are .com nameservers?"
Root nameserver
↑ "Here are the .com TLD nameservers"
Recursive resolver
↓ "Where are cloudflare.com nameservers?"
.com TLD nameserver
↑ "Here are cloudflare.com's authoritative nameservers"
Recursive resolver
↓ "What's the A record for cloudflare.com?"
cloudflare.com authoritative nameserver
↑ "104.16.132.229"
Recursive resolver
↑ caches, returns to stub
Stub resolver
↑ returns to browser
Your browser
→ connects to 104.16.132.229
The whole thing typically takes 20–80 milliseconds for an uncached lookup. For a cached one, under a millisecond. Modern DNS is fast.
Different record types
DNS doesn't just store hostname-to-IP mappings. It stores many types of records:
| Type | What it stores |
|---|---|
| A | IPv4 address |
| AAAA | IPv6 address |
| CNAME | Alias from one name to another |
| MX | Mail server for the domain |
| TXT | Free-form text — used for SPF, DKIM, verification |
| NS | Authoritative nameservers for a domain |
| PTR | Reverse — IP to name (see reverse DNS) |
| CAA | Certificate Authority Authorization — restricts who can issue HTTPS certs |
| SRV | Service location records (used by SIP, XMPP, etc.) |
| SOA | Start of Authority — admin metadata for a zone |
You can look up any of these records using our hostname lookup tool.
Caching: the unsung hero
DNS works at internet scale because of caching. Without it:
- Every page load would trigger 5+ uncached lookups.
- Authoritative nameservers would buckle under load.
- The whole system would slow to a crawl.
With caching at every layer (browser, stub, recursive resolver, sometimes intermediate caches), most queries are answered locally. The TTL on each record tells caches how long to retain it — typically 300 seconds for high-change records (load balancing) up to 24 hours for stable infrastructure (TLD glue).
When you change a DNS record, "DNS propagation" is just waiting for caches to expire and refetch. There's no actual propagation in the network sense — it's just cache TTLs.
Encrypted DNS: DoT and DoH
Traditional DNS sends queries in plaintext. Anyone watching your network — your ISP, the cafe Wi-Fi, the network operator — can see every domain you look up.
Two modern protocols fix this:
- DoT (DNS over TLS): wraps queries in a TLS connection on port 853.
- DoH (DNS over HTTPS): wraps queries in HTTPS on port 443, indistinguishable from regular web traffic.
Both encrypt the contents of the query — domain names — from observers. Your ISP can still see you're talking to a DNS resolver, just not what you asked.
Cloudflare, Google, Quad9, and others all support DoT/DoH. Modern OS settings let you enable encrypted DNS with one toggle. iOS and Android both support it natively. macOS and Windows have it through profiles or third-party tools.
What happens when DNS breaks
When DNS fails or returns wrong data:
- NXDOMAIN — name doesn't exist. Either it really doesn't, or your resolver's cache is stale.
- SERVFAIL — server failure. Usually a misconfigured zone or unreachable authoritative server.
- DNS hijacking — your queries are being intercepted and rewritten to point you somewhere malicious. Encrypted DNS prevents this; plain DNS doesn't.
- Resolver outage — your resolver is down. Switch to
1.1.1.1or8.8.8.8and try again.
When the internet "feels broken" but specific tools work (you can ping IPs but not load websites), DNS is usually the first suspect.
Quick FAQ
Why does DNS feel slow sometimes? Cache miss + a slow authoritative server = a 200ms wait before the page even starts loading. Quality recursive resolvers (1.1.1.1, 8.8.8.8) keep this rare.
What's the difference between a domain registrar and a DNS provider? A registrar (Namecheap, Cloudflare Registrar, GoDaddy) sells you the domain name. A DNS provider (Cloudflare DNS, Route 53, Bunny DNS) hosts the authoritative records that say where the domain points. Often the same company, sometimes not.
Does DNS reveal what websites I visit? Yes — to whoever runs your resolver. Use encrypted DNS and a private resolver if that matters to you.
Why do some sites load instantly when others don't? DNS-cached vs uncached, geographic distance to the resolver, TTLs, and CDN edge availability all factor in. DNS is rarely the slowest part for a frequently-visited site.
TL;DR
- DNS turns names into IPs through five servers in sequence: your stub, a recursive resolver, root, TLD, and authoritative nameservers.
- Caching at every layer keeps the system fast.
- Modern encrypted DNS (DoT/DoH) hides queries from your network.
- When the internet feels broken, suspect DNS first.
Now you know what your computer does in those 30 milliseconds between you pressing Enter and the page starting to load.