What Is TTL

Time to Live (TTL) is a setting that tells DNS resolvers how long they should cache information before requesting an update. It determines how quickly changes to your DNS records spread across the internet. Every record in your DNS zone carries a TTL value, measured in seconds, that directly controls the tradeoff between performance and flexibility.

How TTL Works

When a recursive resolver looks up your DNS record, it stores that information for the duration of the TTL. Once that time expires, it checks back with the authoritative DNS server for the latest data.

Here is a simplified example of the TTL lifecycle:

1. A user visits example.com for the first time
2. Their resolver queries the authoritative server and receives the A record with a TTL of 3600 (1 hour)
3. The resolver caches the response and serves it to any subsequent queries
4. After 3600 seconds, the cache entry expires
5. The next query triggers a fresh lookup to the authoritative server

This caching mechanism is fundamental to how DNS scales. Without TTL-based caching, every single DNS query would need to reach the authoritative server, creating massive load on the DNS infrastructure and adding unnecessary latency for users.

TTL in a DNS Record

When you look at a DNS record in zone file format, the TTL appears as the second field:

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

The SOA record for a zone also contains a minimum TTL field that controls how long resolvers cache negative responses (NXDOMAIN). This means TTL affects not only existing records but also how long a resolver remembers that a record does not exist.

Observing TTL with dig

You can use the dig command to watch TTL in action. The TTL value in a response decreases with each query as the resolver counts down until it must refresh:

# First query — TTL starts at the configured value
dig example.com @8.8.8.8
 
;; ANSWER SECTION:
example.com.    3600    IN    A    192.0.2.1
 
# A few minutes later — TTL has decreased
dig example.com @8.8.8.8
 
;; ANSWER SECTION:
example.com.    3412    IN    A    192.0.2.1
 
# Much later — TTL is nearly expired
dig example.com @8.8.8.8
 
;; ANSWER SECTION:
example.com.    47      IN    A    192.0.2.1

To query the authoritative server directly (which always returns the full configured TTL):

dig example.com @ns1.dnscale.eu
 
;; ANSWER SECTION:
example.com.    3600    IN    A    192.0.2.1

Tip: Compare the TTL from a public resolver like 8.8.8.8 with the TTL from your authoritative server to understand how much cache time remains.

Common TTL Values

Different scenarios call for different TTL values. Here is a reference table of typical settings:

For a detailed breakdown of TTL strategies by record type and use case, see DNS TTL Best Practices.

Choosing the Right TTL

Short TTLs (60-300 seconds)

Short TTLs are best when you expect frequent changes or need fast failover:

• During migrations — when switching hosting providers or changing DNS providers, a short TTL ensures resolvers pick up the new IP quickly
• Failover scenarios — services that may need to redirect traffic to a backup server on short notice
• Active development — staging and development environments where DNS records change often
• Pre-change preparation — lower your TTL 24-48 hours before a planned change so the short TTL is in effect when you make the update

The drawback of short TTLs is increased query volume on your authoritative servers, since resolvers must refresh more frequently.

Long TTLs (3600-86400 seconds)

Long TTLs improve caching efficiency and reduce DNS query load:

• Stable records — MX records for email servers that rarely change, NS records for delegation
• Performance optimization — fewer queries mean faster resolution for returning visitors, since the resolver already has the answer cached
• Email authentication — SPF, DKIM, and DMARC records in TXT format are typically static and benefit from long caching
• CAA records — certificate authority policies change infrequently

The risk with long TTLs is that if you need to make an urgent change, users will continue receiving the old record until the TTL expires.

TTL and DNS Propagation

TTL is the primary factor controlling DNS propagation speed. The relationship is direct:

• Higher TTL means slower propagation, because resolvers serve cached data longer before refreshing
• Lower TTL means faster propagation, because resolvers check for updates sooner

It is important to understand that the old TTL controls how long the old record is cached. If your record currently has a TTL of 86400 (24 hours) and you change the IP address, resolvers that just cached the record could serve the old IP for up to 24 hours. This is why the three-phase migration strategy — lower TTL, make the change, restore TTL — is so important.

Tip: Always lower your TTL well before a planned DNS change. If your current TTL is 24 hours, lower it at least 48 hours in advance so all resolvers have picked up the shorter TTL.

TTL Troubleshooting

Changes not appearing

If you updated a record but still see the old value:

# Check what the authoritative server returns
dig example.com @ns1.dnscale.eu +short
 
# Compare with a public resolver
dig example.com @1.1.1.1 +short

If the authoritative server shows the new value but public resolvers show the old one, the change has been made but resolvers are still serving their cached copy. You must wait for the old TTL to expire, or flush your local DNS cache for immediate results on your own machine.

TTL appears different from what you set

Some resolvers enforce minimum or maximum TTL values. For example, a resolver might not cache for less than 30 seconds even if your TTL is set to 0. You can verify your configured TTL by querying the authoritative server directly:

dig example.com @ns1.dnscale.eu

High query volume on authoritative servers

If your query usage is higher than expected, check whether you have records with very low TTLs. Even raising from 60 to 300 seconds reduces query load by roughly 80%.

TTL and Security

TTL plays a role in DNS security. A very short TTL increases the number of queries that reach your authoritative server, which can be relevant during DDoS attacks. Conversely, if an attacker poisons a resolver cache, a long TTL means the poisoned entry persists longer. With DNSSEC enabled, cache poisoning is mitigated because resolvers can validate responses cryptographically.

Managing TTL in DNScale

DNScale lets you set TTL on a per-record basis through the dashboard or via the API. When you create or edit any record — whether it is an A, AAAA, CNAME, MX, or any other type — the TTL field accepts a value in seconds. DNScale's anycast network ensures that once a resolver's cache expires, the fresh record is served from the geographically nearest edge node with minimal latency.

Conclusion

TTL is key to balancing performance and flexibility in DNS management. Short TTLs give you agility at the cost of higher query volume; long TTLs reduce load but slow down changes. Understanding TTL behavior, knowing how to observe it with dig, and planning your TTL strategy around migrations and stability needs are fundamental skills for anyone managing DNS. At DNScale, you can easily configure TTL values per record to match your needs, ensuring smooth and efficient updates for your domains.