DNS Propagation Explained - Why Your Site Changes Take Hours

You Changed the Record. Why Is Nothing Happening?

You updated your A record to point to a new server. You triple-checked the value. Your DNS provider confirmed the change is saved. But when you visit your domain, it still loads the old site - and it's been 20 minutes.

You're not doing anything wrong. This is DNS propagation: the time it takes for your DNS change to spread across the global network of DNS resolvers that translate domain names into IP addresses. It's one of the most misunderstood concepts in web infrastructure, and it causes more panic than it should.

Here's what's actually happening, why it takes so long, and what you can do about it.

How DNS Resolution Works (The 30-Second Version)

When someone types yoursite.com into a browser, the request doesn't go directly to your server. It goes through a chain of DNS lookups:

1. Browser cache - Has the browser resolved this domain recently? If yes, use the cached IP.
2. OS cache - Has the operating system resolved it recently? If yes, use that.
3. Recursive resolver - Your ISP or a public resolver (Google's 8.8.8.8, Cloudflare's 1.1.1.1) looks up the domain on your behalf.
4. Root nameserver - The recursive resolver asks a root server: "Who is responsible for .com domains?"
5. TLD nameserver - The .com nameserver responds: "The nameservers for yoursite.com are ns1.your-dns-provider.com"
6. Authoritative nameserver - Your DNS provider's nameserver returns the actual A record: "yoursite.com → 203.0.113.42"
7. Response cached - The recursive resolver caches this answer for the duration of the TTL (Time to Live) and returns it to the browser.

Next time someone resolves yoursite.com, steps 4–6 are skipped - the recursive resolver returns its cached answer. This is the caching layer that causes "propagation delay."

What DNS Propagation Actually Is

DNS propagation isn't a broadcast. Your DNS provider doesn't push your new record to every resolver on the internet. Instead, it works by cache expiration:

1. You update your A record from 203.0.113.42 to 198.51.100.7
2. Your authoritative nameserver immediately serves the new value
3. But every recursive resolver that recently looked up your domain still has the old value cached
4. Those resolvers will continue serving the old value until their cached copy expires (based on TTL)
5. After expiration, the next lookup fetches the new value from your authoritative nameserver

"Propagation" is really "waiting for caches around the world to expire." There's no propagation mechanism - it's just distributed cache invalidation.

Why It Takes So Long

TTL (Time to Live)

Every DNS record has a TTL value, measured in seconds. It tells recursive resolvers how long they're allowed to cache the record before checking for updates.

If your TTL was 86400 (24 hours) when you made the change, some resolvers cached the old value up to 24 hours ago - and they won't check again until those 24 hours expire. This is why DNS changes can take "up to 48 hours" (24-hour TTL + resolvers that ignore TTL).

Resolvers That Ignore TTL

Some ISP resolvers enforce minimum cache times regardless of your TTL setting. If you set a TTL of 300 seconds (5 minutes) but a resolver enforces a minimum of 1 hour, your change won't be visible to users on that ISP for at least an hour.

This isn't common with major public resolvers (Google, Cloudflare, Quad9) but does happen with smaller ISPs and corporate DNS infrastructure.

Multiple Cache Layers

The browser, operating system, and recursive resolver each maintain their own cache. Even after the recursive resolver gets the new value, a user's browser might still show the old site because of its local cache. This is why "it works on my phone but not my laptop" is a common DNS complaint.

Negative Caching

If someone looked up your domain before you created a record (getting an NXDOMAIN or empty response), that "doesn't exist" answer is also cached - typically for 15 minutes to an hour. New records can appear to not exist for some users because of negative caching.

How to Check Propagation Progress

Using Online Propagation Checkers

Tools like whatsmydns.net, dnschecker.org, and dig (command line) query DNS resolvers in different geographic locations and show you what each one returns:

# Check what Google's resolver sees
dig @8.8.8.8 yoursite.com A

# Check what Cloudflare's resolver sees
dig @1.1.1.1 yoursite.com A

# Check the authoritative answer directly (bypasses all caches)
dig @ns1.your-provider.com yoursite.com A

If the authoritative nameserver returns the new value but public resolvers still return the old one, propagation is in progress. If the authoritative nameserver returns the old value, the change hasn't been applied correctly - check your DNS provider's dashboard.

What "Fully Propagated" Means

There's no official moment when propagation is "complete." It's a gradual process where more and more resolvers worldwide get the updated value as their caches expire. In practice, most resolvers will have the new value within:

