DNS TTL Guide for BIND Zone Files

Use TTLs intentionally before, during, and after DNS changes

A DNS TTL, or Time To Live, tells recursive resolvers how long they may cache a DNS answer. In a BIND zone file, TTLs affect how quickly clients see record changes after cached answers expire. They do not force existing caches to update immediately.

Default TTL with $TTL

The $TTL directive sets the default TTL for records that do not specify their own value:

$TTL 3600
@       IN  A     192.0.2.20
www     IN  A     192.0.2.21

Both records above inherit a TTL of 3600 seconds, or one hour.

Record-Specific TTLs

You can override the default TTL for a single record by placing the value before the class:

$TTL 3600
@       IN  A     192.0.2.20
www 300 IN  A     192.0.2.21

The apex A record uses the one-hour default. The www record uses 300 seconds.

Planning a Migration

Lower TTLs before a planned change, wait at least the old TTL, make the change, then raise the TTL again after the new records are stable. If a record currently has a TTL of 86400 seconds, lowering it five minutes before a migration will not help clients that already cached the old answer for a full day.

Use Case	Typical TTL	Reason
Stable website record	`3600` to `14400`	Balances cache efficiency and reasonable change speed.
Active migration window	`300`	Allows faster rollback or cutover after caches age out.
Very stable NS or MX target	`3600` to `86400`	These usually change less often, but avoid extreme values if operations are immature.
Testing a new record	`60` to `300`	Useful for short-lived experiments, but not ideal as a permanent default.

Negative Cache TTL

The final SOA field is commonly described as the negative cache TTL. It affects how long resolvers may cache negative answers such as NXDOMAIN, depending on the SOA TTL behavior of the authoritative server and resolver. If you create a record that previously did not exist, some clients may continue seeing the negative answer until that cache expires.

What named-checkzone Validates

named-checkzone can tell whether TTL values are syntactically valid. It cannot tell whether a TTL is operationally appropriate for your migration plan. Treat TTL choice as part of the deployment process, not just zone file syntax.

Changed TTLs in a zone file? Validate the file before loading it into BIND.

Open the Validator