DNS Not Propagating? 8 Fixes That Actually Work

You updated your DNS records hours ago — maybe you pointed a domain to a new host, changed an A record, or swapped nameservers entirely — and nothing has moved. The old IP still shows up everywhere, your site is still pointing at the wrong server, and you're starting to wonder if the registrar even saved the change. DNS propagation failures are one of the most frustrating problems in web infrastructure, partly because the causes are invisible and the error messages are nonexistent. This guide breaks down the eight most effective fixes, in order of likelihood, so you can stop waiting and start diagnosing.

What DNS Propagation Actually Is (and Why It Gets Stuck)

When you change a DNS record, your registrar or DNS host updates its authoritative nameservers immediately. But the rest of the internet does not instantly learn about that change. Resolvers at ISPs, corporate offices, CDN edges, and end-user routers all cache DNS responses for a period defined by the record's TTL (Time To Live). Until that cache expires, those resolvers keep serving the old answer.

Propagation is not a single event — it is thousands of independent cache expirations happening at different times across the globe. Most resolvers respect TTL values, but some override them. Some ISPs cap TTL at their own maximum. Some corporate firewalls serve a local DNS forwarder that never refreshes. And sometimes the problem is not propagation at all — the change was never saved correctly in the first place.

Fix 1: Verify the Change Is Actually Live on the Authoritative Nameserver

This is the first thing to check, because every other fix is pointless if the record was never saved. Query the authoritative nameserver directly, bypassing all caches:

