What is TTL in DNS?

TTL (time to live) is a setting on every DNS record that tells resolvers how many seconds they are allowed to keep the answer in their cache before checking with the authoritative nameservers again. It is expressed as a plain integer of seconds, so a TTL of 3600 means one hour and 86400 means one full day.

TTL exists to balance two competing goals: serving answers quickly from cache, and making sure those answers are not too far out of date. A longer TTL means faster, cheaper lookups but slower updates. A shorter TTL means changes apply quickly at the cost of more queries hitting your nameservers.

When a resolver looks up a record, it stores the answer along with its TTL and starts counting down:

1. A resolver queries your authoritative nameserver and receives a record, for example an A record with a TTL of 3600.
2. The resolver caches that answer and serves it to anyone who asks for the next 3600 seconds without contacting your nameserver again.
3. As the cached copy ages, the remaining TTL ticks down toward zero.
4. Once the TTL reaches zero, the cached entry expires. The next request triggers a fresh lookup, and the cycle starts over.

This is why a record can keep returning its old value for a while after you edit it. Resolvers around the world are still serving copies they cached before your change, and each one only refreshes when its own countdown hits zero. You can read more about how this caching layer behaves in our guide to DNS cache.

Most DNS providers offer a handful of standard TTLs. These are the values you will see most often and when each makes sense:

• 300 seconds (5 minutes) — a short TTL used during migrations or for records that change frequently. Updates apply quickly, but lookups are more frequent.
• 1800 seconds (30 minutes) — a middle ground for records that change occasionally.
• 3600 seconds (1 hour) — a sensible default for most A, AAAA, and CNAME records on a stable site.
• 86400 seconds (1 day) — a long TTL for records that almost never change, such as MX records or NS delegations. Lookups are cheap and fast.

As a rule of thumb, use a longer TTL for records you rarely touch and a shorter TTL for anything you expect to move soon. There is no benefit to setting an extremely low TTL like one or two seconds on a stable record; you simply add load and gain nothing.

The single most useful trick with TTL is to lower it before a migration, not during it. Because resolvers cache the old value for the length of the TTL that was in effect when they fetched it, you have to plan ahead:

1. At least one full TTL period in advance, lower the record's TTL to 300 seconds.
2. Wait for the old, longer TTL to fully expire everywhere, so all resolvers are now caching with the new short value.
3. Make your actual change, such as pointing the record at a new server.
4. Because the TTL is now only five minutes, the new value reaches everyone within minutes instead of hours.
5. Once you have verified the change, raise the TTL back to its normal value to reduce query load.

Skipping the lowering step is the most common reason a migration drags on far longer than expected: the old record was cached at a long TTL, so resolvers keep serving it long after the switch.

TTL is the main lever behind what people call DNS propagation. There is no central database that pushes updates out; instead, the apparent delay is just the sum of every resolver waiting for its cached copy to expire. A record with a one-day TTL can keep showing the old answer for nearly 24 hours after you change it, while a five-minute TTL clears within minutes. Our guide to DNS propagation walks through the full picture.

Because TTL controls how long a wrong or malicious answer can linger, it also matters for safety. If a record is changed without your knowledge, a long TTL means the bad value sticks around longer. ZoneWatcher watches your records around the clock and alerts you the moment a value or its TTL changes, so you are not waiting on a cache to tell you something is wrong.