How DNS Works

What Is It?

DNS stands for Domain Name System. It's the reason you can type google.com instead of 142.250.185.46. Without DNS, you'd need to memorise IP addresses for every site you visit — which would make the web unusable.

But DNS is more than just a lookup table. It's a distributed, hierarchical, cached system spread across millions of servers worldwide. No single server knows all domain names — instead, they refer each other in a chain until someone has the answer.

This architecture is why "DNS propagation" is a real thing. When you change a DNS record, it doesn't update everywhere instantly — it spreads through the cache hierarchy over time, based on something called TTL. Understanding this saves hours of debugging when you launch a new domain or point it somewhere new.

How It Actually Works

Every DNS lookup follows a chain of authority. Here's the full resolution process for example.com:

Your browser
    ↓ "What's the IP for example.com?"
Your OS (checks local cache first)
    ↓ not in cache
Recursive Resolver (your ISP's, or 8.8.8.8, or 1.1.1.1)
    ↓ "Who's authoritative for .com?"
Root Nameserver (13 root clusters worldwide)
    ↓ "Try the .com TLD nameserver"
TLD Nameserver (for .com — run by Verisign)
    ↓ "The authoritative nameserver for example.com is ns1.example.com"
Authoritative Nameserver (run by whoever owns example.com)
    ↓ "example.com → 93.184.216.34"
Recursive Resolver
    ↓ caches the answer for TTL seconds
Your browser
    ↓ connects to 93.184.216.34

Let's break down each step:

Root Nameservers

There are 13 sets of root nameservers (named a.root-servers.net through m.root-servers.net), each actually a cluster of hundreds of servers worldwide. They only know one thing: which nameservers are responsible for each top-level domain (.com, .org, .io, etc.).

TLD Nameservers

Operated by registries like Verisign (.com), the Public Interest Registry (.org), etc. They know which nameservers are authoritative for each registered domain within their TLD.

Authoritative Nameservers

These are the ones your domain registrar or DNS host (Cloudflare, Route 53, etc.) runs. They have the actual records: A records (domain → IPv4), AAAA records (domain → IPv6), CNAME records (alias → another domain), MX records (mail servers), TXT records (verification, SPF, DKIM), and more.

The Recursive Resolver

This is the key player that does all the work. It's usually provided by your ISP, or you can configure 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). It walks the chain from root → TLD → authoritative, caches the result, and serves it to everyone behind it.

TTL (Time To Live)

Every DNS record has a TTL measured in seconds. When a resolver caches a record, it keeps it for that many seconds before asking again. If your A record has TTL: 3600, it'll be cached for 1 hour. This is why DNS changes take time to propagate — every resolver in the chain is serving its cached version until the TTL expires.

DNS Record:
example.com.  3600  IN  A  93.184.216.34
                ↑
         TTL in seconds (1 hour)

What "DNS propagation" actually means

When you change your DNS records, you're updating the authoritative nameserver immediately. But millions of recursive resolvers around the world already have the old answer cached. They'll keep serving it until their cached TTL expires and they re-fetch. With a 24-hour TTL, some resolvers might serve the old answer for up to 24 hours after you made the change.

Pro tip: Lower your TTL to 300 seconds (5 minutes) before making a DNS change. Wait for caches to expire. Make the change. Then raise TTL again after confirming everything works.

The Jargon Decoded

• A Record — Maps a domain name to an IPv4 address. The most common record type. example.com → 93.184.216.34
• AAAA Record — Maps a domain name to an IPv6 address. Same as A but for the newer address format.
• CNAME Record — Canonical Name — an alias that points to another domain name rather than an IP. www.example.com → example.com. Can't be used at root domain (use ALIAS or ANAME instead).
• MX Record — Mail Exchange — tells other mail servers where to deliver email for your domain.
• TXT Record — Free-form text. Used for domain ownership verification, SPF (email anti-spoofing), DKIM (email signing keys), and more.
• TTL (Time To Live) — How long resolvers should cache a DNS record, in seconds. Lower = faster propagation but more DNS queries.
• Recursive Resolver — The DNS server that does the full lookup chain on your behalf. Usually your ISP's server or a public one like 8.8.8.8.
• Authoritative Nameserver — The DNS server that holds the actual records for your domain. The final answer in the chain.
• NS Record — Nameserver record — tells the TLD nameserver which nameservers are authoritative for your domain.

Why This Matters When You're Building

DNS is the first step in every web request. If it's slow or broken, everything else is broken. A DNS lookup typically adds 20-120ms to the first connection to a new domain, which is why browsers cache DNS results aggressively.

When you're deploying a new app or moving infrastructure, DNS is where things go wrong in non-obvious ways:

• You moved your server but forgot DNS still points to the old IP. Users in your city (whose resolvers refreshed) can reach it. Users across the world can't. "It works for me" is a DNS propagation issue.
• You added a www CNAME but forgot the root domain. example.com doesn't work but www.example.com does.
• You set TXT records for email verification but they're not showing up — because the old empty record is still cached.
• Your app makes API calls to api.example.com but doesn't cache the DNS result, so it does a new lookup on every request. DNS adds up.

What To Tell The AI

"I just pointed my domain at a new server IP and it's working for me but not for my users in other countries. Explain what's happening and how long until it resolves itself. What should I check to diagnose the state of propagation?"

"Set up the DNS records I need for: hosting my app on Vercel, sending email through Resend, and verifying ownership with Google Search Console. Give me the exact record types, names, and values."

"My DNS TTL is 86400 seconds. I need to migrate to a new server next week. Walk me through the exact steps and timing to minimise downtime using TTL management."

"Explain what a CNAME flattening / ALIAS record is and why I can't use a regular CNAME at my root domain. My DNS host is Cloudflare — what should I use instead?"

"I'm building a multi-tenant SaaS where customers bring their own domains. Walk me through the DNS architecture — what records do customers need to create, what do I need to verify, and how does the SSL certificate work?"

Common Misconceptions

"DNS changes take 24-48 hours." DNS propagates based on TTL, not an arbitrary window. If your TTL is 300 seconds, changes propagate in 5 minutes once the old cache expires. The "24-48 hours" rule of thumb was based on old records with 86400-second TTLs. Check your TTL first.

"Changing my DNS at the registrar is the same as changing my DNS records." The registrar stores which nameservers are authoritative for your domain (the NS records). The nameservers store the actual records (A, CNAME, MX, etc.). These are two different things. Changing nameservers (e.g., moving from GoDaddy DNS to Cloudflare) has its own propagation delay — and TTL doesn't apply here, the TLD nameserver has its own caching.

"The internet has one DNS." There are millions of resolvers. Some (like 8.8.8.8) update quickly. Some (old ISP resolvers) may over-cache past TTL. You can check propagation globally at dnschecker.org — it shows what different resolvers around the world see.

"A CNAME can point to anything." CNAMEs point to another domain name, not an IP. They can't be used at the root domain (example.com) — only on subdomains (www.example.com). Using a CNAME where you need an A record, or at the apex, is one of the most common DNS mistakes when setting up Vercel/Netlify/etc.

Sources

• Cloudflare Learning — What is DNS? — Excellent visual explainer with diagrams
• How DNS Works (Comic) — Quirky but genuinely excellent step-by-step visual walkthrough
• RFC 1034 — Domain Names: Concepts and Facilities — The original DNS specification
• DNS Checker — Real-time tool to see DNS propagation across global resolvers
• Julia Evans — DNS zine — Illustrated deep dive into DNS that's both accurate and approachable