How DNS Propagation Works: TTL, Resolvers & the Global Timeline

What DNS Propagation Actually Means

DNS propagation is the process by which a change made to a DNS record becomes visible to resolvers and end users across the internet. It is not a broadcast — there is no central DNS server that pushes updates to the world. Instead, propagation is a gradual expiry and refresh cycle: resolver caches around the globe hold your old record until the Time to Live (TTL) expires, at which point they fetch the updated value from your authoritative nameserver.

The term "propagation" is slightly misleading because it implies your new record travels outward. In practice, your authoritative nameserver holds the new record immediately after you save it — the propagation delay exists entirely on the caching side. Every resolver that has cached your old record will continue serving it until the TTL counts down to zero.

Think of it like a newspaper. When the new edition is printed (your authoritative nameserver is updated), every reader who already has yesterday's paper (cached record) continues reading from it until they go to the newsstand and pick up today's edition (TTL expires and resolver re-fetches). You can't recall yesterday's paper from everyone's hands — you can only wait for them to come back for the new one.

💡 Tip: Your authoritative nameserver serves the new record the instant you save it. Every minute of propagation delay is caused entirely by resolver caches holding the old TTL — not by any travel time for your change.

The DNS Hierarchy: Root, TLD, and Authoritative Nameservers

Before understanding propagation, you need to understand the structure DNS operates within. The system is hierarchical, and changes at different levels have very different propagation characteristics. The systems are designed to ensure that data is routed efficiently across the globe.

Root nameservers sit at the top. There are 13 root server clusters, operated by international organisations including Verisign, RIPE NCC, Cogent, and others — the full list is maintained by IANA's Root Servers. They don't store records for individual domains — they store pointers to the nameservers responsible for each TLD.

TLD nameservers hold the NS (delegation) records that point to your authoritative nameservers. These records typically carry a TTL of 172,800 seconds (48 hours) — critical when you're changing nameservers, since that window applies at the TLD level regardless of what you set in your own zone.

Authoritative nameservers are where your zone lives. These are the nameservers you configure with your domain registrar. Your DNS change takes effect here instantly — but the rest of the internet doesn't know until their cached copies of the old record expire.

Resolver cold-start lookup path:

  Root (.) nameservers          ← "Who handles .com?"
       ↓
  .com TLD nameservers          ← "Who handles example.com?"
       ↓
  example.com authoritative NS  ← "What is the A record for example.com?"
       ↓
  Returns: 203.0.113.10 TTL 300

The delegation path (root → TLD → your NS) is cached separately from your zone records, each with its own TTL. When you change only an A record, the delegation path stays cached and only the A record TTL matters. When you change nameservers, the parent TLD zone must also update, governed by the TLD's NS TTL — and that's where the 48-hour worst-case comes from.

How TTL Controls Propagation Speed

TTL is a value set on each DNS record — measured in seconds — that tells resolvers how long to cache that record before checking again. When a resolver fetches your A record and sees TTL 3600, it stores the answer and won't query your authoritative nameserver again for one hour, regardless of what you change in the interim.

This single value is the most important factor in your DNS propagation time.

The propagation window starts from when each resolver last cached your record — not from when you made the change. A resolver that cached your record 55 minutes into a 3600-second TTL cycle will serve the old value for only 5 more minutes. Another that cached it 2 minutes ago will serve the old value for nearly an hour.

⚠️ Warning: The maximum propagation window equals the TTL that was set on the record at the time that resolver last cached it — not the TTL you set now. If a resolver cached your record at TTL 86400 one hour ago, it will serve the old record for another 23 hours.

Propagation by Record Type: A, MX, CNAME, NS, and More

Not all DNS records behave the same way during propagation. Different record types carry different typical TTLs, different caching implications, and different downstream consequences when they change.

CNAME Chain Propagation

When you use a CNAME chain (e.g., www.example.com → myapp.provider.com → 203.0.113.10), each record in the chain has its own independent TTL. A resolver follows the entire chain on first resolution and caches each hop separately. If you change the final A record at the end of the chain, only the TTL of that A record governs how quickly resolvers pick up the change — but only after their cached copy of that specific CNAME target has expired.

NS Record Propagation (Nameserver Changes)

