DNS Explained Properly — Recursive Resolvers, TTL, and Why Propagation Isn't Real

Moved a website to a new server two years ago. Changed the DNS record. Client called an hour later: "The site is still showing the old version." I told them to "wait for DNS propagation," which is the IT equivalent of telling someone to turn it off and turn it back on again — technically useful advice that masks the fact that you don't fully understand what's happening.

I didn't fully understand what was happening. DNS propagation, as most people use the term, isn't a real thing. There's no wave of updates spreading across the internet. What's actually happening is different, more predictable, and once you understand it, you stop telling clients to "just wait" and start being able to tell them exactly how long to wait and why, probably.

DNS is one of those technologies that's been working since 1983 and most developers, I think, never learn how it actually works. They know it "translates domain names to IP addresses" and that's it. The mechanics of how that translation happens explain a lot of behaviors that seem random or unpredictable when you don't know the system.

What Actually Happens When You Type a URL

You type example.com in your browser. The browser needs an IP address. Here's the chain of events, in order:

Step 1: Browser cache. The browser checks if it already has a cached DNS result for example.com. If you visited the site recently, the answer might already be stored locally. Chrome, Firefox, and Safari all maintain their own DNS caches separate from the operating system.

Step 2: OS cache. If the browser doesn't have it, it asks the operating system. The OS maintains its own DNS cache. On Linux, this might be systemd-resolved. On macOS, it's the DNS resolver daemon. On Windows, the DNS Client service.

Step 3: Recursive resolver. If the OS doesn't have it cached, it sends a query to a recursive resolver. This is usually operated by your ISP, or by a public DNS service like Cloudflare (1.1.1.1), Google (8.8.8.8), or Quad9 (9.9.9.9). Your computer sends one question — "What's the IP for example.com?" — to this server, and this server does all the work to find the answer.

The recursive resolver is the key player. If it has a cached answer, it returns it immediately. If not, it starts a chain of queries:

Step 4: Root nameservers. The resolver asks a root nameserver: "Where do I find information about .com domains?" There are 13 root server addresses (actually hundreds of physical servers using anycast routing, but 13 logical addresses). The root server doesn't know the IP of example.com. It knows which servers handle the .com zone and points the resolver there.

Step 5: TLD nameservers. The resolver asks the .com TLD server: "Where do I find information about example.com?" The TLD server doesn't know the IP either. It knows which nameservers are authoritative for example.com and points the resolver there. These authoritative nameservers are what you configure at your domain registrar — they're usually something like ns1.cloudflare.com or ns1.digitalocean.com.

Step 6: Authoritative nameserver. The resolver asks the authoritative nameserver: "What's the A record for example.com?" This server has the actual answer. It responds with the IP address.

The resolver caches this answer and sends it back to your OS, which caches it and sends it to the browser, which caches it and makes the HTTP connection.

All of this happens in milliseconds. A full resolution with no caching takes maybe 50-200ms, roughly. With caching at any level, it's near-instant.

DNS Record Types That Actually Matter

There are dozens of DNS record types. In practice, you'll use about six:

A record — Maps a domain to an IPv4 address.

example.com.    A    93.184.216.34

AAAA record — Maps a domain to an IPv6 address.

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

CNAME record — Aliases one domain to another. Instead of pointing to an IP, it points to another domain name that has its own A record.

www.example.com.    CNAME    example.com.
blog.example.com.   CNAME    my-blog.netlify.app.

CNAME records cannot coexist with other records at the same name. You can't have a CNAME and an A record for the exact same subdomain. This restriction seems to catch people when they try to set up a CNAME at the zone apex (the bare domain without "www"). Most DNS providers work around this with ALIAS or ANAME records, which act like CNAMEs but resolve at the DNS level rather than the client level.

MX record — Specifies which mail servers handle email for the domain.

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

The number is priority — lower is preferred. If mail1 is down, delivery falls back to mail2. Setting up email? MX records are mandatory.

TXT record — Stores arbitrary text. Used for domain verification (Google Search Console, SSL certificate issuance), email authentication (SPF, DKIM, DMARC), and whatever else people need to associate text data with a domain.

example.com.    TXT    "v=spf1 include:_spf.google.com ~all"

NS record — Specifies which nameservers are authoritative for the domain.

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

These are what you set at your registrar to delegate control of your domain's DNS to a specific provider.

TTL — The Thing That Explains "Propagation"

Every DNS record has a TTL — Time To Live. It's a number in seconds that tells caching resolvers how long to keep the record before asking again.

example.com.    300    A    93.184.216.34

