What Should Your DNS TTL Be? A Threshold Ladder by Record Type
The short answer is 3600 seconds, one hour, for most records most of the time. Drop to 300 seconds when you are planning a change, and go up to 86400 seconds for records that genuinely never move. TTL is a trade between how fast you can change something and how many queries you pay for, and the right value depends entirely on which side of that trade a given record sits on.
This article gives you a ladder of values with the reasoning attached to each rung, covers how the choice differs by record type, explains the one TTL you do not control, and works through the negative caching setting that people discover only when it bites them.
The TTL ladder
Five values cover essentially every case, and each one has a specific job.
60 seconds or less: failover only. Useful when an automated system rewrites the record in response to a health check and seconds matter. The cost is real, since every resolver re-queries every minute, and the benefit only exists if something is actually watching and changing the record. Static records at this TTL are paying a toll for nothing.
**300 seconds, five minutes: migration mode.** This is the value to set before a planned change and to hold during the transition. Five minutes is short enough that a mistake is quickly reversible and long enough that caching still does useful work. It is not a permanent setting for most records, though plenty of large sites run here indefinitely and simply accept the query volume.
**3600 seconds, one hour: the sensible default.** Long enough to cache effectively, short enough that an unplanned change is corrected within an hour. If you have no specific reason to choose otherwise, this is the value, and it is the right resting state for records that move occasionally.
**14400 seconds, four hours: stable infrastructure.** Reasonable for records that change perhaps twice a year, where you would rather have the caching efficiency and can plan any change well in advance.
**86400 seconds, twenty-four hours: records that never move.** Appropriate for things like a verification **TXT** record that will sit unchanged for years. It is a poor default, and it is where the twenty-four hour propagation folklore came from, because many providers used it as one.
The judgment underneath the ladder is simple: the TTL is the maximum time you will be stuck with a wrong answer after you fix it. Choose it by asking how long you could tolerate that, not by asking what looks tidy.
How the answer changes by record type
The ladder shifts depending on what the record does and how visible a mistake would be.
A and AAAA records for anything user-facing want one hour as a resting value, dropping to five minutes ahead of any planned move. These are the records that determine whether visitors reach a working server, so the recovery speed matters more than the query saving.
MX records deserve a longer TTL than web records, often four hours or more, because mail is resilient by design. A sending server that cannot deliver will queue and retry rather than fail permanently, which absorbs a good deal of the risk that a shorter TTL would buy you. Lower them ahead of a mail migration like anything else.
TXT records split by purpose. SPF and DKIM records are actively used on every message and are worth keeping at an hour so a mistake can be corrected quickly, since a broken SPF record starts affecting deliverability immediately. Domain verification records that a service checks once and then ignores can sit at a day quite safely.
CNAME records inherit the caching behaviour of the chain they point into, and it is worth remembering that a resolver caches each step separately. A short TTL on your CNAME does not help if the target it points at carries a long one.
NS records inside your own zone are usually set high, since nameservers change rarely, and this is where the exception below applies.
The TTL you do not control
Your zone's apex NS records are not the ones that matter when you change nameservers. The records that actually direct resolvers to your nameservers live in the parent zone, managed by the TLD registry, and the registry sets their TTL. For .com that value is commonly 172,800 seconds, forty-eight hours.
This is the single most useful thing to know about TTL, because it explains an otherwise baffling experience. You lower every TTL in your zone to 300, change your nameservers, and the change still takes two days to settle for some visitors. Nothing is broken. The cached record those resolvers are holding was served by the TLD, and your zone's settings never applied to it.
The practical consequence is that nameserver migrations need a different plan from record migrations. Lowering TTLs does not shorten the window, so the only safe approach is to keep both the old and new nameservers serving correct, identical answers throughout, so that whichever one a resolver reaches produces the right result. Our post on DNS propagation timing works through the sequencing in detail.
Negative caching, the setting nobody sets
There is one more TTL in your zone that most people never touch, and it governs how long a this record does not exist answer is cached. It comes from the minimum field in your SOA record, and it exists because resolvers cache absence just as they cache presence.
The failure it produces is memorable. Someone queries a hostname before you create it, the resolver caches the negative answer for the SOA minimum, you then create the record, and that resolver keeps reporting no such name for the full negative caching period. From your side the record plainly exists. From theirs it plainly does not, and neither of you is wrong.
A value in the range of 300 to 900 seconds is reasonable for most zones. Older defaults sometimes ran to several hours, which turns a five minute mistake into an afternoon. If you are about to create records that people are likely to query prematurely, and a launch is exactly that situation, checking this value first is worth the thirty seconds.
Common mistakes in setting DNS TTL
Lowering the TTL on the day of a change. The new value is subject to the old one, so it does not take effect until a full old TTL has passed. Lower it at least one old-TTL period ahead or the change does nothing for you.
Running every record at 60 seconds permanently. Very short TTLs only pay off when something is actively rewriting the record. Otherwise you are multiplying query volume and adding lookup latency for a responsiveness nobody uses.
Leaving the provider default at 86400. A day-long TTL means a mistake stays live for a day. It is a defensible choice for records that never change and a poor one for anything user-facing.
Assuming your NS TTL governs nameserver changes. The delegation lives in the parent zone at the registry's TTL, often forty-eight hours. Your zone's setting has no effect on how long resolvers cache it.
Ignoring the SOA minimum. Negative answers are cached too, so a hostname queried before it exists stays non-existent for that period. A long default here turns a quick fix into a long wait.
FAQ
What should my DNS TTL be?
3600 seconds, one hour, is the sensible default for most records. Drop to 300 seconds before a planned change, and use 86400 only for records that genuinely never move.
Is a lower TTL always better?
No. A lower TTL buys faster recovery from a wrong answer and costs more queries and slightly slower lookups. It is worth paying when a record might need to change quickly, and wasteful when it will not.
What TTL should I use before a migration?
300 seconds, set at least one full old-TTL period before the change so that resolvers have expired the old TTL along with the old answer. Hold it through the transition, then raise it back afterwards.
Does lowering my TTL speed up a nameserver change?
No. Nameserver delegation is cached in the parent zone at the registry's TTL, commonly forty-eight hours for .com, and your own zone settings do not affect it. Keep both sets of nameservers serving correct answers instead.
Closing thought
TTL is one of the few settings where the trade-off is completely legible: you are choosing how long you will live with a wrong answer in exchange for how many queries you avoid. Most records do not need much thought and belong at an hour. The ones that do need thought are the ones you are about to change, and the discipline that makes changes painless is lowering them early enough to matter rather than the morning of.
Because a low TTL only helps if you find out quickly that something is wrong, the setting works best paired with something watching. Odown checks from seventeen locations on every plan at intervals down to one minute, so a record that resolved to the wrong destination surfaces within a check cycle rather than whenever someone reports it. A five minute TTL and a five hour detection time is still a five hour problem.
