DNS TTL Best Practices

TTL (Time to Live) controls how long DNS resolvers cache your records before checking for updates. Setting the right TTL is a balance between performance (longer caching = fewer queries) and agility (shorter caching = faster changes). This guide covers recommended TTL values for common scenarios.

TTL Basics

TTL is specified in seconds. When a resolver caches a record, it serves the cached version for the TTL duration, then fetches a fresh copy from the authoritative server.

example.com.  3600  IN  A  192.0.2.1
              ^^^^
              TTL: 3600 seconds = 1 hour

For a deeper explanation, see What Is TTL.

Recommended TTL Values

Quick Reference by Record Type

By Stability

By Use Case

TTL Strategy for DNS Migrations

When migrating DNS providers, changing IPs, or moving infrastructure, follow this three-phase approach:

Phase 1: Lower TTL (24-48 Hours Before)

Reduce the TTL to 300 seconds (5 minutes) well before the change. You must wait for the old TTL to expire before the new low TTL takes effect globally.

# If current TTL is 86400 (24h), lower it 48 hours before the change
example.com.  300  IN  A  192.0.2.1    ; old IP, low TTL

This is the most commonly skipped step, and skipping it is the most common cause of extended DNS migration issues. If your current TTL is 86400 and you change the IP without lowering it first, some resolvers will serve the old IP for up to 24 hours.

Phase 2: Make the Change

Update the record to the new value. With a 300-second TTL, most resolvers will pick up the change within 5 minutes.

example.com.  300  IN  A  198.51.100.1  ; new IP, still low TTL

Phase 3: Restore TTL (After Verification)

Once you've confirmed authoritative answers are correct, key recursive resolvers have refreshed, and everything is working, increase the TTL back to its normal value.

example.com.  3600  IN  A  198.51.100.1  ; new IP, normal TTL

Migration TTL Timeline Example

Here is a concrete timeline for migrating an A record from one server to another:

Common TTL Mistakes

TTL Too Long for Dynamic Infrastructure

Setting a 24-hour TTL on an A record that might need to change quickly means you can't respond to outages or IP changes for up to a day.

Fix: Use 300-3600 seconds for records that might change.

TTL Too Short for Stable Records

A 60-second TTL on MX records that haven't changed in years generates unnecessary DNS queries, increasing load on your authoritative servers and slightly increasing latency for users. It also increases your query usage and potentially your bill.

Fix: Use 3600-86400 seconds for stable records.

Not Lowering TTL Before a Migration

Making a DNS change with an 86400-second TTL means some users won't see the change for up to 24 hours. If the old server is already down, those users experience an outage.

Fix: Always lower TTL 24-48 hours before planned changes.

Setting TTL to 0

A TTL of 0 tells resolvers not to cache the record at all. While this gives you maximum control, it means every single DNS query hits your authoritative server, which:

• Increases query load significantly
• Makes your domain dependent on authoritative server uptime for every request
• Adds latency to every page load
• Works against the benefits of anycast distribution by preventing caching

Fix: Use 60-300 seconds instead of 0. Even 60 seconds of caching dramatically reduces query volume.

Misunderstanding Negative TTL

The SOA record's minimum field controls how long NXDOMAIN (non-existent domain) responses are cached. Setting this too high means that after you create a new subdomain, some resolvers will continue returning NXDOMAIN until the negative cache expires.

Fix: Keep the SOA minimum between 300-900 seconds. DNScale manages this automatically as a system record.

TTL and DNS Propagation

TTL directly affects DNS propagation time. The relationship is straightforward:

• Higher TTL -> slower propagation (resolvers serve cached data longer)
• Lower TTL -> faster propagation (resolvers refresh sooner)

But TTL isn't the only factor — some resolvers enforce minimum/maximum cache durations regardless of your TTL setting. Most major public resolvers (Google, Cloudflare, Quad9) respect TTL accurately.

TTL and Performance

Caching Reduces Latency

When a resolver has your record cached, it responds instantly without querying your authoritative server. Longer TTLs mean more cache hits:

TTL 300:   Resolver queries authoritative every 5 min
TTL 3600:  Resolver queries authoritative every 1 hour
TTL 86400: Resolver queries authoritative every 24 hours

For a frequently visited website, a 1-hour TTL means the resolver queries your authoritative server once per hour per record per resolver. A 5-minute TTL means 12 times per hour.

Impact on Authoritative Server Load

Lower TTLs = more queries hitting your authoritative servers. With DNScale's anycast network, this is less of a concern since queries are distributed across multiple edge nodes, but it's still worth considering for very high-traffic domains. It also directly affects your query usage and billing.

TTL for Specific Scenarios

E-Commerce / Business-Critical Sites

example.com.       3600   A     192.0.2.1      ; 1 hour
www.example.com.   3600   CNAME example.com.   ; 1 hour

1 hour balances fast recovery with good caching. During planned maintenance, lower to 300.

SaaS Applications

app.example.com.   900    CNAME myapp.cloud.    ; 15 minutes
api.example.com.   300    A     203.0.113.10    ; 5 minutes

Shorter TTLs for services where you might need to fail over quickly.

Email Records

example.com.       86400  MX    10 mail.example.com.   ; 24 hours
example.com.       86400  TXT   "v=spf1 ..."          ; 24 hours
_dmarc.example.com. 86400 TXT   "v=DMARC1; ..."       ; 24 hours

Email records rarely change. Long TTLs reduce unnecessary queries.

During Active Development

dev.example.com.   60     A     192.0.2.50     ; 1 minute
staging.example.com. 300  A     192.0.2.51     ; 5 minutes

Low TTLs for environments where you're actively changing infrastructure.

Multi-Provider DNS

When running a multi-provider DNS deployment, keep TTLs consistent across all providers. Mismatched TTLs between providers can cause resolvers to cache records for different durations depending on which provider they queried, leading to inconsistent behavior.

Managing TTL in DNScale

Dashboard

When creating or editing a record, set the TTL field to your desired value in seconds.

API

# Create a record with a specific TTL
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "www",
    "type": "A",
    "content": "192.0.2.1",
    "ttl": 3600
  }'
 
# Update the TTL for migration preparation
curl -X PUT "https://api.dnscale.eu/v1/zones/{zone_id}/records/{record_id}" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "ttl": 300
  }'

Infrastructure as Code

Both Terraform and DNSControl support per-record TTL settings, making it easy to enforce consistent TTL policies across your zones.

Related Topics

• What Is TTL — TTL fundamentals
• DNS Propagation Explained — how TTL affects propagation
• How to Flush DNS Cache — clear cached records locally
• What Is an SOA Record — SOA minimum TTL controls negative caching
• Understanding DNS Query Usage — how TTL impacts query volume and billing
• DNS Record Types — all record types and their typical TTLs

Conclusion

Getting TTL right is one of the simplest ways to improve your DNS reliability. Use longer TTLs for stable records to maximize caching, shorter TTLs for dynamic services, and always lower TTL before planned changes. With DNScale, you can adjust TTL per-record through the dashboard or API to match each record's specific needs.