DNS TTL: Sensible Values for A, MX and TXT Records

TTL is the one field in a DNS record that does nothing as long as nothing changes. It only matters when you want to change something, and by then it’s usually too late to adjust it. That timing problem is what this page is about.

What DNS TTL controls

Every record carries a TTL in seconds. A resolver that fetches the record keeps it for that long, counting down. Two queries a few seconds apart show it:

dig @1.1.1.1 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer

example.com.		3600	IN	A	192.0.2.10
example.com.		3571	IN	A	192.0.2.10

The second answer came from cache 29 seconds later. When the counter hits zero, the resolver asks the authoritative server again. So “TTL 3600” means a change can take up to an hour to reach everyone.

The part people miss: the TTL works on the old value. Whatever TTL you set alongside a new value only helps the change after that.

Recommended TTL values per record type

For a VPS you don’t rebuild every week, 3600 seconds is a reasonable default for almost everything. Going much higher buys little, because common resolver software caps cache lifetime anyway. Unbound, for example, defaults to cache-max-ttl: 86400.

TTL routine before a migration

This is how a planned change goes without a long wait:

1. At least one old TTL in advance, lower the TTL on every affected record to 300. With a TTL of 86400 that means at least 24 hours before the move.
2. Wait until the old TTL has passed. Now no resolver caches the record for longer than five minutes.
3. Change the value to the new IP. Keep the TTL at 300.
4. Check that everything works. If not, switch back, which also takes only five minutes.
5. A day or two later, raise the TTL to 3600 again.

The usual mistake is skipping step 2: lower the TTL and change the IP in the same minute. Every resolver that read the old record a moment earlier still holds it for nearly a day. The full process with two servers running side by side is in server migration without downtime.

TTL in zone files and the SOA record

In a zone file you can set a default TTL for all records that don’t carry their own:

$ORIGIN example.com.
$TTL 3600
@      IN  SOA  ns1.example-dns.net. hostmaster.example.com. (
                2026101801 ; serial
                7200       ; refresh
                3600       ; retry
                1209600    ; expire
                3600 )     ; minimum = negative TTL
@      IN  A     192.0.2.10
@  300 IN  AAAA  2001:db8:10::1
www    IN  CNAME example.com.

Since RFC 2308, the last SOA field is the negative caching TTL: how long resolvers remember that a name doesn’t exist. It bites when you open a subdomain in the browser before creating it. More in DNS propagation time.

With a hosted DNS panel such as the one in the betadomain customer area, you set the TTL per record and never touch $TTL or the SOA.

See every TTL for a domain at once

Before a migration you want to know which records have which TTL. Query the authoritative server, because a resolver only shows you the remaining time:

NS=$(dig NS example.com +short | head -n 1)
for t in A AAAA MX TXT; do dig @"$NS" example.com "$t" +noall +answer; done
dig @"$NS" www.example.com A +noall +answer

The second column is the configured TTL. The highest value among the records you plan to change tells you how early to start lowering them.

What the TTL can’t control

The delegation. Which nameservers serve your domain is recorded in the TLD zone, and the registry sets that TTL. You can still check it:

dig @a.gtld-servers.net example.com NS +norecurse +noall +authority

For .com it comes back as 172800. A nameserver switch can take up to two days, regardless of what’s in your own zone.

Resolvers that bend the rules. Some enforce a minimum TTL, some a maximum, and a few ISP resolvers keep records longer than permitted. That’s why you leave the old server running for a day after a cutover even when the arithmetic says five minutes.

Browser and OS caches. They mostly respect TTLs, but not always. If only your own machine still sees the old IP, the problem isn’t on the server side.

Common TTL misconceptions

“A low TTL makes changes show up faster.” Only if it was already low before the change.

“I’ll set everything to 60 and stay flexible.” It works, but each cache miss costs a lookup. Sensible for a failover setup with health checks, overkill for a single VPS.

“The TTL decides when a record becomes active.” No. The record is live on the authoritative server immediately. The TTL only governs how long old copies survive elsewhere. To create records in the first place, see set an A record, and for mail records, MX record setup.

Take a minute now to look at the TTLs on your important records, before the next migration forces the question. At betadomain they’re adjustable per record in the customer area. If you want a second domain for a staging system, it’s worth a quick search for a free name. A .cloud domain costs €25.99 a year there, and the complete price overview lists every extension with its fixed renewal price.