Reference guide
What is the TTL of a DNS record?
The TTL is how long the rest of the internet is allowed to hold on to your answer. It is what makes a DNS change instant for some people and invisible for a whole day to others.
7 min readUpdated September 12, 2026
In short
The TTL, or time to live, is a number of seconds attached to every DNS record. It says how long a resolver may reuse the answer without asking again. A short TTL makes changes fast and multiplies queries; a long TTL does the reverse. And lowering a TTL only takes effect once the old value has finished expiring.
What the TTL is for
DNS would not survive without caching. If every visit to a site triggered a full query up to the authoritative servers, those servers would buckle and every page would take half a second longer to open. The TTL is the contract that runs that cache: you, the zone owner, tell the rest of the world how long it may rely on an answer before asking again.
That contract has one consequence people always underestimate: when you change a record, nobody is told. Resolvers holding the old value keep it until its TTL runs out, then ask again. In that window, part of the internet sees the old answer and part sees the new one, and both are right.
Hence the only rule that matters: set the TTL before the change, not during it. And because the old value still governs caches the moment you edit it, the lowering itself takes a full TTL to bite.
TTL values and what they really do
Pick a TTL against the repair time you are willing to accept, not against an abstract best practice. Here is what each common value buys you and what it costs.
| Value | Duration | What it allows | What it costs |
|---|---|---|---|
| 60 | 1 minute | A near-instant switchover, useful for the few hours of a migration. | A large number of queries and no tolerance: if your DNS servers go down, the domain disappears within a minute. |
| 300 | 5 minutes | The working value during a migration: short enough to fix fast, long enough to absorb a brief incident. | Frequent queries. Fine for a few days, not as a permanent setting. |
| 3600 | 1 hour | The usual compromise in normal operation, for addresses and mail servers. | A mistake stays visible for up to an hour after it is fixed. |
| 14400 | 4 hours | Few queries, for a zone that rarely moves. | Half a working day lost when a value is wrong and nobody notices early. |
| 86400 | 24 hours | The default in many interfaces. Suits what never changes. | A mistake stays in circulation for a whole day, including during a launch. |
| 604800 | 7 days | Reserved for frozen records, such as an ownership verification. | Any correction becomes a week-long affair. |
A value of zero asks for no caching at all. It exists, it works, and it turns every visit into a full query: keep it for very short, supervised switchovers.
Check your own domain, right now
Enter a domain name: the tool shows its nameservers and the time to live announced on each answer.
The schedule for a migration without downtime
Five moments, and one trap: lower the TTL early enough for the old value to finish expiring everywhere.
- 1
Lower the TTL, at least one old TTL in advance
If the record sits at 24 hours, lower it more than 24 hours before the switch. Otherwise the caches still holding the old value never see the new duration.
86400 → 300
- 2
Wait for the old duration to elapse
Nothing changes for visitors while you wait. This is the time it takes for every resolver to ask again and pick up the short
TTL. - 3
Change the record
The switch now spreads at the speed of the short
TTL. If something goes wrong, rolling back takes the same time — which is the whole point. - 4
Check from several networks
A result seen from one machine proves nothing: it may be coming out of a local cache. Get the new value from at least two different resolvers.
- 5
Raise the TTL again
Once the switch is confirmed, put a normal value back. Leaving a one-minute
TTLin place for good makes the domain fragile and buys nothing.300 → 3600
The negative cache, the one people forget
An answer saying this name does not exist gets cached too. That explains the most maddening sequence in the trade: you create a subdomain, you test it straight away, it does not exist — and it goes on not existing for hours while the record sits right there.
That duration does not come from the TTL of the record you just created, which did not exist when the question was asked. It comes from the zone's start of authority record, the SOA, which holds the zone-wide parameters. Simplified interfaces do not always show it, but it is the one that decides.
The practical consequence fits in one sentence: do not test a name before you create it. One query made too early is enough to park that absence in your own resolver's cache for the full negative caching period.
The most expensive TTL mistakes
The TTL was lowered on the morning of the migration
What causes it: The lowering is itself governed by the old duration: resolvers holding the 24-hour value will not come back for it before that day is up.
What fixes it: Schedule the lowering at least one full old duration before the switch. It is the one step you cannot catch up on the day.
The newly created subdomain stays unreachable
What causes it: Someone queried it before it existed, and the negative answer is now parked in caches for the duration the zone sets.
What fixes it: Wait for the negative cache to expire, or test from a resolver that has not yet asked the question. Create first, test second.
Every record sits at one minute permanently
What causes it: A past migration left the values low and nobody raised them again.
What fixes it: Put a normal value back. A very short
TTLleaves the domain hanging on its nameservers being up every second of the day.Changing nameservers takes two days
What causes it: The delegation is not served by your zone but by the extension's registry, on a
TTLyou do not set and that often runs to tens of hours.What fixes it: Keep both DNS hosts live and in sync right through the switch, rather than betting on fast propagation.
The questions that come next
Does the TTL slow my site down?
Indirectly, and barely. A very short TTL makes a new visitor's browser wait for a full resolution more often, which costs tens of milliseconds. It only becomes a performance question at extreme values.
Can caches be purged on demand?
Not globally: nothing exists for telling the whole world to forget an answer. A few large public resolvers offer a form to flush theirs, which only settles their share of the traffic.
Is my TTL always honoured?
Not exactly. Some resolvers apply a floor or a ceiling to what they agree to keep. The TTL is a serious and widely followed request, not a guarantee to the second.
What TTL should mail records use?
An hour suits normal operation. These records rarely change, but when they do you pay for the mistake in lost messages: better to be able to fix it within the hour than within the day.
The TTL decides how long your outages last
A wrong record with a 24-hour time to live stays wrong for 24 hours, even after you fix it. DomainVigil re-reads the records on every domain you own each day and emails you the moment a value changes, so the repair can start at once.
Start for freeFive domains free, forever. No card required.
The other reference guides
- SPF: the list of servers allowed to send mail as your domain
- DKIM: the signature that travels with the message
- DMARC: the rule that says what to do when SPF and DKIM fail
- DNSSEC: signed DNS answers, and what it costs when they break
- CAA: the list of authorities allowed to issue your certificates
- A and AAAA: the two ways of saying where a name lives
- CNAME: the DNS alias, and the four things it cannot do
- MX: where a domain's mail goes, and in what order
- WHOIS and RDAP: reading a domain's registration record
- The certificate chain: three links, and the one people forget
- HSTS: forcing HTTPS, and the trap on the way back