DNS Propagation Taking Too Long? What to Check First

You changed a DNS record. It's been 12 hours, or 24 hours, or even longer, and some locations are still resolving the old record. Meanwhile you've been told "DNS propagation takes 24–48 hours" so many times you're not sure if something is wrong or if you just have to wait.

In practice, most DNS changes propagate to major public resolvers within 30 minutes when TTLs are configured correctly. If you're waiting days, something specific is causing the delay. Here's what to check.

How DNS Propagation Actually Works

When you change a DNS record, you're updating it at your authoritative nameserver (the DNS server that holds the source of truth for your domain). Your change is immediate there.

Everyone else — ISPs, public resolvers, corporate DNS servers — has a cached copy of the old answer. They'll continue returning the old answer until their cache expires. The cache duration is set by the TTL (time to live) on the record.

So "propagation time" is really: how long until everyone's cached copy expires. It's not a broadcast — it's a waiting game where caches expire at different times.

The practical implication: most of the internet updates within an hour, but any resolver that looked up your domain shortly before you made the change will hold the old answer for up to one full TTL period.

Check 1: What Is Your TTL Set To?

This is almost always the cause of slow propagation.

# Check the TTL on your A record
dig yourdomain.com A +ttl

# Example output:
# yourdomain.com.  86400  IN  A  203.0.113.42
#                  ^^^^^
#                  This is the TTL in seconds (86400 = 24 hours)

If your TTL was 86400 (24 hours) at the time of the change, resolvers that looked up your domain just before the change will serve the old answer for up to 24 hours. This is expected behaviour — it's not a bug.

What you should do before DNS changes:

Lower the TTL on your record 24–48 hours before making the change:

• Change TTL from 86400 to 300 (5 minutes)
• Wait 24–48 hours (so existing caches with the old TTL expire)
• Make your DNS change
• Changes will now propagate within ~5 minutes

After migration is stable, raise the TTL back to a higher value.

Check 2: Is the Change Actually Saved?

Query the authoritative nameserver directly — this bypasses all caching and shows you what's actually stored:

# Find your authoritative nameservers
dig yourdomain.com NS +short
# Returns something like:
# ns1.yourprovider.com.
# ns2.yourprovider.com.

# Query the authoritative nameserver directly
dig yourdomain.com A @ns1.yourprovider.com +short

If the authoritative nameserver returns the old IP, your change was never saved. Log into your DNS provider and re-apply it.

Check 3: Are Public Resolvers Seeing It?

If the authoritative nameserver has the correct record, check whether public resolvers have caught up:

# Google's resolver
dig yourdomain.com A @8.8.8.8 +short

# Cloudflare's resolver
dig yourdomain.com A @1.1.1.1 +short

# OpenDNS
dig yourdomain.com A @208.67.222.222 +short

If public resolvers are still returning the old IP, check the TTL:

# Check what TTL public resolvers have left before they refresh
dig yourdomain.com A @8.8.8.8

# The TTL in the answer section decrements — if it shows 82000, you have ~22 hours left

The TTL shown in a resolver's response is the remaining time on their cached answer, not the original TTL. If it shows 0 or close to it, the resolver should refresh soon.

Check 4: Is Your ISP/Corporate DNS Involved?

Some corporate networks and ISPs run their own DNS resolvers that may have longer cache times or don't respect TTLs correctly. This is rare but can cause extended delays for specific networks.

Test from outside your network:

# Use a different DNS server temporarily to test
# Add to /etc/resolv.conf (Linux) or network settings (macOS/Windows):
# nameserver 8.8.8.8

# Or use dig to force a specific resolver:
dig yourdomain.com A @8.8.8.8 +short

If you get the new IP from 8.8.8.8 but not from your normal network, your ISP or corporate resolver is the issue. This resolves on its own; you can't force it to flush.

Check 5: Negative Cache (NXDOMAIN)

If you created a new record for a subdomain (like api.yourdomain.com) that previously didn't exist, DNS resolvers may have cached a negative response — a record that the domain doesn't exist (NXDOMAIN).

NXDOMAIN responses are also cached, typically for the period defined in the SOA record's minimum TTL field.

# Check your SOA record's negative cache TTL
dig yourdomain.com SOA +short
# Output: ns1.yourprovider.com. admin.yourprovider.com. 2026031501 3600 900 604800 300
#                                                                                     ^^^
#                                           This last number is the negative cache TTL (300 = 5 minutes)

If the negative TTL is high (some providers set it to 3600 or more), NXDOMAIN caches will persist for that long.

Check 6: Cloudflare Proxy Interference

If your domain uses Cloudflare with the proxy enabled (orange cloud), Cloudflare's edge network serves requests — not your origin server. Changing your origin server's IP requires updating the DNS record in Cloudflare, but traffic still routes through Cloudflare's network.

# Check if Cloudflare is proxying your domain
curl -I https://yourdomain.com | grep -i "cf-ray\|server: cloudflare"

If Cloudflare is in the path, make sure you've updated both:

1. The A record in Cloudflare's DNS panel (pointing to your new origin IP)
2. Checked whether you need to purge Cloudflare's cache

Changes to Cloudflare's DNS records (when proxied) take effect almost immediately — you shouldn't see multi-hour delays here.

How to Track Global Propagation

Check from multiple global perspectives simultaneously:

# Using DNS lookup tools online — search for "DNS propagation checker"
# Or test multiple resolvers manually:

for resolver in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
    echo -n "$resolver: "
    dig yourdomain.com A @$resolver +short
done

When most resolvers return the new IP and some stragglers return the old one, propagation is in progress and will complete as those caches expire.

The Honest Answer on Timing

Under normal conditions, with a low TTL (300–3600 seconds):

• Authoritative update: instant
• Major public resolvers (Google, Cloudflare): 1–10 minutes
• Most of the internet: 30–60 minutes
• Stragglers with long TTL caches: up to the original TTL value

If you're seeing propagation delays beyond the TTL value, one of the issues above (change not saved, ISP resolver not refreshing, Cloudflare caching) is almost certainly the cause.

DNS Monitoring

Domain Monitor monitors your DNS records continuously and alerts you when any record changes — including when a record unexpectedly reverts to an old value or propagates incorrectly. After a DNS migration, this gives you confirmation that all locations have received the new record. Create a free account.

See what is DNS propagation for a deeper explanation of how DNS caching and TTLs work, and why your domain points to the wrong server for diagnosing related issues.

Also in This Series

• How to Monitor Stripe Webhooks and Checkout Flows
• How to Monitor MySQL Availability, Slow Queries, and Replication Lag
• How to Monitor PostgreSQL Performance and Connection Issues
• How to Monitor Queue Workers on Laravel, Node.js, and Python Apps
• How to Prove Website Downtime to Your Hosting Provider
• Why Your Domain Points to the Wrong Server
• How to Rotate SSL Certificates Without Breaking Your Site
• Let's Encrypt Renewal Failed: Common Causes and Fixes
• Internal vs Public Status Pages: When You Need Both
• How to Reduce Alert Fatigue Without Missing Real Incidents
• Best Status Page Tools for SaaS Startups