How DNS actually works — from URL to loaded page

The problem DNS solves

Computers don't talk to names — they talk to IP addresses like 192.0.2.44 or 2001:db8::44. Humans, meanwhile, can't remember strings of numbers, and they'd be meaningless anyway if the underlying server moved.

DNS is the distributed database that bridges the gap: it maps names to numbers. You remember stackblip.com; DNS tells the network which IP to actually dial. And it does this without any single server knowing everything — the knowledge is spread across a hierarchy, which is both why it scales and why it confuses people.

The hierarchy — root, TLD, authoritative

DNS knowledge is organized in three layers, read right-to-left in any domain name:

• Root servers (.) — the top of the tree. There are 13 logical root server groups. They don't know your domain; they only know who handles each top-level domain.
• TLD servers (.com, .org, .io) — each top-level domain has its own servers. They know every domain under that TLD — specifically, which nameservers are authoritative for each.
• Authoritative nameservers — the servers your hosting provider runs (or that you point to). These hold the actual records for your domain. They're the only source of truth.

So stackblip.com reads as: "the com top-level domain, and within it, stackblip." Each layer only knows enough to point you to the next layer down.

The resolution journey

Your device doesn't walk this hierarchy itself. It asks a recursive resolver — your ISP's, or a public one like 1.1.1.1 or 8.8.8.8 — and the resolver does the legwork. Here's the full trip for a domain that isn't cached anywhere:

1. browser asks the OS: "what's the IP for stackblip.com?"
2. OS checks its own cache + hosts file, then asks the recursive resolver
3. resolver checks ITS cache — if fresh, we're done here (most lookups)
4. resolver asks a ROOT server (.)        → "ask the .com servers"
5. resolver asks the .com TLD servers     → "ask ns1.hostingco.com"
6. resolver asks the AUTHORITATIVE server → "stackblip.com = 192.0.2.44"
7. resolver returns the IP to your device, caches it for its TTL
8. browser opens a TCP (then TLS) connection to 192.0.2.44

TTL — and why "propagation" is a myth

Every DNS record carries a TTL (time to live): how long, in seconds, anyone is allowed to cache it. A TTL of 300 means "this answer is good for five minutes."

This is the entire mechanism behind the thing people call "DNS propagation" — except nothing actually propagates. When you change a record, the change is live on your authoritative nameserver immediately. What you're waiting for is every cached copy around the world to expire. Your coworker sees the new IP in seconds (their cache was empty); someone in another country sees the old one for hours (their resolver cached it with a long TTL).

The record types you'll actually meet

DNS stores a handful of record types. These six cover nearly everything you'll touch:

A      name → IPv4 address          stackblip.com.  300  A     192.0.2.44
AAAA   name → IPv6 address          stackblip.com.  300  AAAA  2001:db8::44
CNAME  name → another name (alias)  www.stackblip.com.  CNAME  stackblip.com.
MX     mail server for the domain   stackblip.com.  MX  10 mail.example.
TXT    arbitrary text (SPF, DKIM, domain verification)
NS     which nameservers are authoritative for the domain

The one that trips people up is CNAME: it points a name at another name, not an IP. www.stackblip.com is usually a CNAME to stackblip.com, which then resolves through its A record. Handy, but it means one extra lookup — and you can't put a CNAME on a bare domain (stackblip.com itself), which is why apex records exist.

Debugging DNS with dig

When a site won't load and you suspect DNS, dig is the tool. It asks exactly the question you want, and shows you exactly what came back:

# what IP does this resolve to? (+short = just the answer)
dig stackblip.com A +short
# → 192.0.2.44

# who's authoritative for this domain?
dig stackblip.com NS +short

# ask a SPECIFIC resolver — bypasses your local cache
dig stackblip.com A @8.8.8.8

# what does YOUR resolver say (compares against the source of truth)
dig stackblip.com A

The answers tell you which layer is failing:

• NXDOMAIN — the domain doesn't exist (or isn't registered, or the name is misspelled). Nothing to resolve.
• SERVFAIL — the resolver tried but couldn't get an answer. Often a broken nameserver or DNSSEC misconfiguration.
• Wrong IP — the record is stale (cache hasn't expired) or misconfigured at the authoritative server. Compare @8.8.8.8 against the authoritative NS to tell which.
• Resolves fine but still won't load — it's not DNS. The IP is reachable; the problem is above it (server down, firewall, or an HTTP-level error).

Wrap-up

DNS is a hierarchical, cached, distributed lookup: your resolver walks from the root servers down to your domain's authoritative nameserver, caches the answer for its TTL, and hands your browser an IP to dial. "Propagation" is just the world's caches expiring. And when something breaks, dig tells you exactly which layer to blame.

Once the IP is resolved, the real conversation begins — and that's where the HTTP status lookup takes over. If your freshly-moved site loads for you but not a client, it's almost always the TTL story above; if it loads but the browser blocks the response, that's a CORS conversation. And if your pages load but feel stale, the caching headers post explains the other half of the speed picture.