What Does DNS TTL Mean?

Every DNS record has a TTL, the number such as 300 or 3600 that you set next to the record at your DNS provider. TTL stands for time to live. It tells DNS resolvers, the services that look up names for people's devices, how many seconds they may cache the record before they ask the domain's authoritative DNS server, the one that holds its records, for a fresh copy. The DNS specification defines TTL as this cache lifetime.

TTL matters whenever you change DNS, for example when you move hosting, replace a server, test failover or switch email providers. A short TTL gets new answers to users sooner. A long TTL means fewer repeated lookups.

How TTL works

When someone opens www.example.com, their device asks a recursive resolver for the domain's DNS record. That resolver is usually run by their internet provider, their company, a public DNS service or their local network.

If the resolver already has a usable answer in its cache, it returns that answer without contacting the authoritative server. The TTL counts down while the answer sits in the cache. When it reaches zero, the resolver normally fetches a fresh answer.

Say a website's A record points to 192.0.2.10 and has a TTL of 3,600 seconds, which is one hour:

• At 12:00, a resolver fetches the record and caches it.
• At 12:15, the owner changes the address to 192.0.2.20.
• At 12:30, the resolver still answers 192.0.2.10. Its cached copy has about 1,800 seconds left.
• Around 13:00, the cached copy expires. The next lookup fetches the record again and gets 192.0.2.20.

The change at 12:15 does not touch the copies that resolvers already hold. That is why different users see different results for a while after a DNS update.

TTL values are always given in seconds:

The TTL is an upper limit. RFC 2181 says that the TTL "specifies a maximum time to live, not a mandatory time to live", and it lets resolvers cap long TTLs at their own upper bound. Some resolvers also keep serving expired records during an outage, when they cannot reach the authoritative servers. RFC 8767 describes this practice of serving stale data.

Choosing a short or long TTL

A short TTL gets changes out quickly. A long TTL lets resolvers reuse cached answers for longer, which means fewer queries to your authoritative DNS servers and fewer failed lookups when those servers are briefly unreachable. The price is that planned changes take longer to reach everyone.

Use a short TTL for records that change often or need fast failover, and a long TTL for stable records where caching matters more than fast updates. There is no correct TTL for every record. It depends on how quickly the record must change, how much query traffic your DNS servers can handle and how much damage an outdated answer does.

For a planned change, lower the TTL first and raise it again once the new setup works. Before moving a website to a new load balancer, for example, you can lower the TTL to 300 seconds. Lower it early enough that the old, longer TTL has run out in every cache before you make the change. Amazon Route 53 recommends this approach when you change a domain or subdomain that is already in use.

Why DNS changes do not appear everywhere at once

DNS updates are often described as "propagation", but most of the delay comes from separate caches that fetched the record at different times. One resolver refreshed the record after the change, while another still has hours left on its cached copy.

Local caches add more delay. The operating system, the browser, applications and network devices keep DNS results of their own, so a user can still see the old answer after their resolver has the new one. Cloudflare notes that a local DNS cache can take longer to update than the TTL suggests.

TTL also applies to negative answers. If a resolver learns that a name does not exist (NXDOMAIN) or has no record of the requested type (NODATA), it caches that answer too. RFC 2308 defines this negative caching. So if someone looked up a new subdomain before you created it, their resolver can keep reporting that it does not exist for a while after the record goes live.

To check a DNS change, compare the answers from more than one recursive resolver and look at the remaining TTL each one reports. The configured TTL describes normal cache behavior. It is not an exact worldwide deadline, because resolver caps, local caches and stale answers during outages all affect what users see.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com