search

Found

info Overview

See exactly when a changed DNS record finishes spreading worldwide. Built-in 5min, 1h, 24h and 48h TTL presets with a live remaining-time countdown — free.

📘 How to Use

  1. Pick a TTL preset (5min, 1h, 24h, 48h) or type the exact seconds into the custom field
  2. Set the date and time you changed the DNS record in the change-time field
  3. Read the estimated completion time, the remaining-time countdown, and the progress bar

DNS Propagation TTL Calculator

sec
schedule TTL (readable)
1h 0m 0s
Estimated completion time
-
Countdown
-
-
Elapsed
-
Progress
-

grid_view Related

Article

DNS Propagation TTL Calculator | Estimate When Changes Go Live

Work out exactly when a changed DNS record finishes spreading to resolvers worldwide, based on its TTL and the moment you made the edit. Built-in 5min, 1h, 24h and 48h TTL presets sit next to a live countdown showing the seconds remaining and a progress bar for the worst-case window.

💡 About this tool

You flipped an A record, moved a server, or repointed MX, and now you are hitting refresh wondering when the change is actually live. That guessing game is the real pain of DNS edits, and it comes straight from the TTL (Time To Live) on the record. The TTL says how many seconds a resolver may cache the answer — a value of 86400 means resolvers can serve the old data for a full 24 hours.

Drop in the time you made the change and the record's TTL, and this tool returns the worst-case completion time plus a running countdown of how long is left. Instead of refreshing blindly, you get a hard number for the upper bound, so you can schedule cutover steps, support windows, and "is it live yet?" replies with confidence.

🧐 Frequently Asked Questions

Q. If I set the TTL to 5 minutes (300s), will everyone see the change in 5 minutes? A. Resolvers that fetch the record after your edit pick it up within 5 minutes, but any resolver that cached the old value just before the change keeps serving it until that cache expires. This tool shows that worst-case window.

Q. Why is "just lower the TTL on cutover day" too slow? A. Lowering the TTL on the day of the change does not shorten caches that were already populated with the old, high TTL. Those resolvers hold the stale answer for the full old TTL. Lowering the TTL a day or two in advance is the standard fix.

Q. Why do some resolvers still return old data after the TTL expires? A. Some ISPs do not honor TTL strictly and refresh their caches on their own schedule. When that happens, real propagation can lag behind the estimate this tool shows.

Q. Are my inputs or the calculated time sent anywhere? A. No. Everything is computed in your browser and nothing is sent to a server.

📚 The "myth" of DNS propagation

DNS engineers like to point out that "propagation" is a misleading word. DNS does not push anything out across the internet — it works on a pull model. Each resolver decides on its own when to ask the authoritative server again, and it does that only when the TTL on its cached copy expires. Nothing radiates outward; caches simply time out one by one and refetch.

That is why the dreaded "wait 48 hours" advice is mostly a myth for ordinary record changes. There is no technical reason a fresh A or CNAME edit needs days. If you set a short TTL such as 300 seconds well before the change, the new record can be visible nearly everywhere within minutes — which is exactly the window this calculator helps you plan for.