What Is DNS TTL? Time to Live Explained

DNS TTL means Time to Live. It is the value that tells recursive resolvers how long they are allowed to cache a DNS answer before they need to ask the authoritative nameserver again.

If you are searching for what DNS TTL is, the short answer is that TTL controls cache duration. It does not change where a record points, but it strongly affects how quickly the rest of the internet notices your change.

example.com. 300 IN A 203.0.113.10

In that example, 300 is the TTL in seconds, so a resolver may keep the answer for up to five minutes.

When a user, mail server, or application queries DNS, the answer is often returned by a recursive resolver rather than by the authoritative nameserver directly. That resolver caches the result for the TTL period to reduce repeated lookups and improve performance.

A higher TTL reduces query volume and can improve stability under load, but it also means old answers stay visible for longer. A lower TTL makes changes become visible more quickly, but increases the number of refreshes required.

• Low TTL: faster visibility for planned changes
• High TTL: fewer refreshes and steadier caching
• Any cached answer can remain in use until its TTL expires

DNS propagation is mostly a caching story, and TTL is one of the main reasons different resolvers can show different answers after a change. If a resolver cached the old record just before you updated it, that resolver may continue serving the old answer until the cached TTL runs out.

That is why lowering TTL ahead of a planned migration is a common operational step. It shortens how long old answers can survive in caches once the change is made.

• What is DNS propagation?
• How to check DNS propagation

There is no single best DNS TTL for every record. The right value depends on how often the record changes, how critical fast rollback is, and whether the record supports a stable service or an active migration.

• 60 to 300 seconds: useful before migrations, cutovers, or failover testing
• 1800 to 3600 seconds: a common middle ground for records that change occasionally
• 86400 seconds or more: often used for stable records that rarely change

Very low TTLs are not automatically better. They create more refresh traffic and do not fix a wrong authoritative answer.

• A and AAAA records during web migrations or cutovers
• MX records during email provider changes
• CNAME records used for app routing or verification
• TXT records when changing SPF, DKIM, or DMARC during mail troubleshooting
• NS and delegation-related records where mistakes can have wide impact

TTL matters most when the cost of stale data is high. If users or mail systems must switch quickly, TTL should be part of the change plan rather than an afterthought.

• TTL does not force every resolver to refresh immediately at the same moment
• Changing TTL after a resolver already cached the old record does not shorten that existing cache entry
• A low TTL does not correct a broken target or wrong record value
• Browser, operating system, or application caching can add extra delay beyond DNS TTL alone

These misunderstandings are why DNS changes can feel inconsistent. The authoritative zone may already be correct while some clients still behave as if nothing changed.

• Identify which records will change and how quickly they may need rollback
• Lower TTL well before the cutover so caches can age out under the shorter value
• Make the DNS change and verify the authoritative answer first
• Check multiple public resolvers to understand cache spread
• Raise TTL again after the new configuration is stable if a longer cache is appropriate

If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.

• Record Lookup
• DNS Propagation Checker
• Domain DNS Summary