DNS changes not propagating

You've updated your DNS records but the new values aren't showing up everywhere yet. The fix is usually to wait, but you can confirm the change is on its way and clear the caches you control.

Symptom

• DomainDash continues to show the previous DNS values after a change, until the public DNS resolver it asks 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.

The Time to Live (TTL) on the old record controls how long that takes. 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. DNS caches by design, so a delay like this is expected.

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 can 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. You can't control this, 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 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, and is 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 refuse to return results, which can look like a propagation failure.
• Wrong record type saved. You saved the wrong record type by accident, or left the old record in place alongside the new one.

How to fix

You can't force global DNS propagation. These steps confirm the change is on its way, clear the caches you control and rule out DNSSEC.

1. Confirm the record was saved correctly. Log in to your DNS provider's dashboard and check the change is there with the correct type and value. It's easy to edit the wrong record or save to the wrong domain.

2. Check the TTL on the record. Run:

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

   The second column (after the name, before the record class) shows the remaining TTL in seconds. If it's 86400 (24 hours) and you changed the record recently, waiting is the fix. For future changes, lower the TTL to 300 seconds a few hours before making the change, then restore it after.

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 complete for most visitors. 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. DomainDash asks a public DNS resolver, the way a visitor's device would, and doesn't query your authoritative nameservers directly. A changed record can take up to its TTL to reach that resolver's cache, and the result updates at the first DNS check after it has. DNS checks run every 6 to 24 hours depending on your plan, so DomainDash can lag behind what dig shows you.

Can you force DNS propagation?

No. There isn't a button, command or tool that makes the whole internet refresh early.

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 tell someone else's resolver to forget what it stored.

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

How to speed up DNS propagation

You can't shorten a TTL that a resolver has already cached. You can do three things:

• Lower the TTL before you make the change. You have to do this 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. Once the change is live everywhere, raise the TTL back to 3600 or higher to reduce DNS query load on your nameservers.

• Flush your own DNS cache. If only you still see the old value, the slow cache is yours. Clear it with the commands in step 4 above.

• Query the authoritative nameserver directly to confirm the change is live. This skips every cache in between and asks the source:

  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 remaining delay is other resolvers holding the old value until their cached TTL runs down, so wait.

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 gives you a third resolver to confirm against.
4. In DomainDash, the site's DNS check shows Healthy with the new record values after its next DNS check.

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