• 5–15 minutes if your previous TTL was 300 seconds
• 1–4 hours if your previous TTL was 3600 seconds
• 12–48 hours if your previous TTL was 86400 seconds

Note: it's the previous TTL that matters, not the new one you set. The cache expiration is based on the TTL that was served when the record was last cached.

How to Speed Up DNS Propagation

Lower Your TTL Before Making Changes

This is the single most effective strategy. If you know a DNS change is coming (migration, new server, new CDN), lower your TTL 24–48 hours in advance:

1. 48 hours before: Change TTL from 3600 to 300 (5 minutes)
2. Wait 48 hours for the old high-TTL cache entries to expire
3. Make your DNS change - now resolvers will check back in 5 minutes instead of 1 hour
4. After propagation: Raise TTL back to 3600 for better performance

This reduces your propagation window from hours to minutes. It requires planning ahead, but it's the difference between a seamless migration and a 24-hour period of inconsistent behavior.

Flush Your Local Cache

While you can't flush every resolver's cache worldwide, you can flush your own:

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Windows:

ipconfig /flushdns

Chrome browser: Navigate to chrome://net-internals/#dns and click "Clear host cache"

This only fixes it for you - useful for verifying that propagation is complete from your location, but doesn't help your users.

Use a DNS Provider with Fast Propagation

Some DNS providers have faster propagation than others because they use lower default TTLs and have better-connected nameserver networks:

• Cloudflare - Typically propagates globally within 5 minutes for proxied records
• AWS Route 53 - Propagation within minutes due to large nameserver network
• Google Cloud DNS - Fast propagation via Google's global infrastructure

Smaller or older DNS providers with fewer nameserver locations may take longer.

DNS Changes and Monitoring

DNS changes are one of the most common causes of unexpected downtime. A misconfigured A record, a botched migration, or an unexpectedly long propagation window can make your site unreachable for some users while appearing fine for others.

How DNS Issues Affect Your Monitoring

If your monitoring checks from US East but your DNS change hasn't propagated to that resolver yet, your monitoring will show the old server as "up" while users in other regions see errors (or vice versa). This is why multi-region monitoring matters during DNS changes:

• Single-region monitoring might show your site as healthy from its location while it's broken for 30% of your users
• Multi-region monitoring catches propagation inconsistencies immediately - if one probe region resolves to the new IP and another resolves to the old IP (which is now offline), you'll get an alert

Using DNS Monitoring to Catch Problems

Beyond uptime checks, dedicated DNS monitoring tracks your actual record values over time:

• A/AAAA record changes - Get alerted if your domain starts resolving to an unexpected IP
• NS record changes - Detect unauthorized nameserver changes (domain hijacking)
• MX record changes - Catch mail routing issues before email delivery fails
• TXT record changes - SPF, DKIM, DMARC modifications that affect email deliverability

Vantaj monitors DNS records and alerts you when they change - whether you made the change intentionally or not. Combined with domain expiry monitoring and SSL certificate tracking, you get complete visibility into the infrastructure layer that sits between your users and your servers.

Common DNS Propagation Mistakes

Changing DNS and Shutting Down the Old Server Immediately

If your TTL was 3600 (1 hour), some users will still resolve to your old server IP for up to an hour after the change. If you've already shut that server down, those users get connection refused errors.

The fix: Keep the old server running for at least 2x your previous TTL after making the DNS change. Only decommission it after propagation is complete.

Testing Only from Your Own Machine

"It works for me" doesn't mean it works for your users. Your local DNS cache might have the new value while ISP resolvers in other countries still serve the old one. Use propagation checkers or multi-region monitoring to verify globally.

Setting TTL to 0

A TTL of 0 means "don't cache this at all." In theory, every lookup should hit your authoritative nameserver. In practice, many resolvers enforce a minimum TTL of 30–300 seconds regardless of what you set. A TTL of 0 also dramatically increases load on your nameservers and can cause resolution delays.

Forgetting About Email

When migrating a domain, teams often focus on web traffic (A records) and forget about email (MX records). If your MX records point to an old mail server that's been decommissioned, incoming email silently bounces. Monitor your MX records alongside your A records during any migration.

The Bottom Line

DNS propagation isn't instant because the internet is a distributed caching system. Every resolver caches your records independently, and they all expire on their own schedule. You can't push changes - you can only wait for caches to expire.

The best strategy: plan ahead. Lower your TTL before making changes, keep old infrastructure running during propagation, monitor from multiple regions, and use DNS record monitoring to verify that changes are applied correctly and consistently worldwide.