TTL Value in DNS: A Guide to Choosing the Right Number

You've changed the record, dig from your own server returns the new answer, but the customer still sees the old site. Or the opposite: you've set the TTL to 300 and after every change you're dealing with half an hour of trouble. Both cases have the same root: the number you've written in the TTL column doesn't match what you're actually doing. The TTL value isn't just a simple number; it's a contract between you and every resolver on the internet.

Who exactly does the TTL value give orders to

The TTL unit is seconds, and it tells intermediate resolvers how many seconds they can consider this answer valid without asking again. Note that this number doesn't give orders to the user's browser or operating system; they have their own caches and some browsers act independently of the TTL. So when you say "I lowered the TTL but it's still cached," you're probably looking at a layer that doesn't read this number.

The second point that's less often mentioned: the effective TTL isn't always your number. Resolvers have the right to apply a lower value, and some ISPs have their own internal ceilings. If you set the TTL to 30, it's not guaranteed to stay at 30 seconds everywhere; you've only set the ceiling, not the floor.

Reasonable range for each record type

There's no universal number. The table below shows the range that works in practice:

For the A record of a stable server, 3600 seconds is a reasonable starting point. If the site's traffic is high and many resolvers are involved, 86400 is also reasonable. But if you set this same record to 60, every visitor sends a fresh query to your authoritative almost every minute. On a weak DNS server, this small number shows up directly in CPU and bandwidth.

Lower the TTL before the change, not after it

This is where people make a mistake: they change the record and then lower the TTL. The correct order is the opposite. If the current TTL is 86400 and you want to change the IP tomorrow, lower it to 300 today and wait for the previous TTL to pass. That is, about one day. Then apply the change. If you don't do this, resolvers that have cached the old answer with a one-day TTL will give you the old answer until the end of that period, and there's no way to forcibly invalidate that cache.

The sign of it is this: half the users see the new site, half don't. Some see it correctly from mobile but not from home Wi-Fi. This scattering is a sign of a long remaining TTL, not a server problem.

The cost of lowering the TTL

The temptation you must resist is to always keep the TTL low so that "we're always ready for a change." The cost is paid by the resolvers and your DNS server. With a 60-second TTL on a domain with average traffic, the query load on the authoritative multiplies, and if that server is on the same machine that serves the site, you've attacked yourself at the worst possible moment.

So my choice is clear: set a long TTL for stable records and only shorten it during the migration window. The only case that justifies keeping it permanently low is a record that's truly rewritten automatically and repeatedly; such as the A record of a service with a dynamic IP or a subdomain that's updated by a script. If you have a dynamic subdomain structure, before choosing the number, also consider the behavior of the wildcard record; wildcard record and managing dynamic subdomains in DNS covers exactly this scenario.

How to see the actual value, not the value you think

Query the authoritative answer and the resolver answer separately. These two numbers are often not the same:

dig +noall +answer example.com A
dig @1.1.1.1 +noall +answer example.com A
dig @ns1.example.com +noall +answer example.com A

The last column of the output is the remaining TTL. If you got 3600 from the authoritative server and 2400 from the resolver, that means the resolver fetched the answer 1200 seconds ago and will keep it for another 2400 seconds. To see the full path and which server is answering, run dig +trace example.com. If the output of these commands is confusing to you, checking DNS records is a faster starting point.

A practical tip: after every change, check the TTL value in the dig output. If the number you see doesn't match the panel, you've probably edited the record in the wrong zone or on another DNS service. This happens more than you think, especially when the domain was bought from one registrar and the zone is hosted on another service.

TTL and email-sensitive records

For MX, a small number carries real risk. If you set the TTL to 60 and your mail server goes down for a few minutes, senders notice the change faster and may send the mail to the wrong destination or temporarily reject it. 3600 is a balanced choice for MX. For TXT records related to SPF and DKIM, 300 to 3600 is also enough; just remember that some email services read the old cached value when verifying the domain, and it takes a few hours for them to see the change.

If your domain is .ir, you have an extra layer: zone changes may pass through IRNIC, and its timing is independent of your TTL. The details of this path are in the complete guide to registering and managing an ir domain with an IRNIC identifier.

Errors seen in the DNS server log

When you make the TTL too short, the first sign usually isn't in the log; it's in the server load. But if you edit the zone manually, take these errors seriously:

• SERVFAIL after editing the zone: it's almost always a syntax error, not the TTL. You've forgotten the serial number (SOA serial) or left out the trailing dot in the hostname.
• NXDOMAIN for a subdomain that exists: the record is registered in a zone for which the authoritative server doesn't answer.
• An old answer with a high TTL from a specific resolver: that resolver's cache hasn't expired yet. Wait or test from another resolver.

We've written the correct order for checking these signs in a practical DNS troubleshooting guide: signs and the order of checking records; in most cases the problem isn't the TTL and the record has been registered incorrectly.

The final number I recommend

For an ordinary domain with a site on a stable server: A and AAAA at 3600, MX at 3600, CNAME at 1800, TXT at 3600, NS at 86400. Before any migration, lower the relevant record to 300, wait for the previous TTL, apply the change, and after it stabilizes, restore the number. If you have a high-traffic site and your DNS server is on the same machine as the site, a long TTL isn't just optimization, it's protecting yourself.

If you're registering a domain for the first time or building the zone from scratch, set these numbers correctly from the start; fixing them later is always more expensive than the initial setup. For new domains, you can start with domain search and registration and set up the zone with these same defaults.

Frequently asked questions

What's the minimum TTL value?

Technically even zero is allowed, but in practice no resolver re-queries every request and most have an internal floor of a few seconds. A value below 60 seconds has almost no practical benefit and only increases DNS server load.

Why do I still see the old site after changing the TTL?

Because the previous TTL is still in the resolvers' caches. Lowering the TTL only affects subsequent answers, and cached answers remain valid until the end of their own lifetime. You must wait for the previous TTL.

Does TTL affect a site's Google ranking?

Not directly. But a very short TTL can slightly increase DNS response time and, under heavy load, cause noticeable slowdown. Its effect is indirect and on the order of a few milliseconds, not an independent ranking factor.

For a server migration, how many hours before should I lower the TTL?

By the current TTL, not a fixed number. If the TTL is 86400, lower it at least 24 hours before. If it's 3600, one hour is enough. Simple rule: the waiting time equals the previous TTL, not the new TTL.