If you have ever wondered why a DNS change is not instant — why your new website or email settings take hours to appear everywhere — the answer usually comes down to one small setting: the TTL, or time to live. It is the value that tells the rest of the internet how long to remember a DNS record before checking for a fresh copy, and it quietly governs how fast (or slow) your DNS changes take effect. Understanding TTL turns the mystery of propagation into something you can actually plan around.

This guide explains what a TTL is in DNS: what the setting means, how caching uses it, how it controls propagation speed, what values are typical, the trade-offs of high versus low TTL, and the practical trick of lowering it before a planned change. By the end, this small but powerful number will make clear sense — and you will know how to use it to your advantage.

What TTL means

TTL stands for time to live, and in DNS it is a value — measured in seconds — attached to each DNS record that tells other servers how long they may cache (store) that record before they must check with the authoritative source for a fresh copy. In plain terms, it is the record’s expiry timer for caching: how long the answer stays ‘good’ before it needs to be looked up again.

Every DNS record — your A record, MX record, and so on — has a TTL, and it applies to that specific record. A TTL of 3600, for example, means servers may cache the record for 3600 seconds (one hour) before rechecking. The value is set in your DNS configuration alongside the record itself.

So TTL is a caching instruction embedded in each DNS record. It does not change what the record says; it controls how long the wider internet is allowed to remember that record before asking again. This small number has an outsized effect, because it governs how quickly any change you make to the record actually reaches everyone — which is where its real importance lies.

How caching uses TTL

To understand TTL’s effect, you need to understand DNS caching. When a server or device looks up a DNS record, it does not query the authoritative source every single time — that would be slow and wasteful. Instead, it caches the answer and reuses it for subsequent lookups, which is what makes DNS fast in everyday use.

The TTL is what tells each cache how long it may keep and reuse that stored answer. A resolver that fetches your record with a TTL of one hour will serve that cached answer to everyone asking for the next hour, and only after the TTL expires will it go back to the authoritative source for a fresh copy. Caches all over the internet do this, each on its own timer.

So caching is why DNS is fast, and TTL is the dial that controls how long cached copies persist. The whole reason DNS changes are not instant is that caches around the world are still serving old copies until their TTL runs out. TTL, in other words, is the setting that determines how long the internet keeps remembering your old record after you have changed it.

How TTL controls propagation

This is where TTL matters most in practice: it directly controls how quickly a DNS change propagates. When you change a DNS record, servers that have the old version cached will keep serving it until their TTL expires — only then do they fetch your new record. So the TTL that was in effect determines how long the old answer lingers.

A high TTL means caches hold the old record for a long time, so a change propagates slowly and can take many hours to be seen everywhere. A low TTL means caches refresh quickly, so a change propagates fast. This is the mechanism behind the familiar advice that DNS changes can take up to 48 hours — the tail is caches with longer TTLs (and some ISPs that ignore TTL) finishing their timers.

So when someone asks why their DNS change has not taken effect yet, the answer is almost always TTL and caching: the old record is still cached somewhere and will not refresh until its TTL expires. Understanding this transforms propagation from a mysterious wait into a predictable process governed by a number you can actually see and, importantly, adjust.

Typical TTL values

TTL values are set in seconds, and a few common values give a sense of the range. Here are typical choices and what they mean.

A TTL around one hour (3600 seconds) is a common, balanced default that most records use, refreshing reasonably often without excessive lookups. Shorter values like 300 seconds (five minutes) make changes propagate fast but mean caches refresh more often; longer values like 86400 (a day) make records very stable but slow to change. The right value depends on how stable versus changeable you need the record to be.

High vs low TTL trade-offs

Choosing a TTL is a trade-off between stability and agility. A high TTL (long caching time) reduces the number of lookups to your authoritative nameserver, which is efficient and fine for records that rarely change, and it means most of the internet has your record cached and ready. The downside is that when you do need to change the record, the change propagates slowly.

A low TTL (short caching time) means changes propagate quickly, because caches refresh often — valuable when you expect to change a record soon or need the flexibility to update fast. The trade-off is more frequent lookups to your nameservers and slightly less caching efficiency, though for most purposes this is negligible.

So the general principle is: use a longer TTL for stable records you rarely touch (efficient, and no need for fast changes), and a shorter TTL for records you are about to change or need to be able to update quickly (agile, at a small efficiency cost). Most records sit comfortably at a balanced default like one hour, and you adjust up or down only when stability or speed of change specifically matters.

