DNS changes not propagating

You've updated your DNS records but the new values aren't showing up everywhere yet. DomainDash may show a Slow status or continue showing the old state. This is usually a waiting game — but there are things you can check and do to move faster.

Symptom

• DomainDash shows dns_propagation_pending or continues to show the previous DNS values after a change
• Some visitors reach the updated site; others still hit the old destination
• Running dig example.com @8.8.8.8 returns a different result to dig example.com @1.1.1.1
• Your browser shows the old site but a VPN or different network shows the new one
• A global DNS checker shows a mix of old and new values across different regions

What it means

DNS propagation is the delay between updating a record at your DNS provider and every resolver around the world picking up the new value. When you save a change, your DNS provider's nameservers start serving the new record immediately — but resolvers that already have the old record cached won't re-query until that cached entry expires.

How long that takes is controlled by the Time to Live (TTL) on the old record. A TTL of 3600 means resolvers may hold the old value for up to an hour. A TTL of 86400 — the default on many providers — means up to 24 hours. This is not a bug; it's how DNS is designed to work efficiently at global scale.

The DomainDash status dns_propagation_pending means the checker sees records, but they appear inconsistent across the resolvers and locations it queries.

Common causes

• High TTL on the old record — the previous record's TTL determines how long caches keep it. If it was set to 24 hours, resolvers are entitled to keep the old value for up to 24 hours after you made the change.
• Resolver caching beyond TTL — some ISP resolvers (and a small number of public resolvers) ignore TTLs and cache records for longer than they should. This is out of your control, but it affects a small fraction of visitors.
• Browser DNS cache — browsers cache DNS results independently of the OS, sometimes for minutes or hours. Clearing it manually is the fastest fix if only you are affected.
• Local /etc/hosts override — a manual entry in /etc/hosts (or the Windows equivalent) takes precedence over DNS entirely. Easy to forget about.
• DNSSEC misconfiguration — if the DS record at your registrar doesn't match the DNSKEY at your DNS provider, DNSSEC-validating resolvers will refuse to return results at all, which can look like a propagation failure.
• Wrong record type saved — you made a change, but accidentally saved the wrong record type or left the old record in place alongside the new one. Always worth double-checking the provider's dashboard.

How to fix

There is no way to force global DNS propagation — caches will expire on their schedule. What you can do is confirm propagation is progressing, clear local caches so you see the new state immediately, and handle DNSSEC issues if that's the cause.

1. Confirm the record was saved correctly. Log in to your DNS provider's dashboard and verify the change is there with the correct type and value. A common source of confusion: saving the right change but then checking the wrong record.

2. Check the TTL on the record. Run:

   dig +nostats +noquestion +nocomments +nocmd example.com A

   The third column shows the remaining TTL in seconds. If it's 86400 (24 hours) and you changed the record recently, you may need to wait. For future changes, lower the TTL to 300 seconds a few hours before making a change — this reduces propagation time from hours to minutes. Restore it to a higher value once the change is live everywhere.

3. Test from multiple resolvers. Compare results across public resolvers to see how far propagation has spread:

   dig example.com A @1.1.1.1
   dig example.com A @8.8.8.8
   dig example.com A @9.9.9.9

   If all three return the new value, propagation is essentially complete. A mix of old and new is normal mid-propagation. Use dnschecker.org for a broader worldwide view.

4. Clear local caches if only you are seeing the old value. For Chrome, go to chrome://net-internals/#dns and click "Clear host cache". To flush your OS cache:

   • macOS: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
   • Windows: ipconfig /flushdns
   • Linux (systemd): sudo systemd-resolve --flush-caches

   Also check /etc/hosts for any manual overrides: cat /etc/hosts.

5. Check for DNSSEC validation failures. If your domain uses DNSSEC, a mismatch between the DS record at your registrar and the DNSKEY at your DNS provider will cause DNSSEC-validating resolvers to block the response. Use the Verisign DNSSEC Debugger to check your domain. If there's a mismatch, contact your DNS provider or registrar to re-sync the DS record.

6. Verify with DomainDash. Once external resolvers show the new records consistently, go to your site in DomainDash and click "Check now". The status should update to reflect the new DNS state. DomainDash checks from multiple locations — if some regions still show the old records, propagation to those areas is ongoing.

How to verify

After waiting for propagation:

1. dig example.com A @8.8.8.8 — should return the new IP address.
2. dig example.com A @1.1.1.1 — should return the same.
3. dig example.com A @9.9.9.9 — confirming a third resolver updates your confidence further.
4. In DomainDash, click "Check now" — status should show Healthy with the new record values.

For future changes: lower your TTL to 300 seconds a few hours before making the change. Once the change is live and propagated, raise the TTL back to 3600 or higher to reduce DNS query load on your nameservers.

Related

• No A or AAAA records — if records are absent entirely rather than in transition
• Nameservers unreachable — if the nameservers aren't responding at all
• Domain not resolving — if you're not sure which DNS issue you have
• DNS health — how DomainDash runs DNS checks