DNS & Domain Management

How DNS Propagation Works (And Why It Takes Up to 48 Hours)

Why do DNS changes take hours to go live? Learn how TTL caching works across global ISP resolvers, how to avoid caching traps, and how to verify propagation.

By AuditYourWeb7 min read
Diagram illustrating DNS propagation across global recursive resolvers

What is DNS propagation and why does it take time?

When you migrate your website to a new web host, update an A record, or configure a new email provider, you expect the changes to go live instantly. However, visitors in different cities or on different cellular networks often continue seeing the old server for hours—or even days.

This transition period is known as DNS propagation:

Authoritative Nameserver Update → TTL Expiration Countdown → Recursive ISP Caches Purged → End Users Receive New IP

DNS propagation is not a single synchronized global event. Rather, it is the gradual, decentralized expiration of cached DNS records across millions of independent recursive resolvers operated by internet service providers (ISPs like Comcast, AT&T, Vodafone), public DNS providers (Cloudflare 1.1.1.1, Google 8.8.8.8), and corporate networks worldwide.


The DNS caching hierarchy explained

To understand propagation delays, consider what happens when a browser queries your domain:

[Browser / Device]
       │
       ▼
[ISP Recursive Resolver] (Caches response for TTL duration)
       │ (Cache Miss)
       ▼
[Root DNS Server (.)] ──► [TLD Nameserver (.com)] ──► [Authoritative DNS (Cloudflare/Route 53)]
                                                              │ (Returns New IP + TTL)
                                                              ▼
                                                   [ISP Resolver Caches Answer & Responds]
  1. Your Authoritative Nameserver (Instant): When you save a new IP in Cloudflare, AWS Route 53, or Namecheap, your authoritative nameservers update within seconds.
  2. Recursive Resolvers (Cached): Millions of ISP resolvers worldwide do not query your authoritative nameserver on every single website visit. Instead, they store the previous answer in their local cache for the duration of your TTL (Time to Live).
  3. The TTL Clock: As long as that TTL countdown has not reached zero on a specific ISP's resolver, that resolver continues returning the old IP address to its local subscribers.

The role of TTL (Time to Live)

TTL (Time to Live) is a setting measured in seconds attached to every DNS record. It dictates exactly how long resolvers are permitted to cache the answer before asking your nameservers for fresh data:

  • 300 seconds (5 minutes) → Fast propagation. Ideal for active migrations and cutovers.
  • 3600 seconds (1 hour) → Standard balance between speed and server query load.
  • 86400 seconds (24 hours) → Static records that rarely change (like apex nameservers).

The Pre-Migration Pro Tip:

If you plan to switch hosting servers next Tuesday:

  1. Lower your TTL to 300 seconds (5 minutes) at least 48 hours before your migration.
  2. Perform your server migration and update the A record.
  3. Your update will propagate worldwide in just 5 minutes rather than 24 hours.
  4. Once stable, raise the TTL back to 3600 or 86400 to reduce DNS query load.

Why some users still see the old site (ISP caching traps)

Even when your TTL is set to 300 seconds, certain factors can prolong propagation:

1. ISP Resolver Overrides (Ignoring TTL)

Some budget or regional mobile network ISPs deliberately ignore low TTLs to save bandwidth and reduce upstream DNS traffic. They hard-code a minimum cache time of 12 to 24 hours regardless of what your DNS record specifies.

2. Local Operating System & Browser DNS Caches

Client operating systems (Windows, macOS) and web browsers (Google Chrome) maintain their own internal DNS caches:

  • Flush Windows DNS: ipconfig /flushdns
  • Flush macOS DNS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  • Flush Chrome DNS: Navigate to chrome://net-internals/#dns and click "Clear host cache".

3. Stale Negative Caching (SOA Minimum TTL)

If a user attempted to visit a subdomain before you created the DNS record, recursive resolvers cache that "NXDOMAIN (Non-Existent Domain)" error for the duration specified in your SOA (Start of Authority) record's minimum TTL field.


How to test global propagation in real time

Never ask your coworkers or friends if they can see the site yet—their local ISPs provide an unreliable sample.

Use our free DNS Lookup & Propagation Checker to query authoritative records across all essential record types:

  • A & AAAA (IPv4 and IPv6 web server routing)
  • CNAME (Aliases and CDN routing)
  • MX (Mail exchangers for email delivery)
  • TXT (SPF, DMARC, and site verification tokens)
  • CAA (Certificate Authority Authorization)

You can also test propagation directly from your terminal using dig against specific global resolvers:

# Query Google Public DNS (8.8.8.8)
dig @8.8.8.8 yourdomain.com +short

# Query Cloudflare DNS (1.1.1.1)
dig @1.1.1.1 yourdomain.com +short

# Query Quad9 (9.9.9.9)
dig @9.9.9.9 yourdomain.com +short

If all three global resolvers return your new IP, your DNS has propagated across major international internet backbones.

Got questions?

Frequently Asked Questions

Quick answers to common questions about how dns propagation works (and why it takes up to 48 hours).

You cannot force third-party ISP resolvers to purge their caches once they have cached your old record with a high TTL. You must wait for their TTL countdown to expire. However, you can flush your local computer's cache (`ipconfig /flushdns`) and test via Google/Cloudflare public DNS.

Continue reading

How to Decode and Inspect SSL Certificates & CSRs (X.509 Guide)

Don't deploy unverified certificates into production. Learn how to decode X.509 certificates and CSRs to inspect SANs, key sizes, and validity dates.

Read the guide
Back to all guides
Зow DNS Propagation Works: The Complete Guide for Webmasters