DNS Propagation Stuck? Fix Cloud Records Not Updating

Stop refreshing your DNS dashboard—it's not helping

You changed a record in Cloud DNS, waited an hour, checked again—still showing the old IP. Yeah, I've been there. Last month a client's entire e-commerce site was pointing to a dead server because of this exact issue. Here's what actually works.

The real fix: decrease TTL before the change

The number one reason DNS propagation looks stuck is the Time-To-Live (TTL) value on the old record. If your old A record had a TTL of 86400 seconds (24 hours), that's how long every DNS resolver in the world will cache that record before checking for updates. You can't rush physics, but you can outsmart it.

1. Before you make any DNS change, drop the TTL on the existing record to 60 seconds (or 300 for production safety). Wait for the old TTL to expire naturally—check with dig yourdomain.com +ttlunits or nslookup -type=soa yourdomain.com. If it still shows 86400, you haven't waited long enough.
2. Make your DNS change—update the record to the new IP or target.
3. Wait 60 seconds, then verify propagation using multiple resolvers: Google's 8.8.8.8, Cloudflare's 1.1.1.1, and your ISP's DNS. A simple dig @8.8.8.8 yourdomain.com confirms if Google sees the new record.
4. After confirmed, raise TTL back to a sensible value (3600 for standard, 86400 for rarely-changed records).

Azure DNS specific gotcha

If you're using Azure DNS, check the resource group's lock settings. Had a case where a read-only lock blocked record updates silently—the portal showed success, but Azure never applied the change. Unlock the resource group, update the record, relock it after.

Why this works—the DNS caching chain

DNS propagation isn't magic. Every resolver—your ISP, Google, Cloudflare—respects the old TTL. They won't re-query your authoritative DNS server until that TTL expires. By lowering TTL before making the change, you're ensuring the entire internet sees the new record within minutes, not days. Skip this step, and you're fighting against a 24-hour cache wall.

Also, some cloud DNS providers (AWS Route 53, Google Cloud DNS) have propagation delays at the edge even after the resolver updates. Route 53 typically propagates globally within 60 seconds, but Google Cloud DNS can take up to 5 minutes due to their anycast network. Not a bug—just how their infrastructure works.

Less common variations of the same problem

CNAME flattening and alias records

If you're using an alias record (Route 53) or CNAME flattening (Azure DNS), the DNS provider handles resolution differently. The alias record points to an AWS resource like an ELB or CloudFront—that resource's IP can change. If the alias target is unhealthy or deleted, the record won't resolve even if TTL is low. Check the target resource's health first, not the DNS record.

DNSSEC validation failures

If you enabled DNSSEC on your domain, a record change can break the signature chain. DNS resolvers that validate DNSSEC will refuse to return the new record—you'll see SERVFAIL errors in dig output. Fix: regenerate your DNSSEC signing keys in the cloud provider's console after the record change, then wait for TTL to expire on the old DS record at the registrar. I've seen this take 48 hours because the registrar's TTL was set high.

Split-brain DNS with on-premises

Some businesses run internal DNS servers that cache the old record longer than public resolvers. If you manage a hybrid cloud, check your on-premises DNS servers—they might have a separate TTL for internal zones. Flush their cache with ipconfig /flushdns (Windows) or systemd-resolve --flush-caches (Linux) after the cloud change.

Cloud DNS with CDN or WAF proxies

If you're using Cloudflare, Akamai, or Azure Front Door, the DNS record might be proxied—meaning the CDN's IP is what end users see. Changing the DNS record alone won't update the CDN config. You need to purge the CDN cache or update the origin server address in the CDN settings. I had a client last month whose Cloudflare proxy was still sending traffic to an old server IP two days after the DNS change—because they forgot to update the origin in Cloudflare's dashboard.

Prevention: set TTL low before any planned change

Stop treating DNS changes as emergencies. Here's a pattern I use for all my clients:

• Keep a pre-change checklist that includes lowering TTL 24 hours before any scheduled change.
• For critical records (A, AAAA, CNAME for your main domain), set a default TTL of 300 seconds. Yes, it increases query volume to your DNS provider, but for most small businesses, the cost is pennies. The peace of mind is worth it.
• Use DNS monitoring tools like Checkly or Dotcom-Tools that check from multiple global locations. Don't rely on your local browser's cache—it'll lie to you.
• Document your current TTL values and target resources in a plain-text file or spreadsheet. When you need to make a fast change mid-crisis, you won't waste time hunting down the old values.

DNS propagation failure is almost always a TTL problem dressed up as something mysterious. Lower the TTL, make the change, verify with multiple resolvers, raise TTL back. Do that, and you'll never spend another afternoon refreshing the same dashboard.