DNS TTL

DNS TTL is the period a resolver may cache a DNS record before requesting a fresh copy from an authoritative server. TTL stands for Time to Live and is measured in seconds. The value controls how quickly record changes become visible and how often resolvers must query authoritative DNS infrastructure.

How DNS TTL works

Every cacheable DNS record includes a TTL value. When a recursive resolver receives the record, it stores the answer and starts counting down. Requests for the same name and record type can use that cached answer until the timer reaches zero. The resolver then discards or refreshes the entry.

Caching reduces lookup time and limits traffic to authoritative servers. A longer value improves cache efficiency but keeps old answers available longer after a change. A shorter value allows faster refreshes but increases query volume and dependence on authoritative availability.

DNS TTL and propagation

The old TTL determines how long a previous answer can remain cached. Lowering the value at the same moment as an IP address change does not affect copies already stored under the earlier setting. Those entries remain valid until their original timers expire.

For a planned migration, reduce the TTL at least one full previous TTL period before changing the record. Confirm the lower setting is visible from every authoritative nameserver. After older cached copies expire, make the destination change and keep the former service available during DNS propagation.

Choosing an appropriate TTL

Stable records can use longer values because they rarely change. Frequently updated records and services that require rapid failover benefit from shorter settings. The correct choice balances update speed, resolver load, operational risk, and the authoritative provider’s capacity.

• 300 seconds: Useful before migrations, failover events, or controlled testing.
• 3,600 seconds: A practical general setting for records that may change occasionally.
• 14,400 seconds or longer: Suitable for stable records when cache efficiency matters more than rapid updates.

These are operational examples, not universal requirements. Some DNS providers restrict available values, and recursive resolvers may enforce their own minimum or maximum cache periods.

TTL for different DNS records

A, AAAA, CNAME, MX, TXT, and other records can have separate values. Changing the website address does not require lowering unrelated email or verification records. Adjust only the records involved in the planned change unless the DNS platform applies one default to the entire zone.

Delegation data is different. Nameserver changes depend on TTL values published by the parent zone and may also involve cached records from the previous provider. A domain migration should keep both DNS zones synchronized until old delegation data expires.

Negative caching

Resolvers also cache responses stating that a name or record does not exist. The zone’s SOA settings influence this negative cache period. If a hostname was queried before it was created, some users may continue receiving an NXDOMAIN response until the negative entry expires.

Lower negative-cache values before launching new hostnames when possible. Clearing a local cache affects only one device; it cannot remove entries stored by internet providers or public resolvers.

How to check DNS TTL

Use dig, nslookup, or an online DNS tool to query the exact hostname and record type. The returned value shows the remaining cache lifetime when querying a recursive resolver. Repeating the query should show the number decreasing until the resolver refreshes the record.

Query authoritative nameservers directly to confirm the configured value. Compare their answers to detect inconsistent zone data. The Cloudflare TTL documentation explains the relationship between caching, lookup performance, and update timing.

Best practices

Document normal and temporary TTL values. Lower them before planned changes, restore the standard settings after the migration stabilizes, and monitor authoritative DNS health. Avoid permanently low values unless the service needs rapid changes and the DNS provider can handle the resulting query volume.