AI AI Tools Guidebook
Troubleshooting

TTL Too High: Why Your DNS Change Won't Propagate

Changed an A record but old caches won't expire? The TTL set BEFORE the change controls propagation. Diagnose your case and fix it the right way.

Published: Updated: Author: AI Productivity Guide Team 🌐 查看中文版本

You repointed an A record from old hosting to new hosting. The new server is ready — you can curl the new IP and see the new site. But half your users still see the old site, your email logs show traffic hitting the old IP, and your phone (on cellular) sees the new site while your laptop (on home Wi-Fi) sees the old one. Nothing is broken. You’re watching cached DNS expire at different rates around the world, because the TTL on your record was set high before the change.

This is the single biggest cause of “DNS doesn’t propagate” complaints, and it is preventable. The lasting fix takes 30 seconds — but only if you do it 24 hours before the change, not after.

TL;DR — the fastest thing you can do right now:

  • If you already made the change today, there is no live fix. The old TTL is counting down in caches worldwide; wait it out (up to 24h if the old TTL was 86400). You can shave the tail off the two biggest public resolvers with their purge tools: Google dns.google/cache and Cloudflare one.one.one.one/purge-cache/.
  • Next time: lower TTL to 300 (or your provider’s floor) 24 hours before the change, wait for the old TTL to expire, then change the value. Propagation then completes in about 5 minutes.

How TTL actually controls propagation

TTL (Time To Live) is a number in seconds that the authoritative DNS server attaches to every answer. Every recursive resolver between you and the user (their ISP, their corporate firewall, Cloudflare 1.1.1.1, Google 8.8.8.8) caches the answer for at most that long.

  • TTL 300 = answers expire after 5 minutes, the next query goes back to authoritative, users see the new value within 5 minutes.
  • TTL 3600 = up to 1 hour.
  • TTL 86400 = up to 24 hours.
  • TTL 172800 (2 days) = up to 48 hours. A common registrar default.

The TTL of the current record is what governs how long the old value stays cached. Changing TTL at the same time as changing the value does nothing for the existing caches — they already grabbed the old value and its old TTL, and they keep both until expiry. This is the one rule that explains almost every case below.

Which case are you in?

SymptomLikely causeLive fix?
Authoritative shows new value, public resolvers show oldOld TTL still counting down (Case 1)No — wait it out
dig TTL is higher than the UI claimsProvider caps/ignores your TTL (Case 2)Switch provider, or plan ahead
Brand-new subdomain still returns NXDOMAINSOA negative-cache TTL (Case 3)Lower SOA minimum
dig returns 104.x / 172.x Cloudflare IPsProxy/CDN in front, DNS TTL is moot (Case 4)Purge the proxy’s HTTP cache

Case 1: You changed the record today and it still hasn’t fully propagated

The most common case. You changed both the value and the TTL today. The old caches still have the old TTL counting down.

How to spot it:

# Query authoritative directly — shows the new value immediately
dig yourdomain.com @ns1.your-dns-provider.com +short

# Query public resolvers — some show new, some show old
dig yourdomain.com @8.8.8.8 +short
dig yourdomain.com @1.1.1.1 +short
dig yourdomain.com @9.9.9.9 +short

# Check the cached TTL countdown
dig yourdomain.com @8.8.8.8
# Look at the TTL column in the ANSWER SECTION — that's seconds remaining

If dig against the authoritative server returns the new value but public resolvers return old, the old TTL is still running.

Fix: there is no live fix — wait. The next time, lower TTL 24 hours before. You can speed up the two largest public resolvers manually:

  • Google: dns.google/cache — enter the name, pick the record type (RR Type), solve the captcha. No Google account needed; rate-limited, so a name/type pair can’t be re-flushed back-to-back.
  • Cloudflare: one.one.one.one/purge-cache/ (or 1.1.1.1/purge-cache/) — pick from A, AAAA, CNAME, MX, NS, TXT, and others; the purge fans out to all Cloudflare data centers within seconds. Note: 1.1.1.1 caches for up to 3 hours but respects a shorter TTL if you set one.

