Glossary

TTL

Controls how long DNS records are cached by resolvers

TTL (Time to Live) is a value in DNS records that specifies how long, in seconds, a resolver or client is allowed to cache that record before it must query the authoritative name server again for a fresh copy.

What is TTL in DNS?

TTL, or Time to Live, is a numerical value present on every DNS record that instructs DNS resolvers how long they may cache that record before considering it expired. TTL is measured in seconds — a TTL of 3600 means the record can be cached for one hour. After the TTL expires, the resolver must query the authoritative name server again to retrieve a fresh copy of the record.

TTL values are set by the domain owner in their DNS zone configuration and apply per-record, meaning different records on the same domain can have different TTL values. A typical A record might have a TTL of 3600 (one hour) or 86400 (one day), while a TXT record used for verification might use a TTL of 300 (five minutes).

TTL is a critical tuning parameter that balances two competing concerns: performance and propagation speed. Higher TTL values reduce DNS query load and speed up resolution for end users (since cached answers are served instantly), but they also mean changes take longer to propagate. Lower TTL values allow changes to propagate faster but increase the volume of DNS queries hitting authoritative servers.

How Does TTL Work?

When a DNS resolver receives a response from an authoritative name server, it stores that response in its cache along with a timestamp and the TTL value. For each second that passes, the cached TTL counts down. When it reaches zero, the resolver discards the cached record and makes a fresh query the next time a client requests that hostname.

Importantly, TTL countdown begins when the record is fetched by the resolver — not when you publish it. If a resolver cached your record 50 minutes ago with a 3600-second TTL, it still has 10 minutes of cache life remaining even if you changed the record 5 minutes ago. This is why DNS changes do not take effect instantaneously worldwide.

A common best practice when planning a significant DNS change — such as migrating to a new server or changing mail providers — is to lower the TTL of the relevant records to 300 seconds (five minutes) several hours or days in advance. Once all resolvers have refreshed with the lower TTL, your change will propagate much faster. After the migration is complete, you can restore the TTL to a higher value.

How to Check TTL Values

You can inspect the current TTL value for any DNS record using the TTL Checker at nslookup.net/tools/ttl-checker. Enter a domain name to see the TTL configured on each of its DNS records, as well as the remaining cache time as seen from different resolvers around the world. This is especially useful when planning a DNS migration, verifying that a TTL reduction has taken effect, or investigating why a DNS change appears to be propagating slowly.

Related Tool

TTL Checker

Try the Tool →

Frequently Asked Questions

What is a good TTL value for DNS records?

For most records, a TTL of 3600 seconds (one hour) or 86400 seconds (one day) is a sensible default that balances caching efficiency with reasonable propagation speed. For records that change frequently or for critical migrations, a TTL of 300 seconds (five minutes) is appropriate. For records that almost never change, such as NS records, TTLs of 86400 or higher are common.

Why is my DNS change not showing up yet?

DNS changes are not instant because resolvers around the world cache records for their full TTL duration. If your previous TTL was 86400 seconds (one day), resolvers that recently cached the old record will continue serving it for up to 24 hours. To speed up future changes, lower the TTL well in advance of the change and then restore it afterward.

Does TTL affect all record types equally?

TTL applies to all DNS record types, but best practices vary. A records and AAAA records often use moderate TTLs (1–24 hours). MX records may use longer TTLs since they change less frequently. TXT records used for verification or SPF might use short TTLs. NS records typically use long TTLs (24 hours or more) since they should be very stable.

What is negative caching TTL?

Negative caching TTL refers to how long a resolver caches a "record not found" (NXDOMAIN or NOERROR/NODATA) response. This is governed by the minimum TTL field in the domain's SOA record. If a resolver queries for a record that does not exist, it caches that negative result for the duration of the negative TTL before querying again, preventing repeated lookups for non-existent records.