That 300 means: cache this answer for 300 seconds (5 minutes). After 5 minutes, the resolver should query the authoritative nameserver again for a fresh answer.

Here's what "DNS propagation" actually is: different resolvers cached your old record at different times, so they expire at different times. There's no propagation. There's no update wave. Your ISP's resolver cached the record 4 minutes ago and will hold it for 1 more minute. Google's resolver cached it 2 minutes ago and will hold it for 3 more minutes. Your friend's ISP cached it 10 seconds ago and will hold it for 4 minutes and 50 seconds.

The maximum wait time for a DNS change to take effect is the TTL of the old record. If your old record had a TTL of 3600 (1 hour), then within one hour, every resolver that cached the old record will expire it and fetch the new one on the next query. No magic. No unpredictability. Just cache expiration.

This is why experienced operations people lower the TTL before making DNS changes:

# Step 1: Two days before the migration, lower TTL to 60 seconds
example.com.    60    A    93.184.216.34

# Step 2: Wait for the old TTL to expire (if it was 3600, wait an hour)

# Step 3: Change the record
example.com.    60    A    198.51.100.42

# Step 4: Within 60 seconds, everyone sees the new IP

# Step 5: After confirming everything works, raise TTL back up
example.com.    3600    A    198.51.100.42

If you skip the TTL lowering and change a record that had a 24-hour TTL, some resolvers will serve the old address for up to 24 hours. That's not "slow propagation." That's caches doing exactly what they were told to do.

Why Some Changes Take Longer Than Expected

Some resolvers don't respect TTL perfectly. A few ISP resolvers are known to set minimum cache times regardless of what the record says. If you set a TTL of 60 seconds, some resolvers might cache it for 5 minutes anyway because they want to reduce query volume.

Also, NS record changes — changing which nameservers are authoritative for your domain — involve the parent zone (the TLD servers for .com, .io, etc.) and those updates go through the registrar. This can take minutes to hours, regardless of TTL, because the registrar has to process the change and push it to the TLD zone files.

Debugging DNS Issues

When something isn't resolving correctly, these tools tell you exactly what's happening.

dig — The Essential Tool

dig example.com

; <<>> DiG 9.18.18 <<>> example.com
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)

The answer section shows the record, its TTL (3600 seconds remaining), and the IP. The bottom shows which resolver answered and how long the query took.

Query a specific resolver to see what different DNS providers return:

# Ask Google's resolver
dig @8.8.8.8 example.com

# Ask Cloudflare's resolver
dig @1.1.1.1 example.com

# Ask the authoritative nameserver directly (bypasses all caching)
dig @ns1.cloudflare.com example.com

Querying the authoritative nameserver directly tells you the "ground truth" — what the actual record says, regardless of any resolver's cache. If the authoritative answer is correct but a specific resolver shows the old record, you probably know that resolver still has a cached copy.

Trace the full resolution path:

dig +trace example.com

This shows every step: root server, TLD server, authoritative server. If resolution is failing, the trace should show exactly where it breaks. Root server doesn't know the TLD? TLD server doesn't have NS records for your domain? Authoritative server isn't responding? The trace makes it visible.

nslookup — The Quick Check

nslookup example.com
nslookup example.com 8.8.8.8

Less detailed than dig, but available on every operating system including Windows. Good for a quick "does this domain resolve?" check.

Checking from Multiple Locations

Your resolver might have the correct answer cached while resolvers in other countries still have the old one. Online tools like dnschecker.org query resolvers around the world and show results from each. When you've made a DNS change and want to know who's seeing the new record and who isn't, this shows you the global state.

Common DNS Mistakes I've Made (and Fixed)

Forgetting the trailing dot. In DNS zone files, domain names should end with a dot: example.com. The dot means "this is a fully qualified domain name." Without it, some DNS providers append the zone name, turning example.com into example.com.example.com. Most modern DNS management UIs handle this for you, but if you're editing zone files directly, watch for it.

CNAME at the zone apex. You can't put a CNAME record on the bare domain example.com (only on subdomains like www.example.com). This is an RFC restriction that exists because CNAME records conflict with other record types, and the zone apex needs NS and SOA records. Cloud providers work around this with proprietary record types (Cloudflare's "flattened CNAME," Route 53's "ALIAS record"), but it's a gotcha when setting up hosting that gives you a CNAME target instead of an IP address.

Not setting up email authentication records. SPF, DKIM, and DMARC are TXT records that tell receiving mail servers "these are the servers authorized to send email from my domain." Without them, email from your domain is more likely to land in spam folders, and anyone can spoof your domain in phishing emails. These are DNS records, not email server settings. Configure them at your DNS provider.

