// FREE TOOL · DNS TTL CALCULATOR
DNS TTL calculator and converter
Type a TTL and get the time it stands for, plus the schedule that actually matters: before a nameserver or host change, lower the record TTL to 300 seconds at least one full old TTL ahead of the cut-over — a 3600-second TTL means lowering it an hour early, a 86400-second one means a day — then cut over, wait one low TTL for every cache to follow, and put the old value back once it is stable. The calculator also does the negative-cache arithmetic from RFC 2308, which is how long a fixed domain keeps answering NXDOMAIN. Free, instant, no signup, and it runs entirely in your browser.
Seconds, or a duration: 3600, 1h, 90min, 1d 12h, 04:00:00. Anything above one week is rejected.
Common values — click one:
The TTL you run while the change is in flight. 300 seconds is the usual choice; below 60 you buy nothing but query volume.
Both come from the SOA in the authority section of an NXDOMAIN answer: dig SOA example.com. RFC 2308 takes the smaller of the two.
How to use the TTL calculator
Three fields, no account, and the arithmetic runs locally — nothing you type is sent anywhere.
- Enter the current TTL. Type the TTL on the records you are about to change, in seconds or as a duration like 1h. The converter shows what it means in readable time and whether it is a switching, balanced or stable value.
- Read the change schedule. It tells you the low TTL to run during the change, how far ahead to publish it, how long caches take to follow the cut-over, and the value to restore afterwards.
- Add the SOA numbers if the domain is returning NXDOMAIN. Run dig SOA example.com, take the minimum field and the TTL of the SOA record, and the calculator returns the RFC 2308 negative-cache window: how long the denial outlives the repair.
Plan an NS change: when to lower the TTL, when to cut over
The reason a TTL number matters is almost never curiosity about seconds. It is that you are moving something, and you want the move to be short. The rule has one non-obvious half:
A lower TTL only helps if you publish it before the change — at least one full old TTL before. Lowering a 24-hour TTL to 300 seconds ten minutes before you cut over does nothing, because resolvers holding yesterday's copy will not come back to see the new, lower value until tomorrow. The old TTL has to expire on its own first. That is the whole schedule:
- Lower the TTL to 300 seconds, one old TTL ahead of the change — two, if you want margin, since some resolvers refresh early and some do not.
- Cut over: change the nameservers, or repoint the records.
- Wait one low TTL — five minutes — and every cache that follows the rules has the new answer.
- Put the old TTL back once it is stable, so you are not paying for a lookup on every visit.
One thing you cannot lower is the TTL on the delegation itself. The NS records that point at your nameservers live in the parent zone, published by the registry, and many registries set them to 48 hours. That is why a nameserver change has a long tail even when your own records are on 300 seconds — and why checking the delegation from two resolvers tells you more than watching a clock.
Negative caching: why an outage outlives its fix
Resolvers cache "this name does not exist" the same way they cache addresses, and that cache has its own TTL. RFC 2308 sets it to the smaller of the SOA record's minimum field and the TTL of the SOA record itself — the two numbers this calculator takes. Both arrive in the authority section of the NXDOMAIN answer, so dig SOA example.com hands you them.
This is the number that decides how long a repair stays invisible. In our own June 2026 delegation outage, the registry record was fixed at 17:30 UTC on 30 June, and the domains did not come back for most of the internet until 1 and 2 July: the resolvers people were using were still inside the negative window. Two practical consequences. Do not judge a delegation fix before that window has passed. And do not fix it twice inside the window, which is how a good repair gets replaced by a worse one.
Common TTL values, and what each one is for
| Seconds | Reads as | What it is for |
|---|---|---|
60 | 1 minute | An active migration or a failover record. Every visitor costs a lookup; do not leave it here. |
300 | 5 minutes | The switching TTL. Publish it before a nameserver or host change, and restore afterwards. |
900 | 15 minutes | A cautious default for records you still edit occasionally. Also the negative-cache TTL at several large registries. |
1800 | 30 minutes | Common SOA minimum, which makes it a common negative-cache ceiling. |
3600 | 1 hour | The most common answer to "what should my TTL be" — quick enough to change within a working day, cheap enough to serve. |
14400 | 4 hours | The old cPanel-era default. Still everywhere, and the reason plenty of changes take half a day. |
43200 | 12 hours | Stable records only. An emergency change is half a day behind you. |
86400 | 1 day | MX, TXT and anything you have not touched in a year. Lower it a day before you plan to. |
172800 | 2 days | Typical TTL on the delegation NS records in a TLD zone — set by the registry, not by you. |
604800 | 1 week | The practical ceiling. Beyond this you are relying on caches you cannot reach. |
To read the TTL a resolver is actually holding right now, rather than the one you configured: dig example.com +noall +answer prints it in the second column and it counts down as the cache ages. On Windows, nslookup -debug example.com shows the same field. A TTL far below what you set means someone is serving the record other than you expect; a TTL that never moves means you are reading an authoritative server directly rather than a cache.
// FAQ
What TTL should I set before changing nameservers?
300 seconds, published at least one full old TTL before the change. The publishing order is the part people get wrong: lowering a 24-hour TTL an hour before the cut-over changes nothing, because resolvers holding the old copy will not re-read it for another day. Lower it a day ahead, make the change, wait five minutes for caches to follow, then restore the original value so you are not paying for a lookup on every visit.
How long is a TTL of 3600?
One hour. It is the most common TTL on web records: long enough that most visitors are served from cache, short enough that a change reaches everyone within a working hour. Two other values you will meet often are 14400, which is four hours and was the default in a generation of hosting panels, and 86400, which is one day and belongs on records you do not expect to move.
What is the negative cache TTL, and how is it calculated?
It is how long resolvers remember that a name does not exist. RFC 2308 defines it as the smaller of the SOA record's minimum field and the TTL of the SOA record itself, both of which arrive in the authority section of an NXDOMAIN answer — run dig SOA example.com to read them. It matters because it survives the repair: in our own June 2026 delegation outage the registry record was fixed hours before most resolvers stopped answering NXDOMAIN.
Does lowering the TTL make DNS propagation faster?
Only if you lower it in advance. There is no propagation in the sense of data being pushed around: the registry and your nameservers have the new answer immediately, and what you wait for is resolvers whose cached copy has not expired. A TTL lowered before the change shortens those copies. A TTL lowered at the same time as the change shortens nothing, because the caches you care about are still holding the previous value with its previous lifetime.
Is a very low TTL bad?
As a steady state, yes — a 30-second TTL means nearly every visit costs a DNS lookup, which adds latency for users and load for your nameservers, and it removes the cushion that keeps a site reachable if your DNS provider has a bad ten minutes. As a temporary state around a change it is exactly right. The pattern is lower, change, verify, restore, rather than living permanently at 60 seconds because a migration once needed it.
The TTL that matters is the one in the answer.
One command reads your domain from two public resolvers with the remaining TTL on every record, then checks the zone, the hostname binding and the served content.
$ npm i -g @clize/clize && clize login $ clize domain check example.com[ Agent Domains → ]