DNS Propagation Still Pending After 24 Hours? Here's Why

First: Confirm the Problem Is Actually Propagation

Before blaming propagation, eliminate the most common false positives. Many "propagation problems" are actually something else entirely.

💡 Tip: Query your authoritative nameserver directly first. If it's serving the wrong record, propagation isn't your problem — the change didn't save correctly, or you edited the wrong zone.

Run this sequence before proceeding to cause analysis:

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

# Step 2: Query your authoritative NS directly (bypasses all caching)
dig example.com A @ns1.yourprovider.com +short

# Step 3: Query a public resolver
dig example.com A @8.8.8.8 +short

# Step 4: Query your local resolver (what you're currently seeing)
dig example.com A +short

Interpreting the results:

• Auth NS shows old value, public resolver shows old value: Your DNS change didn't save, or you edited the wrong record/zone. This is not a propagation issue — go back to your DNS control panel.
• Auth NS shows new value, public resolver shows old value: Genuine propagation delay. The change is live at the source; caches haven't expired yet. Proceed to the cause analysis below.
• Auth NS shows new value, public resolver shows new value, local resolver shows old value: Your local machine or your ISP's resolver is lagging. Flush your local cache and try switching to 1.1.1.1 temporarily.
• Auth NS shows new value, some global resolvers show new, others show old: Normal mid-propagation state. Different resolvers are at different points in their TTL cycle.

Use our DNS Propagation Checker to query your record from 100+ global resolver vantage points simultaneously — this tells you exactly how widespread the propagation is and which regions are still lagging.

Cause 1 — Your TTL Was Too High Before the Change

This is the most common cause of DNS propagation taking too long, and it's entirely self-inflicted.

When resolvers cache your DNS record, they store it for the duration of the TTL that was on the record when they last fetched it. If your A record had a TTL of 86400 (24 hours) and a resolver fetched it at 11:00 AM, that resolver will serve the old value until 11:00 AM tomorrow — regardless of what you changed at 2:00 PM.

The TTL you set after making the change only affects resolvers that query your nameserver after the change. Resolvers already holding a cached copy won't check in again until the old TTL expires.

What you can do now: Wait. You're at the mercy of whatever TTL was on the record before the change. The maximum additional wait time is the old TTL value minus the time since the record was last cached by each resolver. In the worst case (a resolver that cached the record 1 minute before you made the change with a 24-hour TTL), you're waiting close to the full 24 hours.

What you can do next time: Lower the TTL to 300 (5 minutes) at least 24–48 hours before any planned change. This is the pre-migration TTL strategy — described in our How DNS Propagation Works guide. The wait for propagation drops from 24+ hours to under 15 minutes.

Cause 2 — Negative Caching (NXDOMAIN Records)

Negative caching is less well-known but just as frustrating. If your domain or subdomain didn't exist before (or was previously deleted), resolvers received NXDOMAIN responses — "this domain does not exist." Per RFC 2308, recursive resolvers cache NXDOMAIN responses for the duration of the SOA record's minimum TTL field.

This means that even after you create the record, resolvers that have a cached NXDOMAIN for that name won't query your nameserver again until the negative cache TTL expires.

How to diagnose:

# Check your zone's SOA record for the minimum TTL (last field)
dig example.com SOA +short

# Example output:
# ns1.provider.com. hostmaster.provider.com. 2024031501 10800 3600 604800 3600
# The final value (3600) is the minimum TTL — controls negative caching

The last number in the SOA output is the minimum TTL. If it's 86400, resolvers that cached an NXDOMAIN for your subdomain will hold it for up to 24 hours. Lowering this value in your zone helps for future situations but won't expire existing negative cache entries.