These only touch those two resolvers, not your users’ ISPs, so they help the long tail, not the whole world.

Case 2: Your DNS provider is silently capping or ignoring your TTL

Some registrar-as-DNS combos won’t serve the TTL you typed. Two distinct things happen here, and it’s worth telling them apart:

  • A minimum floor. Some control panels won’t accept anything below a fixed value. As of June 2026, GoDaddy’s DNS manager floors TTL at 600 (10 minutes); Cloudflare allows down to 60 for DNS-only records (30 on Enterprise); proxied Cloudflare records are pinned at exactly 300 and can’t be edited. If your panel won’t take 300, use its lowest legal value — 600 still beats 86400 by a mile.
  • A silent override. Older shared-DNS setups (some legacy Namecheap/Bluehost bundled DNS) display one value in the UI while the authoritative server returns a larger one.

How to spot it:

# What does the authoritative actually serve?
dig yourdomain.com @<authoritative-ns> | grep -E "^yourdomain"
# The middle number is the TTL in seconds. Compare it to the UI.

If the UI shows 300 but dig shows 3600+, the provider is overriding you.

Fix: switch to DNS hosting that respects TTL precisely (Cloudflare, AWS Route 53, Google Cloud DNS, NS1, DNSimple, deSEC). If you can’t switch right now, accept the cap and plan every change at least one full TTL ahead.

Case 3: Negative cache (NXDOMAIN TTL) makes new subdomains slow to appear

You added blog.example.com for the first time and it still doesn’t resolve. This isn’t your A record’s TTL — it’s the SOA minimum TTL, which (per RFC 2308) controls how long resolvers cache an NXDOMAIN (“does not exist”) answer. The negative-cache lifetime is the smaller of the SOA minimum field and the SOA record’s own TTL.

How to spot it:

dig SOA yourdomain.com +short
# Output: ns1... admin... serial refresh retry expire minimum
# The LAST number is the negative-cache TTL.
# If it's 86400, an NXDOMAIN can be cached for up to a day.

Fix: lower the SOA minimum field (your provider’s UI may label it “Negative TTL” or “NXDOMAIN TTL”). On Cloudflare and Route 53 the default is already low (Cloudflare uses 1800); some older zones still carry 86400. If you’re about to add a subdomain, query it once after it exists, not before — a pre-creation query is what seeds the NXDOMAIN into caches in the first place.

Case 4: A CDN / proxy layer sits in front of DNS

Cloudflare’s proxy mode (orange cloud) returns its own anycast IPs with a fixed 300-second TTL on the public-facing record and ignores your origin TTL entirely. Vercel and Netlify Edge cache their own.

How to spot it: dig yourdomain.com +short returns Cloudflare IPs (104.x.x.x or 172.x.x.x), not your origin. The public TTL on those is short, but Cloudflare’s internal origin pull follows their own rules.

Fix: once Cloudflare is in front, DNS-layer TTL is moot — they switch origins at the edge in about 30 seconds. If your real complaint is “users still see the old site,” that’s the HTTP cache, not DNS. Purge it from the Cloudflare dashboard (Caching, Purge Everything) or via the cache-purge API.

Shortest fix path (for the next change)

The real fix is procedural, not reactive. Run this 24 hours before any planned DNS change:

  1. 24 hours before: at the authoritative DNS provider, change the TTL on every record you plan to touch from its current value (often 3600 or 86400) down to 300 — or your provider’s floor if it won’t accept 300. Don’t change the value yet. Save.

  2. Wait for the old TTL to expire. If the old TTL was 3600, wait at least 1 hour; if 86400, wait 24 hours. After this point, every cache refreshes within 300 seconds.

  3. Make the actual change (new value, TTL still 300).

  4. Verify across resolvers:

    for resolver in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo "@$resolver: $(dig yourdomain.com @$resolver +short)"
done

    All four should show the new value within 5 minutes.

  5. The next day: raise TTL back to 3600 or higher to cut DNS query load and improve cache hit rate.

How to confirm it’s actually fixed

# Authoritative TTL (what the DNS provider sends)
dig yourdomain.com @<authoritative-ns> | awk '$1=="yourdomain.com." {print $2; exit}'

