Jul 1, 2026 · 7 min read

How DNS Actually Works — A Developer's Guide

You type example.com into your browser and a website appears. Between your keystroke and that first pixel rendering, a chain of lookups happens that most developers never think about — until something breaks.

DNS is the system that translates human-readable domain names into IP addresses. It’s often called “the phone book of the internet,” but it’s more like a distributed, cached, hierarchical phone book with millions of copies that don’t always agree with each other.

The Resolution Chain

When your browser needs to find the IP address for blog.example.com, it doesn’t just ask one server. It walks through a chain of caches and servers, stopping as soon as it gets an answer.

You type: blog.example.com

  ┌─────────────────┐
  │  Browser Cache   │ ── cached? → done
  └────────┬────────┘
           │ miss
  ┌────────▼────────┐
  │    OS Cache      │ ── cached? → done
  └────────┬────────┘
           │ miss
  ┌────────▼────────┐
  │   Recursive      │ ── cached? → done
  │   Resolver       │    (your ISP or 8.8.8.8)
  └────────┬────────┘
           │ miss
  ┌────────▼────────┐
  │   Root Server    │ ── "I don't know, but ask
  │   (.)            │     the .com TLD server"
  └────────┬────────┘
           │
  ┌────────▼────────┐
  │   TLD Server     │ ── "I don't know, but ask
  │   (.com)         │     example.com's nameserver"
  └────────┬────────┘
           │
  ┌────────▼────────────┐
  │  Authoritative       │ ── "blog.example.com
  │  Nameserver          │     is 93.184.216.34"
  │  (ns1.example.com)  │
  └──────────────────────┘

  Answer flows back up the chain.
  Each layer caches it for next time.

Let’s walk through each step.

Browser cache. Your browser remembers recent lookups. Chrome keeps DNS entries for about 60 seconds. You can see them at chrome://net-internals/#dns.

OS cache. Your operating system has its own DNS cache. On macOS, the dscacheutil service handles this. On Linux, systemd-resolved or nscd does the job. On Windows, it’s the DNS Client service.

Recursive resolver. This is the workhorse. It’s usually run by your ISP, or it’s a public resolver like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. If it doesn’t have the answer cached, it goes hunting — starting at the root.

Root servers. There are 13 root server clusters (labeled A through M), operated by organizations like ICANN, Verisign, and NASA. They don’t know where blog.example.com lives, but they know where to find the .com TLD servers.

TLD servers. The Top-Level Domain servers for .com, .org, .io, etc. They know which authoritative nameservers are responsible for each domain under their TLD.

Authoritative nameserver. This is the final source of truth. It holds the actual DNS records for the domain and returns the IP address (or whatever record was requested).

The whole process typically takes 20–120 milliseconds on a cold lookup. Cached lookups are near-instant.

DNS Record Types

DNS isn’t just about mapping names to IPs. Different record types serve different purposes.

A record — Maps a domain to an IPv4 address. The most common record type.

example.com.    A    93.184.216.34

AAAA record — Maps a domain to an IPv6 address. Same as A, but for the newer protocol.

example.com.    AAAA    2606:2800:220:1:248:1893:25c8:1946

CNAME record — An alias that points one domain to another. The resolver follows the chain until it finds an A or AAAA record.

www.example.com.    CNAME    example.com.

CNAMEs can’t coexist with other records on the same name. You can’t have a CNAME and an MX record on example.com. This is why many DNS providers offer “ALIAS” or “ANAME” as a workaround for root domains.

MX record — Specifies mail servers for the domain. The priority number determines which server to try first (lower = higher priority).

example.com.    MX    10 mail1.example.com.
example.com.    MX    20 mail2.example.com.

TXT record — Stores arbitrary text. Used for domain verification (SSL certificates, Google Search Console), email authentication (SPF, DKIM, DMARC), and other purposes.

example.com.    TXT    "v=spf1 include:_spf.google.com ~all"
example.com.    TXT    "google-site-verification=abc123..."

NS record — Specifies which nameservers are authoritative for the domain. These are set at your domain registrar.

example.com.    NS    ns1.cloudflare.com.
example.com.    NS    ns2.cloudflare.com.

TTL and “Propagation”

Every DNS record has a TTL (Time To Live) — a number in seconds that tells resolvers how long to cache the answer. When you see a TTL of 3600, that means resolvers will cache the record for one hour before asking again.

example.com.    3600    A    93.184.216.34
                 ↑
                TTL: cache for 1 hour

So what about the “48 hours of propagation” everyone warns about?

