DNS TTL Calculator

A TTL is a number that quietly decides how fast your changes reach people. Set it too high and a mistaken record lingers for a day; set it too low and your name servers carry needless traffic. The page turns TTLs into plain language, explains what the value implies and then plans the sequence of steps for a migration.

What a TTL is

The time to live is the number of seconds a resolver may keep an answer before asking again. It is stored with each record, so different records of the same name can have different TTLs. Operating systems, browsers and routers cache for no longer than the TTL, though some round it up or down. A record that has been cached with a TTL of one day can stay in a cache for a day after you change it, which is the central fact behind every DNS migration plan.

Entering a value

Type seconds (3600) or a combination of units (1h30m, 2d, 1w), or press one of the quick buttons: 1 min, 5 min, 30 min, 1 h, 4 h, 1 d and 7 d. The result shows the value in seconds, in words (for example “1 hour”) and in BIND notation (1h), plus advice. The advice sorts values into very short (under about 60 seconds), short, moderate (a common choice for records that may change, 300 to 3600 seconds), long and very long, with the trade-off of each in a sentence.

Choosing a value

Short TTLs help when you expect changes: failover records, records behind a load balancer, anything you are about to migrate. Long TTLs reduce lookups and tolerate name server outages, which suits records that almost never change, such as NS and MX at a stable provider. Typical practice is 300 to 3600 seconds for web hosts, a day for MX and NS, and temporary lowering before a planned change. Content-delivery providers often set 60 to 300 seconds and manage the rest themselves.

The change planner

Open “Planning a change” and enter the record’s current TTL and the time you want to make the change. The planner returns four times. Lower the TTL to your target at least one old-TTL period before the change, so every cache has picked up the short value. Make the change at the chosen time. Every cache has the new value one short-TTL period after the change. And a warning of what happens without the first step: the old value may linger until the change time plus the old TTL. Finally it suggests raising the TTL again once you are sure.

A worked schedule

Say a record has a TTL of one day and you want to change it on Tuesday at 14:00, with a TTL of one hour in between. The planner says: lower the TTL to one hour by Monday 14:00; change the record on Tuesday at 14:00; every cache is guaranteed to have the new value by Tuesday 15:00; without lowering first, the old value could remain until Wednesday 14:00; raise the TTL again after Tuesday 15:00. The same sums apply to any other times, shown in your own time zone.

Limits

The plan assumes resolvers respect the TTL they are given. A few ignore very short values or apply a floor, and clients may cache beyond DNS, for example in a browser’s connection pool. Add some margin. The page cannot read your real record’s TTL: use the DNS Lookup to see it. To see whether two large resolvers already agree, use the DNS Propagation Checker.

Related tools

• DNS Propagation Checker shows whether a change has reached two resolvers.
• DNS Lookup displays the TTL a resolver currently reports.
• SOA Lookup shows the negative-caching time of a zone.
• ISO 8601 Duration Calculator converts time spans in another notation.