Cloud DNS Record Propagation Stuck – Fix in 5 Minutes

Quick answer: TTL too high or old cache. Lower your TTL to 300 seconds before making changes. Then flush your local DNS.

I know this is frustrating. You changed a DNS record hours ago, but the world still sees the old IP. Visitors get errors, emails bounce, and your boss is asking why the site is down. I've been there. This tripped me up the first time too, especially when I switched providers from AWS to Cloudflare.

DNS propagation isn't magic. It's controlled by Time To Live (TTL) — a number you set on each record. TTL tells caching servers (like your ISP's DNS) how long to keep the old record before asking for a new one. If your TTL was 86400 seconds (24 hours), you'll wait a full day. But there's more: your own computer, browser, and router might hold old copies. And sometimes cloud providers have internal caches you can't see.

Here's the real fix, step by step.

Step 1: Check your TTL

Log into your cloud provider's DNS console (AWS Route53, Cloudflare, Google Cloud DNS, Azure DNS, or your registrar). Look at the record you changed. If TTL is over 3600 seconds (1 hour), change it to 300 seconds (5 minutes) — before you make any more changes. Apply the new TTL, wait 5 minutes, then change the record value. I always do this 24 hours before a planned change, but if you're in a hurry, do it now.

Step 2: Flush your local DNS cache

Your computer is the biggest liar. It remembers old DNS records even after you change them. Open a terminal (Command Prompt on Windows, Terminal on macOS/Linux) and run:

Windows 10/11:

ipconfig /flushdns

macOS Ventura and later:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo resolvectl flush-caches

After this, close your browser completely (all tabs, all windows) and reopen it. Chrome and Firefox have their own DNS caches too. On Chrome, go to chrome://net-internals/#dns and click "Clear host cache".

Step 3: Use dig to see what the world sees

I never trust a browser check. Use a tool that queries public DNS servers directly. The dig command is your best friend. Open a terminal and run:

dig example.com @1.1.1.1

This asks Cloudflare's DNS server (1.1.1.1) what it thinks example.com is. Replace with your domain. The answer section shows the record. If it's still the old value, propagation hasn't reached Cloudflare yet. Try Google's DNS too:

dig example.com @8.8.8.8

If one shows the new value and the other shows the old, you're seeing regional caching. That's normal — give it more time, usually 10-30 minutes with a 300-second TTL.

Step 4: Check your cloud provider's status

Sometimes the problem isn't on your side. AWS Route53, Cloudflare, and Google Cloud DNS have occasional propagation delays. Check their status pages:

AWS Route53: health.aws.amazon.com
Cloudflare: cloudflarestatus.com
Google Cloud DNS: status.cloud.google.com

If they report issues, stop troubleshooting. Wait for their fix.

Step 5: Use a DNS propagation checker tool

For a quick global view, use a web-based tool like whatsmydns.net or dnschecker.org. They query dozens of servers worldwide. If 80% show your new record, you're good. The remaining 20% will catch up within the TTL window.

What if it's still stuck after 2 hours?

Two things could be wrong. First, your registrar's nameservers might still point to the old provider. Log into your registrar (GoDaddy, Namecheap, Google Domains) and confirm the nameservers match your cloud DNS provider. Second, your domain might have a high TTL set at the registrar level — that controls how long caching servers hold the nameserver records themselves. This is rare, but I've seen it with .com domains that had a 48-hour TTL on the NS records.

If neither works, contact your cloud provider's support. For AWS Route53, open a support case. For Cloudflare, use the live chat. Tell them the exact domain, the record type (A, CNAME, TXT), and what dig shows. They can force a cache clear on their end sometimes.

How to prevent this next time

Lower your TTL to 300 seconds (or even 60 seconds) on all records a day before you make changes. Set a reminder. I use a calendar event that says "Reduce TTL on example.com". After propagation is complete (usually 24-48 hours later), raise it back to 3600 or 86400 to reduce DNS query load.

Also, never make DNS changes during peak traffic hours. Friday afternoon is a bad idea — you'll spend the weekend wondering why the site is down. Do it Tuesday or Wednesday morning.

"DNS propagation isn't magic. It's math. TTL controls everything." — Priya, after fixing 200+ sticky DNS issues

One last thing: if you're using a CDN like Cloudflare, remember that their proxy (orange cloud) adds a layer. The DNS might resolve to Cloudflare's IPs immediately, but Cloudflare's edge servers might still serve old cached content. Clear Cloudflare's cache in the dashboard under "Caching > Purge Everything".

Good luck. You'll be seeing the new record within 10 minutes.