Replace ns1.yourdns-host.com with your actual authoritative nameserver (found in your registrar's DNS settings or by running whois yourdomain.com). If this query returns the old IP, the change was not saved or has not replicated to that nameserver yet. Log back into your DNS control panel and verify the record is correct, then save it again explicitly. Many panels have a misleading auto-save that does not always commit.

You can also use the DNS Lookup tool on this site to query specific nameservers without needing a terminal.

Fix 2: Flush Your Local DNS Cache

Your own computer is almost certainly caching the old answer. Before assuming the whole internet is broken, flush your local resolver cache.

Windows 10 and 11:

macOS (Ventura, Sonoma, Monterey):

Linux (systemd-resolved):

After flushing, open a new browser tab (or use a private/incognito window to bypass any browser-level DNS cache) and recheck. Chrome has its own internal DNS cache that survives a system flush — clear it by visiting chrome://net-internals/#dns and clicking Clear host cache.

Fix 3: Flush Your Router's DNS Cache

Your home or office router acts as a DNS forwarder. It caches responses from upstream resolvers and serves them to every device on the network. Even after you flush your PC's cache, the router may hand back the stale answer immediately.

The fastest fix is a full router reboot (power cycle, not just a soft restart). This clears the forwarder cache on virtually all consumer routers.

If you need more control, log into the router admin panel. Common addresses and portals by brand:

• Netgear: routerlogin.net or 192.168.1.1
• TP-Link: tplinkwifi.net or 192.168.0.1
• ASUS: asusrouter.com or 192.168.1.1
• Linksys: 192.168.1.1
• D-Link: 192.168.0.1

Look for a DNS Cache or Advanced DNS section. On ASUS routers running Merlin firmware, there is an explicit Clear DNS Cache button under Administration. On TP-Link routers, a reboot from the admin panel under System Tools > Reboot clears the cache cleanly.

Fix 4: Switch to a Public DNS Resolver Temporarily

Your ISP's resolver may have an aggressive caching policy or even a bug where it serves stale records past the TTL. Switching to Google (8.8.8.8), Cloudflare (1.1.1.1), or OpenDNS (208.67.222.222) temporarily tells your machine to ask a different resolver that may have already refreshed its cache.

Windows — change DNS adapter settings:

macOS:

This change only affects your machine. It is a diagnostic tool as much as a fix — if the new resolver returns the correct IP, your ISP's resolver is the problem. It will catch up once the cached TTL expires; there is no way to force it remotely.

Fix 5: Check That Your TTL Was Not Set Too High Before the Change

TTL is the single biggest driver of long propagation times. If your old record had a TTL of 86400 (24 hours) and you changed it without lowering the TTL first, resolvers that cached it right before you made the change will not re-query for up to 24 hours. This is working as designed, not a bug.

For future changes, the best practice is to lower the TTL to 300 seconds (5 minutes) at least 24–48 hours before making a record change. After the change is confirmed, raise the TTL back to something reasonable like 3600.

For the current situation, there is no shortcut. Calculate when the cache will expire: find out when a resolver last fetched the record and add the original TTL. You can see the remaining TTL on a record with:

The number in the answer section before the record type is the remaining TTL in seconds at the querying resolver.

Fix 6: Confirm the Nameservers at the Registrar Match Your DNS Host

A common cause of propagation appearing to stall is a mismatch between the nameservers listed at the registrar and the nameservers where you actually edited the DNS records. If you updated records in Cloudflare but your registrar still points to your old web host's nameservers, no amount of waiting will help.

The NS records returned should match exactly what your DNS provider (Cloudflare, Route 53, Namecheap Premium DNS, etc.) gave you. If they do not match, log into your domain registrar and update the nameservers under the domain settings. Nameserver changes themselves take time to propagate — typically 30 minutes to a few hours, though the registry technically allows up to 48 hours.

Fix 7: Check for DNSSEC Signing Errors

If your domain has DNSSEC enabled, a misconfigured or expired DNSSEC key will cause resolvers that validate signatures to return SERVFAIL instead of the actual record. From the outside this looks like propagation failure, but it is actually active rejection of your DNS responses.

Test for DNSSEC validation failure:

If the Cloudflare or Google resolver returns SERVFAIL but querying the authoritative nameserver directly returns the correct answer, DNSSEC is the likely culprit. Also check:

This queries the parent zone (the TLD nameserver) for your domain's DS record. If the DS record present in the parent zone does not match the DNSKEY on your authoritative nameserver, every DNSSEC-validating resolver will reject your records.

The fix is to either update the DS record at your registrar to match your current DNSKEY, or disable DNSSEC temporarily while you troubleshoot. Do not leave DNSSEC half-configured — it breaks the domain for a significant portion of internet users.

Fix 8: Look for Conflicting Records or Zone File Errors

Sometimes propagation appears stuck because there are conflicting records in the zone that resolvers handle inconsistently. Common examples include:

• Both an A record and a CNAME record for the same hostname (this is illegal in DNS and different resolvers handle it differently)
• Multiple A records for the same hostname pointing to different IPs (round-robin), and you only updated one of them
• A wildcard record (*.yourdomain.com) overriding a specific record at a subdomain
• A stale SOA serial number that has not incremented, causing secondary nameservers not to pull the zone transfer

Pull the full zone response from your authoritative nameserver to look for conflicts:

Review every record carefully. If you are on a managed DNS platform like Cloudflare, Route 53, or DNSimple, the control panel will often flag conflicting records. On cPanel-based hosting, check the Zone Editor for duplicate entries. Delete the conflicting record and save the zone again, which will also increment the SOA serial and trigger secondary nameserver synchronization.

How to Verify Propagation Is Complete

Once you have applied one or more of the above fixes, verify the change from multiple vantage points:

1. Query from your local machine after flushing cache: nslookup yourdomain.com
2. Query from a second network (use your phone's mobile data, not Wi-Fi)
3. Query from public resolvers: dig yourdomain.com A @1.1.1.1 and dig yourdomain.com A @8.8.8.8
4. Use the propagation checker to test from global nodes

If all three return the correct IP, propagation is complete from a practical standpoint. Some deeply cached ISP resolvers may lag, but those represent a small and shrinking fraction of users.

How to Prevent This Next Time

The two-step TTL workflow eliminates most propagation pain:

1. At least 24 hours before the planned change: Lower the TTL on the record you intend to change to 300 seconds. Wait 24 hours. Now the maximum cache age for any resolver is 5 minutes.
2. Make the record change. Within 5 minutes, all resolvers will have fetched the new record.
3. After confirming the change: Raise the TTL back to 3600 or higher to reduce DNS query load.

Also keep DNSSEC and your DS records in sync whenever you change DNS providers, and always verify nameserver changes at the registrar before editing records at the new provider. Most propagation nightmares are caused by editing records at a DNS host that is not actually authoritative for the domain yet.

DNS is not magic, and propagation failures almost always have a concrete, fixable cause. Work through these eight fixes systematically, and the vast majority of stalled propagation issues resolve within minutes rather than hours.