Changing nameservers is fundamentally different from changing zone records because the update must propagate through two layers. First, your registrar updates the glue records in the parent TLD zone — this can take anywhere from minutes to several hours depending on the registrar. Second, the TLD's updated NS records propagate to resolvers worldwide, which are governed by a TTL set by the TLD operator.

MX Record Propagation

MX records control where email for your domain is delivered. When MX records change, sending mail servers globally continue attempting delivery to your old mail server until the old MX TTL expires in their resolver's cache. Retrying logic typically waits for a resolution change to happen naturally across the network.

The DNS Resolution Chain Step-by-Step

Every DNS query — whether from a browser, an email server, or a monitoring tool — follows the same resolution chain. Understanding each step explains why propagation isn't instantaneous even for records with low TTL.

• Local OS cache check. Your operating system maintains its own DNS cache. If the record was recently resolved on the same machine, the OS serves the cached answer directly without any network call.
• Recursive resolver query. If the OS cache misses, the query goes to the recursive resolver configured on the machine — typically your ISP's resolver or a public resolver like 8.8.8.8 or 1.1.1.1.
• Iterative resolution on cache miss. If the recursive resolver's cache is cold or expired, it performs iterative resolution: it queries root nameservers for the TLD, then the TLD, then your authoritative nameserver directly.
• Authoritative nameserver response. Your authoritative nameserver returns the current record and its TTL. This is the ground truth — your change is live here the instant you save it.
• Answer returned and cached. The recursive resolver caches the response for the TTL duration and forwards the answer to the client. Every subsequent query from any user on that resolver gets the cached answer.

💡 Tip: Propagation delay exists only in local and resolver-level caching. If the authoritative nameserver is already serving the new value, the wait is entirely for stale resolver caches to expire.

Why Different Regions See Different Results

The internet has tens of thousands of independent recursive resolvers operated by ISPs, cloud providers, and organisations worldwide. Each maintains its own cache with its own TTL countdown, initialised at whatever point that resolver last queried your authoritative nameserver.

• Cache initialisation timing. Resolvers are independent. There is no synchronised expiry event. A resolver that cached your record 5 minutes ago has nearly its full TTL remaining; one that cached it yesterday may already be at expiry.
• Query volume in that region. High-traffic regions query your record frequently, so caches are refreshed more recently. A less-popular domain in a low-volume region may have a resolver cache that's older.
• Anycast architecture. Public resolvers like 8.8.8.8 and 1.1.1.1 operate hundreds of points of presence globally. Two users both using 8.8.8.8 may route to different PoPs with different cache states.
• ISP TTL compliance. Some ISPs ignore your declared TTL entirely, caching records for a fixed internal duration of 12–48 hours regardless of what you set.

You can run a propagation check across 100+ global resolvers to see exactly which regions are still serving old values and which have already updated.

How Major Public Resolvers Handle Propagation

Different public resolvers have different caching behaviours and update frequencies. Understanding how they handle your records is essential for verifying global propagation status.

Google Public DNS (8.8.8.8, 8.8.4.4)

Google's resolver network is one of the largest in the world. It is generally TTL-compliant and known for relatively fast propagation. The TTL returned by Google DNS is the remaining cache time, not the original TTL — if you see TTL 847 when the record TTL is 3600, Google cached that record 2,753 seconds ago. For urgent changes, Google provides a public DNS cache flush tool that lets you request early cache invalidation for specific records.

Cloudflare (1.1.1.1, 1.0.0.1)

Cloudflare is typically the fastest public resolver for picking up changes. It uses aggressive cache prefetching — refreshing popular records before their TTL expires — which means your new record may appear on 1.1.1.1 slightly before the full TTL window has elapsed. Cloudflare also offers a 1.1.1.1 cache purge tool where you can manually request cache invalidation for a specific hostname.

ISP Resolvers

This is where the most variation exists. ISP resolver behaviour across different carriers and regions ranges from perfectly compliant to completely ignoring your TTL, with some enforcing minimum cache durations of up to 48 hours in extreme cases.

How to Check DNS Propagation Status Right Now

When you need to verify whether your change has propagated to a specific resolver, use dig with the @ flag to target a nameserver directly and bypass your local cache.

# Query Google's public resolver
dig example.com A @8.8.8.8

# Query your authoritative nameserver directly (bypasses all resolver caches)
dig example.com A @ns1.yourprovider.com

# Check remaining cache time on a resolver
dig example.com A @8.8.8.8 +ttl

