DNS changes not propagating

You've updated your DNS records but the new values aren't showing up everywhere yet. DomainDash may still show the old DNS state until the location it checks from picks up the new record. This is usually a waiting game, but there are a few things you can check and do to move it along, and to confirm the change is on its way.

Symptom

• DomainDash continues to show the previous DNS values after a change, until the location it checks from picks up the new record
• 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 locations

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.

While propagation is in flight, DomainDash may still report the old DNS state for a while, until the location it checks from picks up the new record.

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, open your site in DomainDash. It re-checks DNS on its normal schedule, so the result updates to reflect the new DNS state once the location DomainDash checks from has picked up the change. There's nothing to click. If it still reports the old DNS state, the resolver it queried from hasn't refreshed yet; give it 15–30 minutes.

Can you force DNS propagation?

No, and it's worth being honest about why, because it saves you chasing a fix that doesn't exist. There's no button, command, or tool that makes the whole internet refresh early.

The reason is that propagation isn't one thing happening in one place. Every resolver around the world keeps its own cache, and each one holds the old record until the TTL it cached before your change expires. You changed the record at your provider, but you can't reach into someone else's resolver and tell it to forget what it already stored. Each cache counts down on its own clock, and the longest of those clocks is set by the TTL that was on the record at the moment that resolver last looked it up.

So a service that claims to "force" propagation can really only do two honest things: query lots of resolvers to show you progress, or flush a cache you actually control. Neither one speeds up the resolvers that still hold the old value.

How to speed up DNS propagation

You can't shorten a TTL that's already been cached, but a few things genuinely help, both for the change you've already made and for next time.

• Lower the TTL before you make the change. This is the only real lever, and it has to be pulled in advance. Drop the record's TTL to 300 seconds a few hours before you edit it, so resolvers cache the current value for a much shorter window. When you then make the change, caches expire in minutes instead of hours. Restore the higher TTL once the change is live everywhere.

• Flush your own DNS cache. If only you are still seeing the old value, the slow cache is yours, and that one you can clear.

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

• Query the authoritative nameserver directly to confirm the change is live. This skips every cache in between and asks the source, so you know the new record really is being served, even while other resolvers still hold the old one:

  dig @ns1.example.com example.com

  Swap in your provider's nameserver hostname. If the authoritative answer is correct, the change is live and the rest is just caches catching up.

• Otherwise, wait out the old TTL. Once you've confirmed the record is correct at the source and cleared your own cache, the remaining delay is other resolvers holding the old value until their cached TTL runs down. There's nothing to fix here. Give it time.

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, open your site. On its next scheduled DNS check the status returns to Healthy with the new record values, on its own.

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