It’s not really propagation. DNS doesn’t push updates to servers around the world. Instead, cached copies expire at different times. If your old record had a TTL of 86400 (24 hours), some resolvers cached it right before you changed it — they’ll hold the old value for up to 24 hours.

The “48 hours” is a worst-case estimate that accounts for:

High TTLs on old records
Some resolvers ignoring TTL and caching longer
NS record changes at the registrar level (which have their own TTL)

How to speed it up: Lower your TTL to 300 (5 minutes) a day or two before making the change. After the old high-TTL entries expire, all resolvers will be fetching fresh records every 5 minutes. Then make your change. Then raise the TTL back up once everything is stable.

DNS over HTTPS (DoH)

Traditional DNS queries are sent in plaintext over UDP. Anyone between you and the resolver — your ISP, a coffee shop’s WiFi, a compromised router — can see every domain you visit.

DNS over HTTPS (DoH) wraps DNS queries inside HTTPS encrypted connections. Your DNS lookups become indistinguishable from regular web traffic.

Most modern browsers support DoH:

Firefox uses Cloudflare’s DoH by default in the US
Chrome, Edge, and Brave support it if your system resolver offers DoH
Safari supports it on macOS and iOS

You can also configure it system-wide by pointing your resolver to https://dns.cloudflare.com/dns-query or https://dns.google/dns-query.

DoH doesn’t make you anonymous — your resolver still sees your queries — but it prevents eavesdropping on the path between you and the resolver.

Common Developer Scenarios

Custom domain setup

When you deploy to Vercel, Netlify, or Railway and add a custom domain, you’re typically doing one of:

A record pointing your root domain (example.com) to their IP
CNAME record pointing www.example.com to their hostname (e.g., cname.vercel-dns.com)

Some providers use ALIAS/ANAME records for root domains since CNAMEs technically can’t be used at the zone apex.

Email DNS records

Setting up email (Google Workspace, Fastmail, etc.) requires multiple records:

MX records — where to deliver mail
TXT record for SPF — which servers can send mail on your behalf
TXT record for DKIM — cryptographic signature for outgoing mail
TXT record for DMARC — policy for handling failed SPF/DKIM checks

Missing any of these means your emails land in spam — or don’t arrive at all.

SSL certificate verification

Certificate authorities like Let’s Encrypt need to verify you own the domain before issuing an SSL certificate. One common method is DNS verification: they give you a TXT record to add, then check for it.

_acme-challenge.example.com.    TXT    "gfj9Xq...Rg85nM"

This is especially useful for wildcard certificates, where HTTP verification isn’t an option.

Debugging DNS

When something isn’t resolving correctly, these tools help you figure out where the problem is.

dig

The go-to tool for DNS debugging. Available on macOS and Linux (install dnsutils or bind-utils if missing).

# Basic lookup
dig example.com

# Query a specific record type
dig example.com MX
dig example.com TXT

# Query a specific nameserver directly
dig @8.8.8.8 example.com

# Trace the full resolution chain
dig +trace example.com

# Short output (just the answer)
dig +short example.com

dig +trace is the most useful — it shows you exactly which servers are being queried at each step, so you can see where a stale or wrong answer is coming from.

nslookup

Available everywhere, including Windows. Less powerful than dig but gets the job done.

# Basic lookup
nslookup example.com

# Query a specific record type
nslookup -type=MX example.com

# Query a specific nameserver
nslookup example.com 8.8.8.8

Flushing your local cache

When you’ve made a DNS change and want to test it immediately:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

# Windows
ipconfig /flushdns

Common issues

Changed DNS but site still shows old content. Check the TTL on the old record. Query a public resolver (dig @1.1.1.1 example.com) to see if the change has reached the wider internet. Your local cache might be stale — flush it.

Domain works in browser but not in code. Check if your code is using a cached DNS result, or if the connection is being refused for a different reason. Also check your /etc/hosts file — it overrides DNS.

Subdomain not resolving. Make sure the record exists on your authoritative nameserver. Use dig +trace sub.example.com to see where the chain breaks. If you’re using a reverse proxy, make sure it’s configured to handle the subdomain.

Key Takeaways

DNS is a distributed caching system, not a single database
Resolution walks: browser cache → OS cache → recursive resolver → root → TLD → authoritative
TTL controls how long records are cached — lower it before making changes
“48-hour propagation” is really just caches expiring at different times
dig +trace is your best friend for debugging DNS issues
DoH encrypts your DNS queries but doesn’t make you anonymous

DNS is one of those things that’s invisible when it works and maddening when it doesn’t. Understanding the resolution chain and caching layers turns “I don’t know why it’s not working” into “I know exactly which cache is stale.”