# Cached TTL countdown at a public resolver (changes on each query)
dig yourdomain.com @8.8.8.8 | awk '$1=="yourdomain.com." {print $2; exit}'

# Repeat the public query after 60s — it should decrement by ~60
sleep 60
dig yourdomain.com @8.8.8.8 | awk '$1=="yourdomain.com." {print $2; exit}'

Two signals tell you the cut-over is complete:

  1. The cached countdown jumps back up to the full TTL instead of decrementing — that resolver just fetched a fresh answer, so the old one expired and the new value is now cached. From this moment, every user on that resolver sees the new value.
  2. The public resolver’s +short value matches the authoritative value. For a global view beyond the four resolvers above, a multi-region checker like whatsmydns.net shows green checkmarks across continents.

Prevention

  • Treat TTL like a knob you turn down before maintenance. Set a calendar reminder: “T-24h: lower TTL to 300.” Then change. Then “T+24h: raise back to 3600.”
  • For records you change frequently (preview environments, staging, A/B test endpoints), leave TTL at 300 permanently. The query-load cost is trivial.
  • For records you never change (root MX, SPF TXT, DKIM TXT), leave TTL at 86400. Higher cache hit rate, and fewer outages if your DNS provider has a brief blip.
  • Don’t change TTL and the record value in the same operation. It doesn’t help. The damage was the previous TTL on the previous value.
  • Pick a DNS provider that respects TTL. Cloudflare, Route 53, Google Cloud DNS, NS1, and DNSimple all honor it precisely. Some cheap registrar-bundled DNS does not.

When this isn’t on you

  • The user’s ISP runs its own caching layer that ignores authoritative TTL and caches for fixed periods (rare, but documented at some Comcast and Asian ISPs).
  • A corporate firewall / WAF caches DNS independently.
  • A browser-level secure DNS (DoH) profile caches separately from the OS resolver.
  • The user has pinned the host in their /etc/hosts file and isn’t using DNS at all.

These are all out of your control. The right answer is to communicate the expected propagation window and move on.

FAQ

Q: What’s a sane long-term TTL for production records? A: 3600 (1 hour) is the sweet spot for records you might change in an emergency. 86400 (1 day) for records you’ll never touch. 300 (5 min) only during planned changes or for endpoints you change weekly.

Q: Does lowering TTL hurt performance? A: A little. Each cache miss adds one DNS round-trip (~20ms) for the first user in that resolver’s region. Even at TTL 300, a busy resolver still hits cache well over 99% of the time, so the impact is negligible. At 3600 it’s smaller still.

Q: My provider won’t let me set TTL below 600. Is that a problem? A: No. As of June 2026, GoDaddy floors TTL at 600 seconds; that’s still 144x faster than 86400. Lower TTL to 600, wait at least one full old-TTL cycle, then make your change. Cloudflare goes down to 60 for DNS-only records if you want tighter.

Q: Cloudflare proxy says TTL is “Auto.” What does that mean? A: When a record is proxied (orange cloud), Cloudflare returns its own anycast IPs with a fixed 300-second TTL to the public, and the “Auto” setting can’t be edited. Your TTL is irrelevant for public propagation, but Cloudflare’s own edge updates within about 30 seconds when you change the origin. For DNS-only (gray cloud) records, the TTL you set is what’s served.

Q: Can I force resolvers to flush their cache? A: Mostly no. You can flush your own machine and ask users to flush theirs. Public resolvers won’t flush on demand — with two big exceptions: Google’s dns.google/cache clears a specific name from 8.8.8.8, and Cloudflare’s one.one.one.one/purge-cache/ does the same for 1.1.1.1. Useful for the stubborn 1% still seeing stale data after a change.

Q: I lowered TTL but the change is still slow. A: You lowered the TTL today and changed the record today. The old TTL is what governs the cache for the old answer. Wait at least the duration of the old TTL — if it was 86400, that’s 24 hours — for caches to flush. Future changes will then be fast.

Tags: #Domain #DNS #SSL #Troubleshooting #TTL #DNS propagation

Related Articles