DNS TTL Explained, With a Calculator for the Wait After a Change

Work out the longest time a cached answer can still be served after a DNS change, and read why lowering the TTL afterwards does not shorten a wait that has already started.

By Net Insight Published 2026-09-17 Updated 2026-09-17

What a TTL is

A time to live is the number of seconds a resolver may keep an answer before it has to ask again. It is published with the record, it counts down independently inside every cache that holds a copy, and it is the only number that determines how long an old answer can survive after you change the record.

That last sentence is the whole subject of this page, and it is worth separating from a related but different question. A TTL does not affect how quickly a name resolves, how fast a connection is established, or how many servers answer. It affects how long incorrect or outdated information can persist, and it affects how much query load your authoritative servers receive.

The arithmetic, stated plainly

The window is the old TTL minus the time already elapsed since the change, floored at zero. A resolver that cached the previous answer one second before your change is the worst case, which is why the calculation does not need to know anything about when caches were warmed.

The two inputs are deliberately the old TTL and the elapsed time. The old TTL is the one that mattered: the value that was on the record when the last cache somewhere fetched it. Reading the number from the new record after the change is the mistake this order is designed to prevent.

Why lowering the TTL afterwards does not help

This is the most common misunderstanding in DNS operations, and it follows directly from the arithmetic. A copy already sitting in a cache was given a lifetime when it was fetched. Changing the published TTL does not reach into that cache and rewrite the remaining time. The copy keeps counting down to the number it was given.

The procedure that does work is to lower the TTL first, wait for the old longer value to expire everywhere once, and then make the record change. At that point every cache holds a copy with a short lifetime, and the change becomes visible within that short window. The cost is a period of higher query volume before the change, which is a deliberate trade rather than a side effect.

Negative answers use a different timer

There is a second caching rule that surprises people, and it applies to names that do not exist. When a resolver is told that a name does not exist, it caches that negative answer for the interval published in the zone’s SOA record, not for a record TTL. There is no record TTL to inherit, because there is no record.

The practical consequence is that creating a name which previously did not exist can appear to take longer than changing one that already existed. A resolver that was asked about the name during the period when it did not exist has a negative answer cached, and it will keep returning “does not exist” until that interval runs out. Measuring the wait for a new name against the TTL you just set will therefore produce a result that looks wrong and is not.

Where the number comes from in a real report

Every record in a DNS answer carries its own remaining TTL, and that value is a countdown rather than the configured maximum. Two resolvers holding the same correct answer will usually report different TTL values simply because they fetched it at different moments. That is why the DNS lookup report preserves the TTL as it was returned, and why the propagation checker ignores TTL differences when deciding whether two resolver answers agree.

The shortest TTL across all types is the useful summary figure. It is the longest time any correct cache could still serve the previous answer, and it is the number to compare against the calculation above.

What this calculator does not do

It does not measure anything about your actual caches. There is no way to ask the internet which resolvers hold which copy, so the result is a bound derived from your own inputs rather than an observation about the network. The report says so rather than presenting the number as a measurement.

It does not account for local caching that you do not control. Browsers, operating system resolvers and application-level caches keep their own copies with their own lifetimes, and a machine that has the old answer cached locally will keep showing it long after every public resolver has the new one. Clearing a local cache is a separate action and is usually the fastest way to confirm that a change has landed.

It does not apply to negative answers, as described above, and it does not model resolvers that impose their own minimum or maximum TTL. A resolver with a floor will hold an answer longer than your record asked for, and no published value prevents that.

Record types other than the address records follow the same timer, so the calculation applies equally to a mail route change or a policy text change. What each type is for, and which ones a normal zone needs, is in the DNS record reference. For the order to run these checks when a change has gone wrong, the network guide puts them in sequence.

Keep this setup

Save the settings to your Sitefarm account. Uploaded files and generated results are not stored.

Questions worth asking

Does a lower TTL make my site faster?

No. TTL controls how long a resolver may keep an answer, and it does not affect the speed of a connection. A very low TTL only means more queries to your authoritative servers and more chances for a resolver to notice a change quickly.

I lowered the TTL and the change is still not visible. Why?

Because copies that were already cached keep the lifetime they were given. Lowering the TTL shortens only copies fetched after the change. The way to control the window is to lower the TTL before making the change and wait out the old value once.

Why does a brand new name seem to take longer than a changed one?

Negative answers are cached with a different timer, taken from the SOA minimum rather than from a record TTL. A resolver that was told the name did not exist keeps that answer for the SOA minimum, which can be longer than the record TTL you chose.

Is 300 seconds a good TTL?

It is a common compromise rather than a rule. Lower values shorten the window in which a mistake is hard to reverse; higher values reduce query volume. The number to pick depends on how often you change records and how long an error would be tolerable.

Do all resolvers respect the TTL I publish?

Mostly, with two exceptions worth knowing. Some resolvers impose a minimum of their own, and a client that cached the answer locally — a browser, an operating system stub, an application — adds another copy with its own lifetime that you do not control.