DNS Changes Not Propagating After 48 Hours

Step 1 — Confirm the change is correct at the authoritative source

Always start at the authoritative nameserver, not a caching resolver:

# Find the authoritative NS for the domain
dig NS example.com @8.8.8.8 +short

# Query the authoritative NS directly (bypasses all caches)
dig A example.com @ns1.authoritative-example.com

# If this returns the correct new IP, the change is live — propagation is just incomplete
# If this returns the old IP, the change was not saved correctly

Step 2 — Check the TTL of the record before the change

The old TTL determines how long caches are allowed to hold the stale record:

# Query a resolver that has the old cached value
dig A example.com @192.168.1.1

# The TTL shown in the response is the remaining cache lifetime
# e.g., "example.com. 72000 IN A 203.0.113.1" means 20 hours still cached

# What was the original TTL before you changed it?
# If it was 86400 (24 hours), caches can hold it for up to 24 hours after they last refreshed
# A fresh cache hit just before your change = up to 24 more hours of stale data

Step 3 — Check the TLD zone for nameserver delegation

For NS record changes or domain transfers, the TLD nameserver is the source of truth:

# Check .com TLD servers for NS delegation
dig NS example.com @a.gtld-servers.net

# Check .net TLD
dig NS example.net @ns1.nic.net

# If TLD servers return old NS records, the registrar change has not propagated yet
# TLD zone updates typically take 15 minutes to 24 hours depending on the registry

Step 4 — Use a global DNS propagation checker

Check multiple resolvers worldwide:

• https://www.whatsmydns.net/#A/example.com
• https://dnschecker.org/#A/example.com

Look for the pattern: - Consistent old IP in a specific region → those resolvers are still within cache TTL - Consistent new IP globally but one resolver still old → that resolver has extended TTL or an issue

Step 5 — Check for secondary DNS / DNS hosting panel sync

If you use a DNS hosting provider, confirm the change reached the secondary nameservers:

# List all NS records for the domain
dig NS example.com @8.8.8.8 +short

# Query EACH nameserver individually
for ns in $(dig NS example.com +short); do
  echo -n "$ns: "
  dig A example.com @$ns +short
done

If different nameservers return different values, the zone transfer from primary to secondary has not yet completed.

Step 6 — Calculate earliest possible full propagation

Full propagation = time of last cache refresh + TTL of old record.

Example:
- Old TTL: 86400 (24 hours)
- Record changed at: 12:00 UTC Monday
- A resolver that cached the old record at 11:59 UTC Monday will hold it until 11:59 UTC Tuesday
- Maximum wait from time of change = TTL (24 hours in this case, not 48)

"48-hour propagation" is a common myth. True propagation time = old TTL, often 1–24 hours.

Fix 1 — Wait for the TTL to expire (correct approach for most cases)

If the authoritative nameserver is already serving the correct value:

# Check what TTL remains on cached records
dig A example.com @8.8.8.8 | grep -E "^example"
# TTL shown is time remaining — wait this long for each resolver to refresh

Nothing can force external resolvers to flush their caches for your domain. The only correct fix is waiting for the TTL to expire.

Fix 2 — Pre-lower TTL before planned changes (proactive)

Before the next planned change, lower the TTL 24 hours in advance:

# Set TTL to 300 seconds (5 minutes) one day before the change
# DNS hosting panel or zone file:
example.com.  300  IN  A  203.0.113.1   ; current IP, lowered TTL

# After 24 hours, all caches hold at most 5-minute-old records
# Make the change:
example.com.  300  IN  A  198.51.100.5  ; new IP

# After change propagates (5 minutes), restore long TTL
example.com. 3600  IN  A  198.51.100.5

Fix 3 — Verify and fix the authoritative server

If the authoritative server is still returning old data:

# Log into your DNS hosting panel and confirm the record shows the new value
# Then re-query the authoritative NS directly:
dig A example.com @ns1.yourdnsprovider.com

# If it still shows old data, check for:
# - Multiple A records (old one not deleted)
# - Wrong zone (editing a subdomain zone vs. the parent)
# - Cache at the DNS hosting panel itself (some providers cache for a few minutes)

Fix 4 — Force secondary zone transfer (if you control the NS)

# BIND 9 — force zone transfer to secondaries
sudo rndc reload example.com
sudo rndc notify example.com

# On secondary — force refresh from primary
sudo rndc retransfer example.com

Fix 5 — Flush corporate resolver cache (if accessible)

For internal resolvers where you have admin access:

# Unbound
sudo unbound-control flush_zone example.com

# systemd-resolved
sudo resolvectl flush-caches

# Windows DNS Server (PowerShell)
Clear-DnsServerCache

• Set a low TTL (300–600 seconds) at least 24 hours before any planned DNS change; restore the original TTL after the change is confirmed working
• Query the authoritative nameserver directly (not a caching resolver) to verify the change is correct before waiting for propagation
• Use a global propagation checker immediately after making a change to establish a baseline — this helps distinguish 'not propagated yet' from 'change not applied correctly'
• Understand the registrar's nameserver delegation TTL (often 48–172800 seconds at the TLD) when planning domain migrations — this is separate from your zone's record TTL
• Document the old TTL for each critical record so you know the maximum propagation window before making time-sensitive changes