How to Configure TTL Settings in a DNS Zone?
Set one sensible zone default TTL, give individual records their own TTL only when they genuinely need a different timer, and keep the SOA negative cache TTL short during change windows so “does not exist” answers do not linger.
For a planned cutover, drop the relevant DNS record TTL, wait one old TTL so caches age out, make the change, verify from authoritative and public resolvers, then restore steady values. That is DNS TTL best practice without drama, and this routine prevents most rollout surprises.
Configuring TTL Settings In A DNS Zone
All TTL work happens on your authoritative DNS, not at the domain registrar’s contact page. Pick the route that matches how you manage your zone today.
- Managed DNS dashboard: Open the zone. There is usually a “Default TTL” for the whole zone, a “TTL” field on each record row, and an SOA section where the negative cache TTL lives.
- API or infrastructure as code: Each record payload has a ttl field in seconds. Many providers also expose an SOA or zone resource with a negative_ttl or nxdomain_ttl field.
- BIND style zone files: The $TTL directive at the top sets the zone default. The last number in the SOA record is the negative cache TTL. Any record line can include its own TTL before the class and type to override the default.
I keep a new zone at a 3600 second default, then override only the handful of records that benefit from faster pivots.
Set Zone Default TTL
Think of this as the baseline timer for records that do not specify their own TTL.
- Provider UI: Open zone settings, find “Default TTL” or “Zone TTL”, enter seconds, save.
- API or IaC: If the provider supports a zone level default, set it there. If not, rely on per record TTLs.
- BIND file: Put $TTL at the top of the file.
BIND snippet:
$TTL 3600
@ IN SOA ns1.example.com. hostmaster.example.com. (
2025092501 ; serial
3600 ; refresh
900 ; retry
1209600 ; expire
300 ) ; negative cache TTL
That first line means any record without an explicit value inherits a DNS TTL of 3600 seconds. Simple, predictable, and easy to reason about.
Set Per‑Record TTL Overrides
Use overrides only for records that actually need a different caching behavior. This is where DNS record TTL shows up.
- Provider UI. Edit the record, change the TTL field, save.
- API or IaC. Set ttl on the record resource or payload.
- BIND file. Place the TTL number right before the class and type on the record line.
Examples:
@ 3600 IN A 203.0.113.10
www 300 IN CNAME app.example.net.
api 60 IN A 203.0.113.20
Here, the apex sticks with a one hour habit, the www CNAME refreshes every five minutes, and the api A record refreshes every minute.
That keeps stable names cheap to serve and hot paths nimble.
Set SOA Negative Cache TTL
This controls how long recursive resolvers remember negative answers like NXDOMAIN. It matters during changes where labels are added or removed.
- Provider UI: In SOA or Advanced zone settings, look for “Negative cache TTL” or “Minimum TTL”, set seconds, save.
- API or IaC: Use the zone or SOA resource field named negative_ttl or nxdomain_ttl.
- BIND file: The last numeric field in the SOA block is the negative cache TTL.
Keep it short during change windows, for example 300 seconds. Outside of those windows, 300 to 600 seconds is a healthy steady value.
This keeps DNS cache TTL for non existent names from sticking longer than necessary.
Change TTL For A Planned Cutover
This is the repeatable sequence that avoids cache surprises.
- Identify only the records that will change. There is no benefit in lowering TTLs across the entire zone if two labels move.
- Lower TTL on those records to 60 to 300 seconds. If labels might be created or removed, set the SOA negative cache TTL to about 300 for the change window.
- Wait one full previous TTL. If the old TTL was 3600 seconds, give it an hour. That lets existing caches expire naturally.
- Apply the change. Update the A or AAAA value, flip a CNAME target, or create or remove the label.
- Verify. Check the authoritative answer first, then ask a couple of public resolvers. Confirm the value and that the TTL is counting down.
- Restore steady values. Keep long lived records at higher TTLs again and leave only the truly dynamic labels short.
I keep this exact list in runbooks. It is the core of TTL in DNS that teams can follow without second guessing.
Apply TTL In Provider Dashboards
The labels differ a little by vendor, but the clicks are similar.
- Zone default TTL. Zone settings page. Field named Default TTL or Zone TTL. Enter seconds such as 3600. Save.
- Per record TTL. Records list. Edit the desired record. Field named TTL. Enter seconds. Save.
- SOA negative cache TTL. Advanced or SOA section. Field named Negative cache TTL or Minimum TTL. Enter seconds such as 300. Save.
This quick pass touches the three knobs that actually change behavior.
Applying TTL Using Terraform Or Other APIs
Most providers expose ttl at the record level and a negative TTL at the zone or SOA level.
Terraform example for Route 53:
resource "aws_route53_record" "api" {
zone_id = "Z123456EXAMPLE"
name = "api.example.com"
type = "A"
ttl = 60
records = ["203.0.113.20"]
}
Generic REST style:
POST /zones/example.com/records
{
"name": "www",
"type": "CNAME",
"content": "app.example.net.",
"ttl": 300
}
If SOA tuning is available through API, expect a zone level endpoint with a field such as negative_ttl or nxdomain_ttl.
Apply TTL In BIND‑Style Zone Files
BIND shows all three levers in one file.
- Set the zone default with $TTL at the top.
- Use the last field of the SOA for the negative cache TTL.
- Place numeric TTLs on specific records that need overrides.
Example:
$TTL 3600
@ IN SOA ns1.example.com. hostmaster.example.com. (
2025092501 ; serial
3600 ; refresh
900 ; retry
1209600 ; expire
300 ) ; negative cache TTL
@ IN A 203.0.113.10
www 300 IN CNAME app.example.net.
api 60 IN A 203.0.113.20
mail 3600 IN MX 10 mx1.example.com.
Remember to increment the SOA serial when changing the file so secondaries pick up the update.
Verify TTL And Propagation
Two views matter. Authoritative shows what your zone serves right now. Public resolvers show what the world has cached.
Authoritative check:
dig @ns1.example.com www.example.com A +noall +answer +ttlunits
Public resolver checks:
dig www.example.com A +noall +answer +ttlunits
dig @1.1.1.1 www.example.com A +noall +answer +ttlunits
dig @8.8.8.8 www.example.com A +noall +answer +ttlunits
Look for the correct answer and a TTL that counts down. If a newly created label still returns NXDOMAIN from a public resolver for a short time, that is the earlier negative answer still inside its timer.
Try a different resolver or wait for the SOA negative TTL to expire.
