In DNS, TTL stands for time to live. It tells a resolver how many seconds it can normally reuse cached DNS data before requesting a fresh answer. A TTL of 300 means five minutes, and a TTL of 3600 means one hour. The number governs DNS caching, not how long a website stays online or how quickly a page downloads.

TTL matters whenever a record might change. A longer value can reduce repeated queries to the authoritative nameservers that publish the records and help a cache answer promptly. A shorter value can make a later edit visible sooner to resolvers that fetch the record after the shorter value is in place. Neither setting gives a guaranteed worldwide cutover time, because cached copies and application behavior vary.

Read TTL Values in Seconds

DNS resource records carry TTL values in seconds. If a lookup displays 300 IN A 192.0.2.10, the 300 is a five-minute TTL for that answer; it is not an HTTP cache header or a five-minute server lease. The example uses an IP address reserved for documentation. DNS interfaces sometimes display the same setting as minutes or hours, so convert units before comparing two screens.

A resource record set, or RRset, groups records with the same owner name, class and type. The authoritative members of an RRset have one TTL value under DNS rules. For example, two A records at the same name are members of one A RRset, while an AAAA record at that name belongs to another set and can have a different TTL. A low TTL for one record type does not automatically lower the TTL for every type at the name.

TTL is a field in the DNS record a resolver receives. Each cache tracks the lifetime of its own copy, so there is no single countdown shared by all users. An authoritative answer may show the configured lifetime, while a cached answer may show a smaller remaining lifetime. Always note which server was queried when reading a number.

Why a Cached TTL Counts Down

A cached TTL counts down as time passes after the resolver receives an answer. Suppose a recursive resolver caches an A RRset with a TTL of 3600 seconds; ten minutes later, it may report roughly 3000 seconds remaining. Another resolver that fetched the same RRset moments ago may still show nearly 3600. Both can have the same record value and different remaining TTLs.

After a cache entry expires, a resolver normally fetches fresh data when it next needs to answer a matching query. It might then receive the same value again, which starts a new caching interval, or receive a changed value from the authority. Seeing a TTL reset does not, by itself, prove that an operator edited the zone.

If the authoritative value changes while a resolver holds the old record, the old cached answer can remain until its lifetime ends. Reducing the authoritative TTL after that resolver fetched the old value does not shorten the lifetime of the copy already in its cache. This is why TTL planning for a future change has to account for the value that was published before the edit, not just the value shown afterward.

A device, browser or application may also cache DNS information or reuse an established connection. A direct query to a recursive resolver and a browser visit therefore need not change at the exact same instant. TTL is a DNS mechanism; it is not a command that closes active connections.

Positive and Negative Answers Have Different TTL Rules

A positive answer supplies the requested records, such as an A or MX RRset, with their TTL. A negative answer can report that a name does not exist (NXDOMAIN) or that the requested record type is absent (NODATA). If the lookup follows a CNAME alias, the negative result can describe the final target rather than the original name. Caching these negative results prevents repeated queries for the same missing information.

An authoritative negative response includes the zone's SOA record, which holds administrative information about the zone. The negative cache lifetime is the smaller of the SOA record's configured TTL and its MINIMUM field; the server puts that smaller value in the SOA record's TTL field in the response. SOA MINIMUM is not the default TTL for every positive record in the zone. A zone file can supply a separate $TTL directive for records without an explicit TTL.

This difference matters when adding a name for the first time. If a resolver recently cached NXDOMAIN for new.example.com, it may continue to say the name is missing even though the new A record has been published by the authoritative servers. The new A record's short positive TTL does not cancel the old negative cache entry. Check the earlier negative answer and its SOA-derived lifetime when that happens.

Balance Cache Reuse and Update Speed

A longer TTL favors cache reuse and lowers the frequency of queries that reach authoritative infrastructure. It can also let an old value persist longer after a change. A shorter TTL increases opportunities for resolvers to fetch a new value, but it can increase DNS query traffic and make users more dependent on the authority being reachable when a cache entry expires. The right number depends on operational needs, not on a universal “best” TTL.

For data that rarely changes, a longer value can be reasonable. For a planned change, an operator may choose a shorter value ahead of time and allow previously cached longer-lived copies to age out before making the underlying edit. Other cached data, especially NS delegations and negative answers, may follow different lifetimes.

Compare the Published and Cached Answers

To investigate a TTL-related delay, compare the exact name and record type at the authoritative server and at the affected recursive resolver. Note which server provided each result, whether the response is positive or negative, and any remaining TTL. A cached address that differs from the published address has a different meaning from a cached answer saying that the name is missing.

If authoritative servers that should publish the same data disagree, investigate their zone updates first. If the resolver shows an old answer with time remaining, its cache can explain the difference. If both DNS answers are new but an application still reaches an old endpoint, inspect local caching or connection reuse.