# SPF: who can send email for this domain
example.com.    TXT    "v=spf1 include:_spf.google.com ~all"

# DMARC: what to do with emails that fail SPF/DKIM
_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Ignoring IPv6. If you have an AAAA record and your server doesn't actually accept IPv6 traffic, users on IPv6-preferred networks will try the IPv6 address first, fail, and then fall back to IPv4. That fallback adds seconds of latency. Either set up IPv6 properly or don't publish AAAA records.

DNS Security — DNSSEC and DoH

Standard DNS is unencrypted. Queries travel in plaintext. Anyone between you and the resolver — your ISP, a coffee shop's router, a state-level actor — can see every domain you look up. They can also modify responses, redirecting you to a different IP address (DNS hijacking).

DNS over HTTPS (DoH) encrypts DNS queries inside HTTPS. Your ISP can see that you're sending encrypted traffic to 1.1.1.1 or 8.8.8.8, but they can't see which domains you're looking up. Most modern browsers support DoH natively. Firefox enables it by default in some regions.

DNSSEC is a separate protection: it adds cryptographic signatures to DNS records so the resolver can verify the response came from the authoritative server and wasn't tampered with in transit. It doesn't encrypt queries — it authenticates responses. DNSSEC and DoH solve different problems and complement each other.

Setting up DNSSEC for your domain is usually a checkbox in your DNS provider's dashboard plus a DS record at the registrar. Not all providers support it. When they do, it's worth enabling.

Local DNS Override — /etc/hosts

Before any DNS query leaves your machine, the OS checks /etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts (Windows):

# /etc/hosts
127.0.0.1    localhost
192.168.1.50  myapp.local
93.184.216.34 example.com

Entries here override DNS completely. If you add 93.184.216.34 example.com, your machine will use that IP for example.com regardless of what DNS says. This is useful for testing a new server before changing DNS — add the new IP to your hosts file, verify the site works, then change the real DNS record with confidence.

Also useful for blocking domains. Point unwanted hostnames to 0.0.0.0 and they'll fail to connect:

0.0.0.0    ads.example.com
0.0.0.0    tracking.example.com

This is essentially what Pi-hole does, but at scale with a list of tens of thousands of ad and tracking domains.

Internal DNS and Split Horizon

Worth mentioning because it comes up in any company with internal services. Split-horizon DNS (also called split-brain DNS) means the same domain name resolves to different IP addresses depending on where you're querying from. Inside the corporate network, api.company.com resolves to the internal IP 10.0.1.50. Outside the network, it resolves to the public IP 203.0.113.25.

This is configured by running different DNS servers for internal and external zones, or by using DNS views on the same server. Most cloud providers support this natively — AWS Route 53 has private hosted zones, Cloudflare has split-horizon through their Zero Trust product.

The debugging confusion this causes is real. "The API works from my laptop but not from the CI server." Because your laptop is on the VPN and gets the internal IP, while the CI server is outside and gets the public IP, which might not have the same services running. dig from both locations reveals the difference immediately.

DNS as Infrastructure — Why It's Worth Understanding

Most developers interact with DNS only when setting up a new domain or migrating a server. Learn it once, and those interactions stop being stressful guesswork.

When a client says "my site isn't loading," the first thing I check is DNS. dig takes two seconds and tells me immediately whether the domain resolves to the right IP, whether the TTL is what I expect, and whether the authoritative nameserver has the correct record. Nine times out of ten, the answer is obvious within a minute.

When someone says "DNS propagation is taking forever," I can check the old TTL, calculate when the caches will expire, and give an exact timeframe instead of a shrug. Or I can query the authoritative server directly and confirm the change is live, then explain that their local resolver is still caching the old record and will update within X minutes.

DNS is invisible infrastructure. It works so reliably that we forget it's there. But when it breaks — or when we need to change it — understanding the mechanics turns a stressful, unpredictable process into a straightforward one with predictable timelines and clear debugging steps.

---

Keep Reading

• HTTP/3 and QUIC — Why HTTP/2 Wasn't the Final Answer — DNS resolves the address, but the protocol that carries your data has changed dramatically too.
• SSH Tunneling — The Networking Swiss Army Knife Nobody Taught Me — Another piece of invisible networking infrastructure that every developer should understand.

---

Further Resources

• Cloudflare Learning Center: What is DNS? — Clear, visual explanations of DNS resolution, record types, and common DNS security concepts.
• RFC 1035 — Domain Names: Implementation and Specification — The foundational specification that defines the DNS protocol, message format, and resolution process.
• DNS Checker — A free tool for checking DNS propagation across global resolvers, useful for verifying record changes in real time.