The TTL in the answer section against a recursive resolver shows the remaining cache time — not the original TTL. If you see TTL 847 when querying 8.8.8.8 and the record TTL is 3600, that resolver cached the record 2,753 seconds ago.

Always rule out local caching first. You can discover which authoritative nameservers your domain uses and query them directly to ensure your host has updated the records correctly on their end:

# Find your authoritative nameservers
dig example.com NS +short

# Then query one of them directly for the live record
dig example.com A @ns1.yourprovider.com +short

If the authoritative nameserver is already serving the new value, Use NS Lookup to confirm your authoritative nameservers are correct, and SOA Lookup to inspect your zone's TTL settings.

Impact on Email, SSL, and CDN During a DNS Change

DNS propagation doesn't just affect website reachability. Depending on which record type you're changing, the downstream effects extend to email delivery, certificate issuance, and CDN routing.

1. Email Delivery During MX Changes. Sending mail servers globally continue attempting delivery to your old mail server until the old MX TTL expires. drain the old server's queue and keep it running during the transition.
2. SSL Certificate Issuance. Certificate Authorities validate domain control at the time of issuance. Changing hosting and requesting a new SSL certificate simultaneously can lead to issuance failures if records aren't propagated.
3. CDN Behaviour. CDNs that use anycast maintain their own edge caches. When you point your domain at a CDN, DNS propagation must complete before the CDN edge can take over traffic.

Common Reasons Propagation Takes Longer Than Expected

High TTL Set Before the Change

If your records had a TTL of 86400 (24 hours) before you made the change, and a resolver cached your record at hour 1 of the cycle, that resolver won't pick up your change for another 23 hours — regardless of what you've changed the TTL to now.

💡 Tip: The time to fix a high TTL is 48–72 hours before you make the change, not after. Lower it in advance, wait a full TTL cycle, then make the change.

Negative Caching of NXDOMAIN Responses

If your domain didn't exist previously and resolvers received an NXDOMAIN response, those resolvers cached that negative result. The negative cache TTL is controlled by the minimum TTL field in the zone's SOA record. This behaviour is standardised in RFC 2308, which defines how resolvers must handle and cache negative DNS responses. Even after you create the record, resolvers holding a cached NXDOMAIN won't check again until that negative TTL expires.

Local OS or Application-Level Caching

Even if global resolvers have picked up your change, your local machine may still serve the old answer from its own cache. Flush your OS DNS cache before concluding that propagation is slow:

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

# Windows
ipconfig /flushdns

Frequently Asked Questions

Q: How long does DNS propagation take? A: It depends entirely on the TTL set on your records before the change. With a TTL of 300 already in place, most resolvers pick it up within 10–30 minutes. With a TTL of 86400, it can take 24–48 hours or longer.

Q: Why does my site load on my phone but not my laptop? A: Your phone and laptop use different DNS resolvers (mobile data vs Wi-Fi). Each has its own cache with its own TTL countdown, so they reach the refresh point at different times.

Q: Can I force DNS propagation to happen faster? A: You cannot force external resolvers to expire early. You can only flush your local cache and switch to a public resolver. Lower your TTL 48–72 hours before a planned change.

Q: My authoritative nameserver shows the new record — why aren't resolvers picking it up? A: Recursive resolvers cached the old record and won't check the authoritative source again until the TTL expires. Propagation is a waiting game from this point.

Q: What is the difference between DNS propagation and DNS replication? A: Replication is the sync between your own primary and secondary nameservers (fast). Propagation is the process of global recursive resolvers refreshing their caches (slow).

Q: Can I use CNAME flattening at the zone apex to avoid propagation issues? A: Flattening lets you point the root domain to a CNAME target, but the resulting A record still carries a TTL that resolvers will cache, meaning propagation dynamics remain the same.

Next Steps

If your DNS change isn't propagating as expected, read our DNS Propagation Troubleshooting guide, which covers every common cause — from high TTL to incorrect registrar delegation.

To understand TTL settings in depth and know exactly what to set for each record type, see our DNS TTL Explained guide.

Browse all DNS guides on DNSnexus for related topics.

Related Guides

• DNS Propagation Still Pending After 24 Hours? Here's Why and How to Fix It
• DNS TTL Explained: What It Is, How to Set It, and When to Lower It
• How to Migrate DNS to a New Host Without Downtime