TTL (Time to Live) is the time in seconds during which DNS resolvers and browsers cache the answer to a DNS query. Once the TTL expires, the cache is dropped and the client sends a fresh query to the DNS server.

How TTL Works

Example: the A record for example.com has TTL = 3600 (1 hour). A visitor opens the site and their browser asks DNS for the IP. For the next hour that IP stays in the cache. If you change the IP address, the visitor will keep landing on the old server for another hour.

Recommended TTL Values

Record type	Stable TTL	Before migration
A (IP address)	3600 (1 hour)	300 (5 min)
AAAA (IPv6)	3600 (1 hour)	300 (5 min)
CNAME	3600 (1 hour)	300 (5 min)
MX (mail)	86400 (24 hours)	3600 (1 hour)
TXT (SPF/DKIM)	86400 (24 hours)	3600 (1 hour)
NS	86400 (24 hours)	86400 (do not change)

💡 Before a migration: Lower the TTL of all important records to 300 seconds 24–48 hours before the move. After the migration, restore the standard values.

Checking Record TTLs

# Check the TTL of an A record
dig example.com A

# The answer shows the TTL
;; ANSWER SECTION:
example.com.    3600    IN    A    192.168.1.1
#               ^^^^
#               TTL in seconds

Minimum TTL in cPanel

In cPanel (DNS Zone → Simple DNS Zone Editor) the default minimum TTL is 14400 seconds. For faster propagation of changes:

Go to Advanced DNS Zone Editor
Pick the record → edit its TTL
The lowest TTL cPanel accepts is 14400

⚠️ Do not keep the TTL very low permanently: TTL = 60 seconds puts an excessive load on the DNS server and increases page load time for every new visitor.

Symptom	Cause	Fix
A day after an IP change, some users still see the old server	TTL wasn't lowered in advance, so resolvers keep the old record for the full original caching period	Lower the TTL 24–48 hours before the next migration instead of at the moment of the move
cPanel shows TTL 14400 even though 300 was entered in the zone	cPanel enforces its own minimum TTL for the Simple DNS Zone Editor regardless of the entered value	Use the Advanced DNS Zone Editor, which allows setting the exact TTL value
The ISP's resolver serves the old record longer than the declared TTL	Some resolvers round up or extend TTL beyond the authoritative value — RFCs permit this as part of caching behavior, it's not a bug	Build in extra time margin when planning a migration (actual TTL is greater than or equal to the declared one)
After changing TTL from 300 to 86400, propagation is still fast	The new (longer) TTL value only takes effect after the previous, shorter TTL expires — so the effect isn't immediate	This is expected behavior; raise the TTL only after the migration is complete

TTL for CDN and Failover Setups

For schemes with automatic IP failover during an outage (DNS failover), a low TTL isn't a one-time step before a migration — it's a permanent setting.

# Typical configuration for a failover setup
@  A  60  203.0.113.10   ; primary server
@  A  60  203.0.113.20   ; backup server (used by the monitoring system)

A TTL of 60 seconds means that if the primary server goes down, switching to the backup takes up to a minute instead of an hour. For the switching mechanism itself, see the article on DNS failover, and for spreading load across geographically distributed servers, see Anycast and GeoDNS.

When Lowering TTL Will Not Help

The user's ISP resolver forcibly applies its own minimum TTL higher than yours — this happens with some mobile carriers and is outside the domain owner's control
NS records at the parent zone (in the TLD registry) have their own TTL, typically 24–48 hours, independent of the TTL of records inside your zone
Applications and mobile clients cache DNS at the OS or library level regardless of the record's TTL — for example, some Java applications cache DNS "forever" without explicitly setting networkaddress.cache.ttl
Browsers keep their own internal DNS cache (typically 60 seconds in Chrome) on top of the system cache — lowering the record's TTL has no effect on that

SOA Minimum: TTL for Negative Caching

The Minimum field in an SOA record sets the TTL for negative answers — for example, NXDOMAIN, when the requested name doesn't exist. This value is separate from the TTL of ordinary A/MX records and often gets overlooked when configuring a zone.

# Example SOA record
example.com. IN SOA ns1.zevshost.net. admin.example.com. (
  2026093001 ; Serial
  3600       ; Refresh
  900        ; Retry
  1209600    ; Expire
  3600 )     ; Minimum (negative caching)

DNS Provider	Typical SOA Minimum
cPanel (BIND)	3600 seconds
Cloudflare	1800–3600 seconds
Route 53 (AWS)	900 seconds by default

If you deleted a record and expect resolvers to know immediately, what matters is the SOA Minimum, not the record's own TTL: until the Minimum expires, some resolvers may cache the "no such record" answer separately from the previous value.