TTL and DNS Propagation: Why Your Record Change Isn't Live Yet

You just updated a DNS record, but the site still points at the old server. Nine times out of ten this is TTL caching, not a broken config. Once you understand TTL, you can predict how long a change takes—and shrink that wait before you swap an IP or migrate a server.

What TTL Actually Is

TTL (Time To Live) is a value in seconds attached to every DNS record. It tells resolvers worldwide how long they're allowed to cache that record. Typical values are 3600 (one hour) or 86400 (24 hours).

When you point a domain from an old IP to a new one, the authoritative server updates instantly. But every recursive resolver that queried the record beforehand—your ISP's DNS, a public resolver, your own machine—is still holding the old answer. Each one keeps serving it until its local TTL countdown hits zero, then re-fetches from the authoritative server. That overlap window is what people call DNS propagation. Nothing is really "spreading"; caches are simply expiring at their own pace.

Before a Migration: Lower the TTL First

The key trick is to drop the TTL before you make the real change—say from 86400 down to 300 (five minutes).

• Do it at least one old TTL ahead of time (e.g. 24 hours early) so the large cached value expires naturally first.
• Once the whole internet is caching the record on a 300 rhythm, perform the actual IP change.
• Your worst-case wait shrinks from a full day to a few minutes.
• After the migration settles, raise the TTL back to 3600 or higher to cut query volume and improve stability.

Flush Your Local Cache

Sometimes the world has caught up but your own machine still shows the old value, because your OS caches too. Clear it:

Windows:

ipconfig /flushdns

Linux (pick what your distro uses):

sudo resolvectl flush-caches      # systemd-resolved; older: systemd-resolve --flush-caches
sudo systemctl restart nscd       # if you run nscd

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Note: browsers keep their own DNS cache, so restart the browser if needed. You can't force-flush your ISP's recursive resolver—you just wait out its TTL.

Confirm It's Actually Live

Don't conclude "it works" just because it loads for you. Check from several angles.

Read a record's current value and remaining TTL:

dig A example.com +noall +answer
nslookup example.com              # Windows / universal

Bypass local caching by asking a specific public resolver directly:

dig @8.8.8.8 A example.com
dig @1.1.1.1 A example.com

Trace the resolution from the root down to confirm the authoritative server is returning the new value:

dig +trace A example.com

Then use an online multi-location lookup tool that queries many global nodes at once. Only when the major public resolvers and multiple regions all return the new IP is the change truly live everywhere.

Common Misconceptions

• "It goes live instantly." Not unless the old TTL was already tiny—check the original TTL first.
• Testing only your own machine. Your OS and browser caches will lie to you; always try a different resolver and region.
• Lowering the TTL only after the change. By then the large old TTL is already cached, so the lower value won't take effect until the next cycle—too late.

Summary

DNS is never truly instant because TTL governs how long the old value survives in every layer of cache. The right workflow: lower the TTL to something like 300 well ahead of a migration, flush local caches with ipconfig /flushdns or resolvectl flush-caches after the change, then confirm global rollout with dig +trace, direct public-resolver queries, and multi-location checks—raising the TTL again once things are stable. Manage the TTL, and propagation time is yours to control.