DNS Record TTL Expiry Calculator

When you click save after changing a DNS record, the clock begins to tick. But you probably don’t get to see it. So when you go reload site after updating A record to point to new server IP, you still see old address. The internet seems broken.

The issue is naturaly more about caching and patience than anything else. Those hard limits called time to live (TTL) aren’t a suggestion; they’re the value that origin server sets telling resolvers just how long they can hoard that answer without checking back with the original source. Use our calculator above and it’ll do the math for you, converting these abstract seconds into something concrete that you can plan around.

How DNS Propagation Works

To understand why your change isn’t spreading, realize that there’s a layer of caching between you and recursive resolver provided by your ISP. This layer may impose a maximum on all TTLs (twenty four hours is common) or respect them strictly. Then there’s whatever minimum your local network hardware applies to cached entries, usually stretching a brief TTL into more lengthy one. Next, there are small but often overlooked caches in your operating system or browser that come from recent lookups. Sum the time left in each bucket and you have overall delay. And that’s how a five-minute TTL feels like a five-hour wait when you haven’t considered local floor values.

Most folks is unaware that they get burned by negative caching. When you attempt to resolve a non-existent domain, the resolver doesn’t simply forget and ask again; it will cache the negative response. This is good because it stops your PC from asking over and over for missing record. However, even after you create that record, it will still return cached negative result buried in negative cache. Unlike the normal TTL you assign to a positive reply, the expiry of this are typically calculated from the minimum field of the SOA record. It’s one of those small details that has system admins scratching their heads for hours thinking their newly created site was live but their users could never find it.

When you’re planning a migration, think backwards from old TTL (not the new one). What’s the most common error people make? They drop the TTL down to sixty seconds as soon as they change the IP address. That doesn’t do anything useful for the users who has cached your old IP with a two hour timer on their computers. Once those timers have started ticking, they don’t stop; they just keep ticking away. Instead, what you should of do is lower the TTL way back before migration, give it some time to propagate, and then make the change. By the time you flip the switch, the cached data is already about to expire. It’s a small thing, but man it makes such a diffrence in uptime.

Changing a CNAME involves two lookups. In this case, the TTL of the alias and the TTL of the final address may not match. Changing an MX will affect mail flow because queues and retries will keep old routing information longer than the TTL suggests. This table details those differences by record type. It also shows how managed edge services does fast updates using short TTLs, compared to what you may see from home labs which may impose longer floors. The key is that you match your plan to most restrictive cache along the path. “If there’s a layer that ignores your low TTL and caches things for an hour, then your five minute plan is now an hour long plan.

Then there’s the verification buffer. Once you reach the theoretical expiry time, I suggest waiting another little while before assuming the change has took effect. That covers publish lag, where your DNS provider take several seconds to spread the change to all their nodes around the world. It also covers the possibility of network blips causing some resolvers to continue serving old data. Ten percent added to your calculation as a buffer is not unreasonable. What might have been a risky cutover becomes a managed transition.

In conclusion, DNS propagation is a game between memory and time. And these numbers on the chart aren’t just data, but instead a timeline of how long the internet will recall what was once configured. Use this as a countdown clock instead of thinking of it as a fixed number, plan your changes accordingly knowing when the clock expires. From a home lab to tweaking your mail server hostname, be aware of age of the caches and you’ll both be viewing the same world. When the clock runs out, check back. It always wins.