A DNS TTL is the number of seconds a resolver may keep reusing a cached answer without asking your DNS server again. Use 3600 seconds (one hour) or more for records that rarely change; before a migration, lower the TTL to 300 at least one old TTL ahead of the switch, so a full day ahead if it was 86400. Lowering it at the moment you change the IP does not help: on our test bench such a record kept returning the old address for another 59 minutes 53 seconds.
How we tested
On 10 November 2026 we ran an authoritative BIND 9.18.39 server and three caching resolvers in an isolated Ubuntu 24.04 container: Unbound 1.19.2 with default settings, a second Unbound with forced TTL limits (at least 300 and at most 900 seconds), and dnsmasq 2.91 acting as a home router. We changed records with nsupdate, queried the resolvers every 5 to 10 seconds and logged the address and remaining TTL; the longest scenario ran for 67 minutes. Rules come from RFC 1035, 2181, 2308 and 8767; public service limits from Google, Cloudflare and NLnet Labs documentation (checked 10.11.2026). These are test bench results, not measurements on RichHost servers.
What a TTL actually controls
A TTL (time to live) is set per record set: all A records of one name share one TTL, while the MX of the same domain can have another. RFC 2181 defines it as a whole number of seconds from 0 to 2147483647. Three points are often misunderstood.
- The countdown starts when a resolver asks, not when you make the change. A resolver that fetched the record at 10:00 with TTL 3600 keeps it until 11:00; another that asked at 10:40 keeps it until 11:40. That is why a change “applies” at different times for different people.
- Caches in a chain do not add up. Your browser, operating system, router and ISP resolver may all sit between you and the DNS server. On the bench the router (dnsmasq) asked the resolver 40 seconds after it had cached a record with TTL 120 and received the remaining 80, not 120. After the change both switched in the same second.
- The SOA minimum field is not the default TTL. It was in RFC 1035, but since RFC 2308 it sets the negative caching time. The default TTL in a zone file comes from the
$TTLdirective or the TTL field in your control panel.
How these caches together decide the wait after any DNS change is measured separately in our article on DNS propagation time. This one is about which number to set and when to change it.
Which TTL to use for each record type
| Record | Normal TTL | Before changes | What to consider |
|---|---|---|---|
| A, AAAA, CNAME of the site | 3600 | 300 | IP change during a move; Cloudflare’s Auto equals 300 |
| MX | 3600-14400 | 300 | Until the old TTL runs out some mail goes to the old server, so it must keep accepting mail |
| TXT for SPF and DMARC | 3600 | 300 | Add a new sending service to SPF before you start sending from it |
| TXT for DKIM | 3600 | not needed | Publish a new key under a new selector in advance and do not query it before it exists |
| NS and glue | 86400 | will not help | The delegation TTL in the registry zone applies (.com 172800), not yours |
| SOA (TTL and minimum) | 3600 and 300-3600 | 300 for minimum | The lower of the two sets how long “no such record” is cached |
A permanently low TTL does not make a site faster: every N seconds every resolver asks your DNS server again, and a visitor whose cache has expired waits for an extra lookup. A very high TTL makes any urgent change slow. A sensible middle ground for most sites is 3600 normally and 300 for a few days around a move. Mail record order is covered in our SPF, DKIM and DMARC setup guide.
NS records are a separate case: resolvers take the delegation cache time from the parent zone, so the TTL in your own zone barely matters. The switch itself is described in how to change domain nameservers.
Lower, switch, raise back: the bench test
We took two records with TTL 3600 and the same address. The resolver cached both at 15:12:10. At 15:12:20 the late record got a new IP and a TTL of 300 at the same time, as people often do at the last minute. The plan record only had its TTL lowered to 300; its IP was changed an hour later, at 16:12:43. In the output R1 is Unbound with defaults, R2 is Unbound with 300/900 limits, and the number in brackets is seconds since the change.
15:12:10 R1 late.lab A NOERROR 192.0.2.10 3600 15:12:10 R1 plan.lab A NOERROR 192.0.2.10 3600 15:12:20 nsupdate: late.lab A 198.51.100.20 TTL 300; plan.lab A 192.0.2.10 TTL 300 15:27:04 R2 late.lab A NOERROR 192.0.2.10 6 15:27:15 R2 late.lab A NOERROR 198.51.100.20 300 (+895 s) 16:12:03 R1 late.lab A NOERROR 192.0.2.10 7 16:12:13 R1 late.lab A NOERROR 198.51.100.20 300 (+3593 s) 16:12:13 R1 plan.lab A NOERROR 192.0.2.10 300 16:12:43 nsupdate: plan.lab A 198.51.100.20 TTL 300 16:17:06 R1 plan.lab A NOERROR 192.0.2.10 7 16:17:16 R1 plan.lab A NOERROR 198.51.100.20 300 (+273 s)
The record whose TTL was lowered together with the change reached the new server after 59 minutes 53 seconds: the resolver honestly waited out the old 3600 seconds. The prepared record switched 4 minutes 33 seconds after the IP change. The resolver capped at 900 seconds moved late after only 14 minutes 55 seconds, so in real life some visitors see the new site earlier and some later, and the old server must keep running until the longest TTL has expired.
The working plan:
- Check the current TTL:
dig +norec @ns1.your-dns.example example.com A. That number is your minimum lead time. - Lower the TTL to 300 one old TTL plus a margin ahead: 2 hours ahead for 3600, one to two days ahead for 86400.
- Check public resolvers:
dig @8.8.8.8 example.comshould show a TTL of 300 or less. - Change the IP or MX. Keep the old server running for at least another day: resolvers with their own rules exist.
- After 1 or 2 days, raise the TTL back to 3600 or more.
Moving files, the database and mail step by step is covered in how to move WordPress to another host.
Resolvers that rewrite your TTL
The specification lets resolvers limit TTLs, and they do. By default Unbound keeps nothing longer than a day (cache-max-ttl 86400) and no negative answer longer than an hour; an operator can also set a floor with cache-min-ttl, although the Unbound documentation warns that values above an hour or so lead to cached data that no longer matches the real data. Here is what the two resolvers returned for the same records:
| TTL in the zone | Unbound defaults | Unbound with 300/900 limits |
|---|---|---|
| 0 | 0, new address from the first query after the change | 300, old address for another 4 min 58 s |
| 30 | 30, switched after 27 s | 300, old address for another 4 min 58 s |
| 3600 | 3600 | 900 |
| 172800 | 86400 | 900 |
| negative 120 | 120 | 300 |
| negative 86400 | 3600 | 900 |
Public services have limits too. The Google Public DNS FAQ (updated 06.11.2026) says TTLs are generally limited to six hours even if the actual TTL is longer. Cloudflare as a DNS host does not accept less than 60 seconds (30 on Enterprise) or more than a day, and proxied records always get 300. The takeaway: a TTL below 60 to 300 seconds does not guarantee a faster switch, and a TTL above 6 hours will be cut short in part of the world anyway.
Negative caching: a record that did not exist yet
If someone queried a name before you created it, the resolver remembers the answer “no such name” (NXDOMAIN) or “the name exists but has no record of this type” (NODATA). Under RFC 2308 that time is the lower of two numbers: the TTL of the SOA record itself and its minimum field. BIND already puts the computed value into the negative answer:
dig @127.0.21.10 new.neg1.lab +norec (SOA TTL 3600, minimum 300) status: NXDOMAIN neg1.lab. 300 IN SOA ... 1 7200 3600 1209600 300 dig @127.0.21.10 new.neg2.lab +norec (SOA TTL 120, minimum 3600) status: NXDOMAIN neg2.lab. 120 IN SOA ... 1 7200 3600 1209600 3600 15:12:21 R1 new.neg2.lab A NXDOMAIN SOA-ttl 120 15:12:26 nsupdate: add new.neg1.lab A, new.neg2.lab A, www.neg1.lab AAAA 15:14:26 R1 new.neg2.lab A NOERROR 198.51.100.20 300 15:17:24 R1 new.neg1.lab A NOERROR 198.51.100.20 300 15:17:24 R1 www.neg1.lab AAAA NOERROR 2001:db8::20 3600
A new record in the zone with a negative TTL of 120 appeared after 2 minutes; in the zone with 300, after 4 minutes 58 seconds. NODATA behaves the same way: when we added an AAAA record to an existing name, the IPv6 address only appeared once the negative cache expired. RFC 2308 suggests one to three hours as a sensible default, but if you often add subdomains or publish TXT records to verify services, a minimum of 300 is more practical. How to tell such a cache from a truly missing record is shown in our DNS_PROBE_FINISHED_NXDOMAIN fix. One more trap: the resolver with a floor raised the 120 second negative TTL to 300.
Browser and operating system caches
There are two more layers between you and the resolver. Chromium keeps addresses from the system resolver for 60 seconds and, with its built-in resolver, follows the TTL with a one minute minimum (as explained by Eric Lawrence, 2022). Clear it with the Clear host cache button at chrome://net-internals/#dns; Firefox has a button at about:networking#dns. The OS cache follows TTLs too: on Windows ipconfig /displaydns shows the remaining TTL of each entry, and on Linux with systemd-resolved resolvectl flush-caches clears it. These caches are short and rarely cause hour-long delays; the real delay comes from your ISP or a public resolver, which you cannot flush from your computer.
If X, do Y
| Situation | What to do |
|---|---|
| Moving in a week, TTL is 86400 now | Lower A and MX to 300 today, switch no earlier than a day later |
| Moving tomorrow, TTL is 86400 | Lower it now and postpone the switch by a day; if you cannot, keep the old server working for another day |
| Changing the mail server | MX 300 in advance; the old server keeps accepting mail for the old TTL, then check nothing is left there |
| Adding a new email sending service | Update SPF first, send from the new service no earlier than one TXT TTL later |
| Rotating a DKIM key | Publish the new selector a day before switching, remove the old one a week later |
| Creating subdomains often | SOA minimum 300, and do not test a name before the record exists |
| Changing nameservers | Record TTLs will not help; wait for the delegation TTL in the registry zone |
| Records never change | 3600 to 86400 for A and MX, 86400 for NS |
| Want TTL 0 or 10 “for speed” | Use at least 60: a resolver with a floor will raise the value anyway |
If you are moving a site to hosting with our own control panel and its AI assistant, such as RichHost plans, lower the TTL at your old DNS provider before you start copying files: by the time the transfer is done, the old value will have expired.
FAQ
I lowered the TTL to 300, so why did the change still take an hour?
Resolvers had cached the record with the old TTL of 3600 and keep it until it expires. They only see the new value on their next query. Lower the TTL one old TTL before the change.
Can I set a TTL of 0?
Yes, and default Unbound then does not reuse the answer from cache. But on our bench a resolver with a floor kept serving such a record for 300 seconds after the change, and some DNS hosts do not allow less than 60.
How do I see how long the old answer will live?
Ask the resolver in question, for example dig @8.8.8.8 example.com: the number in the second column is the TTL remaining in its cache. The record’s real TTL shows when you query your own DNS server with +norec.
Does TTL affect site speed?
Barely. A visitor makes an extra DNS lookup at most once per TTL, and the browser caches it. For a typical site the difference between 300 and 3600 is hardly noticeable, so 3600 is a perfectly normal value in quiet times.
Should I raise the TTL back after the move?
Yes, after 1 or 2 days, once you are sure you will not need to roll back. Leaving 300 forever does no harm, but it adds queries to your DNS server and gains nothing.