The pre-change trick: lower it first

The single most useful practical application of TTL is a simple trick: lower the TTL before a planned DNS change to make the change propagate fast. Because the TTL in effect when caches fetch your record determines how long they hold it, reducing the TTL in advance means caches will refresh sooner, so your later change reaches everyone quickly.

The technique is to lower the record’s TTL — to a short value like 300 seconds — a day or two before you plan to make the actual change. This gives the existing longer-TTL caches time to expire and re-fetch the record at the new, low TTL. Then, when you make your real change (pointing to a new server, switching hosts, updating email), it propagates in minutes rather than hours, because everyone is now caching with the short TTL.

After the change has propagated and settled, you can raise the TTL back to a normal value for efficiency. This lower-then-change-then-restore approach is the professional way to make DNS changes with minimal downtime and delay — turning TTL from a source of frustrating waits into a tool you actively use to control exactly how fast a change takes effect. It is the practical payoff of understanding what TTL really does.

FAQs

What is a TTL in DNS?

TTL (time to live) is a value in seconds attached to each DNS record that tells other servers how long they may cache the record before checking the authoritative source for a fresh copy. It’s the record’s caching timer — how long the answer stays ‘good’ before it needs to be looked up again. Every DNS record has a TTL.

How does TTL affect DNS caching?

When a server looks up a DNS record, it caches the answer and reuses it rather than querying every time — which makes DNS fast. The TTL tells each cache how long it may keep and reuse that stored answer before refetching. Caches all over the internet do this, each on its own TTL timer, which is why old records can linger.

Why do DNS changes take time because of TTL?

Because servers with the old record cached keep serving it until their TTL expires — only then do they fetch your new record. A high TTL means the old answer lingers a long time (slow propagation); a low TTL means caches refresh fast (quick propagation). TTL and caching are the main reason DNS changes aren’t instant everywhere.

What is a typical TTL value?

TTLs are in seconds. Common values: 300 (5 minutes, fast propagation), 3600 (1 hour, a balanced default), 14400 (4 hours), and 86400 (24 hours, very stable but slow to change). Around one hour is a common default; use shorter values when you need fast changes and longer ones for stable records that rarely change.

Should I use a high or low TTL?

Use a longer TTL for stable records you rarely change — it’s efficient and reduces lookups. Use a shorter TTL for records you’re about to change or need to update quickly — changes propagate fast, at a small efficiency cost. Most records sit at a balanced default like one hour; adjust only when stability or speed of change specifically matters.

How do I make a DNS change propagate faster?

Lower the record’s TTL (to a short value like 300 seconds) a day or two before your planned change. This lets existing caches expire and refetch at the low TTL, so your later change propagates in minutes rather than hours. After it settles, raise the TTL back for efficiency. This lower-then-change trick minimises downtime and delay.

The bottom line

A TTL (time to live) in DNS is a small but powerful setting: a value in seconds, attached to each DNS record, that tells the rest of the internet how long to cache that record before checking the authoritative source for a fresh copy. It is the record’s caching timer, and it works hand in hand with DNS caching — the mechanism that makes DNS fast by letting servers reuse stored answers rather than querying every time. Because caches all over the internet hold your record until its TTL expires, the TTL directly governs how quickly any change you make actually reaches everyone: a high TTL means slow propagation as old copies linger, a low TTL means fast propagation as caches refresh often.

That makes TTL the answer to the perennial question of why DNS changes are not instant, and it turns propagation from a mystery into something predictable. Typical values run from 300 seconds (five minutes, fast) through a balanced one-hour default to 86400 (a day, very stable), with the choice being a trade-off between stability and agility. The most useful practical takeaway is the lower-then-change trick: reduce a record’s TTL a day or two before a planned change so caches refresh quickly, make the change so it propagates in minutes rather than hours, then restore the TTL afterward for efficiency. Understand TTL, and you turn a source of frustrating DNS waits into a tool you actively use to control exactly how fast your changes take effect.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. A TTL (time to live) is a per-record value in seconds telling the internet how long to cache a DNS record before rechecking. It governs propagation speed: high TTL = slow changes, low TTL = fast changes. Typical is around one hour. The key trick: lower the TTL a day or two before a planned change so it propagates in minutes, then restore it afterward.