ℹ️ Note: Negative caching most commonly affects new subdomains (e.g., you're adding api.example.com for the first time), records that were recently deleted and re-created, and domains or subdomains that experienced an NXDOMAIN period during a migration.

Cause 3 — ISP Resolvers That Ignore TTL

Some ISPs operate recursive resolvers that do not honour your declared TTL. Instead of fetching a fresh record when the TTL expires, they cache records for a fixed internal duration — sometimes 24 hours, sometimes longer. This is non-compliant with RFC 1034 and RFC 1035 but it exists, particularly with certain regional ISPs and telecom-operated resolvers.

How to identify this cause:

You'll see it when propagation appears complete for most global resolvers (your DNS Propagation Checker shows green across most locations) but a specific geographic region or ISP's resolver is still returning old data well beyond what the TTL would explain.

# Check what a specific ISP resolver is serving (if you know their resolver IP)
dig example.com A @<isp-resolver-ip> +short

# Compare the TTL remaining (a very high remaining TTL on a low-TTL record is suspicious)
dig example.com A @<isp-resolver-ip>

What you can do: Nothing, technically. You cannot force an external resolver to expire its cache. The practical options are:

1. Wait for the ISP's internal cache policy to expire the record.
2. Advise affected users to switch their device DNS to 1.1.1.1 by Cloudflare or 8.8.8.8 by Google temporarily — both are RFC-compliant and update faster than most ISP resolvers.
3. If this is a business-critical scenario affecting known users, contact the ISP's network operations team — some will manually flush caches for legitimate requests.

Cause 4 — Stale Records at Your Registrar

This cause is distinct from a DNS propagation problem — it's a configuration problem masquerading as one. Your registrar controls the NS records that appear in the parent zone (the TLD's DNS servers). If those NS records point to the wrong nameservers, every resolver that follows the delegation chain will end up at the wrong authoritative nameserver — and get either old data or an NXDOMAIN.

How to diagnose:

# Check what NS records are published in the parent zone (TLD level)
dig example.com NS +trace

# Or check WHOIS for the registered nameservers
whois example.com | grep -i "name server"

Compare the nameservers shown in the parent zone against the nameservers listed in your DNS provider's control panel. They must match exactly.

Use WHOIS Lookup to verify the nameserver delegation at the registry level, and NS Lookup to check what NS records are currently being served.

⚠️ Warning: Registrar NS record updates can themselves take time to propagate through the TLD's DNS servers (typically 24–48 hours for some registries). If you just changed nameservers, this may add an additional propagation layer on top of your zone-level changes.

Cause 5 — Wrong Nameserver Delegation

Related to Cause 4, but distinct: your registrar may show the correct nameservers in its UI, but the actual NS records in your DNS zone might not match, or the glue records (IP addresses for NS hostnames that are within the same domain) might be missing or incorrect.

This is particularly common when:

• You migrated from one DNS provider to another but left residual NS records in the zone.
• Your DNS zone has NS records pointing to one provider while your registrar delegates to another.
• You're using nameservers that are within your own domain (e.g., ns1.example.com) without glue records.

How to diagnose:

# Run a full trace to see where the delegation breaks
dig example.com A +trace

# Check the NS records in your own zone
dig example.com NS @ns1.yourprovider.com

# Verify glue records exist if using in-domain nameservers
dig example.com NS +additional

Run a DNS Check on DNSnexus to get a full zone health report, which will flag delegation mismatches, missing glue records, and NS inconsistencies automatically.

Diagnostic Checklist: Isolating the Real Cause

Follow this decision tree when DNS propagation is taking too long:

Step 1: Is the new record live on your authoritative nameserver?

• Query your auth NS directly: dig example.com A @ns1.yourprovider.com
• If NO → Your change didn't save. Fix in DNS control panel. Stop here.
• If YES → Continue to Step 2.

Step 2: Is the new record visible on a major public resolver?

• Query Google: dig example.com A @8.8.8.8
• If YES → Your local resolver or ISP is lagging. Flush local cache (ipconfig /flushdns or sudo dscacheutil -flushcache). Try 1.1.1.1 as your DNS.
• If NO → Continue to Step 3.

Step 3: What was the TTL before the change?

• Check git history, DNS audit logs, or ask your DNS provider.
• If TTL was 86400 and it's been under 24 hours → Normal. Wait.
• If TTL was 86400 and it's been over 48 hours → Proceed to Step 4.

Step 4: Is the registrar delegation correct?

• Run WHOIS Lookup and confirm nameservers match your DNS provider.
• Run dig example.com NS +trace and verify the chain is intact.
• If delegation is wrong → Fix at registrar. TTL for NS at TLD level applies.
• If delegation is correct → Proceed to Step 5.

