To move a site or mail to a new server with little downtime, lower the TTL of the records you will change, wait for the old TTL to expire, make the change, and raise the TTL again afterwards. The wait matters: resolvers that cached the record under the old TTL keep it until that time is up, so lowering the TTL and changing the record at the same moment achieves nothing. Check the current value in the DNS lookup, where each record shows its TTL.
The timing rule
Say the A record has a TTL of 86400 seconds (24 hours) and you plan to switch on Saturday at 10:00.
- Thursday 09:00 or earlier: set the TTL to 300 (5 minutes). Resolvers that cached the old record now hold it for up to 24 hours from when they fetched it.
- Saturday 10:00 is more than 24 hours later, so every cached copy is the 300-second version or newer.
- Make the change. Within about five minutes resolvers pick up the new value (see DNS propagation explained for why cache expiry, not propagation, is the delay).
- Verify with the DNS propagation checker.
- After you are sure the new target works, raise the TTL back (see below).
RFC 2181 §8 describes the TTL as “a maximum time to live, not a mandatory time to live”. Some resolvers ignore very short values and apply their own minimum, so allow extra margin rather than planning to the second.
Which TTL to choose
| Value | Use |
|---|---|
| 300 seconds | During a planned change; accepts more query load for quick rollback |
| 3600 seconds | Everyday default for most records |
| 14400 to 86400 seconds | Stable records you rarely change |
These are common choices, not rules. Your DNS host may offer only a subset of values or enforce a minimum, so check its documentation. The trade-off: a low TTL makes changes quick but sends more queries to your name servers and adds a lookup delay for visitors whose resolver cache missed; a high TTL does the reverse and also means a mistake lingers longer.
What to lower
- A and AAAA records for the site, if you are changing hosting.
- MX records, if you are changing mail provider. Old and new MX must not coexist unevenly; see How to set up MX records.
- TXT records for SPF, if you move senders.
- CNAMEs that point at the old platform.
Records you are not changing do not need a lower TTL.
NS and DS: the parent zone sets the clock
Changing name servers is different. The NS records at your registrar are published in the parent zone (for example, the .com zone), and their TTL is set by the registry, not by you. Your own zone also contains NS records for the same domain, with a TTL you do control. Resolvers may hold either copy. RFC 2181 §5.4.1 ranks authoritative data above glue and referral data, which is why mixed answers occur during a change.
Practical consequences:
- You cannot shorten the parent’s NS TTL. Plan for a longer window than for ordinary records, and read the actual value by querying the parent zone’s name servers for your NS set; the figure differs between registries.
- Keep the old name servers answering with correct data until the parent TTL has passed. If the old provider removes the zone early, resolvers that still follow the old delegation get SERVFAIL or empty answers.
- Copy the whole zone to the new provider and compare it before changing NS.
- If DNSSEC is enabled, the DS record at the registrar also lives in the parent zone and has its own TTL. Moving to a provider that signs differently needs the old DS removed or replaced in step with the key change; a stale DS makes validating resolvers return SERVFAIL for the whole domain. Follow your new provider’s documented procedure and keep the old keys published until the DS TTL has passed.
After the move
Wait until the new setup has been correct for a day, then restore the longer TTL. Leaving 300 seconds in place is safe but costs more queries. If anything breaks during the window, the short TTL lets you point back to the old server within minutes, so keep the old server running until you are done.
FAQ
Can I lower the TTL on the day of the change? You can, but it helps only the resolvers that fetch the record afterwards. Copies cached earlier keep the long TTL.
Does a TTL of 0 mean no caching? RFC 1035 §3.2.1 says a zero TTL means the data is for the current transaction only and should not be cached. Many hosts refuse 0; use a small number such as 60 or 300.
How do I find the old TTL? Look up the record in the DNS lookup. A resolver shows the remaining TTL on a cached answer, so query it a few times or ask an authoritative server for the full value.
Sources
- RFC 1035, §3.2.1 RR definitions, Format: https://www.rfc-editor.org/rfc/rfc1035#section-3.2.1
- RFC 2181, §8 Time to Live (TTL): https://www.rfc-editor.org/rfc/rfc2181#section-8
- RFC 2181, §5.4.1 Ranking data: https://www.rfc-editor.org/rfc/rfc2181#section-5.4.1