Step 5: Is this a new subdomain or recently deleted record?

• If YES → Check SOA minimum TTL for negative cache duration. Wait.
• If NO → You're likely hitting ISP resolvers with TTL override behaviour. Scope the affected resolvers. Wait or advise users to switch resolvers.

How to Accelerate Resolution (What You Can and Can't Control)

What you CAN do:

• Flush your local DNS cache. Doesn't help other users, but resolves the issue for your own machine immediately.

  Code

  # Windows
  ipconfig /flushdns
  
  # macOS
  sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  
  # Linux (systemd)
  sudo systemd-resolve --flush-caches
  

• Switch your DNS resolver to 1.1.1.1 or 8.8.8.8. Public resolvers tend to be more RFC-compliant and update faster than many ISP resolvers. This is a per-device change.

• Contact your DNS provider's support if the auth NS is serving wrong data. If the authoritative nameserver isn't reflecting your change, escalate with them.

• Fix delegation issues at the registrar immediately. These are under your direct control and can be corrected right now — the only delay is the registrar's own processing time and the TLD's NS TTL.

What you CANNOT do:

• Force external recursive resolvers to flush their cache.
• Override TTL behaviour on ISP-operated resolvers.
• Make propagation happen faster than the TTL set before the change allows.
• Speed up TLD-level NS propagation (this is controlled by the registry).

For a deeper understanding of why these constraints exist, see our How DNS Propagation Works guide, and for TTL strategy, see DNS TTL Explained.

Frequently Asked Questions

Q: My DNS Propagation Checker shows the new record everywhere except one country — what's happening? A: The resolvers in that region are likely still within their TTL cache window, or the ISP resolvers there override TTL. Check the remaining TTL value being served by those resolvers. If it's abnormally high compared to your record's TTL, you're hitting a non-compliant resolver. Users in that region can switch to 1.1.1.1 or 8.8.8.8 as a workaround.

Q: I changed my nameservers 48 hours ago and some resolvers are still querying the old ones — is that normal? A: Nameserver delegation changes propagate through the TLD's DNS infrastructure, which has its own TTL (often 48–172800 seconds depending on the registry). It's normal for some resolvers to lag. Use dig +trace to see exactly where the delegation chain breaks and confirm your registrar has processed the change.

Q: Can I delete the old DNS record to force resolvers to re-query sooner? A: No. Deleting a record causes resolvers to receive NXDOMAIN on their next query — but they won't make that query until the TTL on their cached answer expires. And once they do get NXDOMAIN, they'll cache that for the negative cache TTL. Deleting records doesn't accelerate propagation and can introduce additional NXDOMAIN caching delays.

Q: Why is my phone seeing the new record but my laptop isn't? A: Your phone and laptop are using different DNS resolvers (mobile data vs home broadband, for example). Each resolver has its own independent cache at its own point in the TTL cycle. This is completely normal mid-propagation behaviour — it means propagation is in progress, not stuck.

Q: Is there a way to completely avoid propagation delays? A: The only way to minimise propagation delay is to lower your TTL well in advance of any planned change. With TTL at 300 (5 minutes), most resolvers will pick up changes within 10–30 minutes. Propagation can never be instant unless you control every resolver your users rely on, which isn't realistic.

Q: My DNS provider says propagation is complete on their end — but I'm still seeing old data. Who's right? A: Your DNS provider is correct that the authoritative nameserver has been updated. Their claim is accurate from the source perspective. The old data you're seeing is in your local cache, your ISP's resolver cache, or a regional resolver cache. Use dig to query your auth NS directly to confirm the record is correct at source, then flush your local cache.

Next Steps

If you've confirmed the record is live on your authoritative nameserver and propagation is simply in progress, use our DNS Propagation Checker to monitor the rollout across global resolvers in real time.

Run a DNS Check for a full zone health report — it will surface delegation issues, SOA configuration problems, and record inconsistencies that could be extending your propagation window.

Browse all DNS guides for related troubleshooting and configuration topics.

Related Guides

• How DNS Propagation Works: TTL, Resolvers & the Global Timeline
• DNS TTL Explained: What It Is, How to Set It, and When to Lower It