TTL Explained: How to Change DNS Without Taking the Site Down

Every DNS outage story I have heard follows the same shape. Someone made a perfectly reasonable change, the change was correct, and yet for hours afterwards part of the world kept going to the old place. The villain is almost always TTL — a number that most people set once, ignore forever, and only learn to respect after it ruins a Friday.

This article is about that number: what it controls, how it travels, and how to plan a change so the cutover is boring.

What TTL actually controls

TTL stands for time to live, and it is measured in seconds. It is attached to each record in your zone, and it tells a resolver how long it may keep a copy of that answer before asking again.

That is the entire mechanism. DNS does not push changes out to the world. When you edit a record, you have updated the source of truth — the authoritative servers — and nothing else. Everyone else learns about it on their own schedule, when their cached copy expires and they come back to ask. Try it on DNS Checkers Check DNS Propagation

A TTL of 300 means resolvers may hold the answer for five minutes. A TTL of 86400 means a full day. Long TTLs reduce query volume and make lookups marginally faster. Short TTLs make you nimble. You get to pick which one you want, per record.

The cache chain between you and your visitor

It helps to picture the chain of copies between your DNS panel and a visitor's browser.

Your authoritative nameserver answers. A recursive resolver — the one at the visitor's ISP or a public service — caches that answer. If the visitor runs their own small DNS service, that may cache too. The operating system caches. So, sometimes, does the browser. Each copy has its own expiry clock, started at a different moment.

This is why two people can see two different answers at the same instant, and why "it worked for me" is one of the least useful sentences in an incident call. You are not comparing one system to another. You are comparing two chains of copies that happened to start at different times.

Why lowering the TTL the day of the change fails

Here is the trap. Suppose your A record has a TTL of 86400 and you decide at 11am to lower it to 300, then change the address at noon. Everything looks fine on your end.

But every resolver that fetched your record this morning is entitled to keep that old answer until tomorrow morning. Your new 300-second TTL only applies to copies fetched after the change. You shortened the life of future copies while leaving a day's worth of old ones exactly as they were.

The correct order is the reverse. Lower the TTL first, then wait out the old TTL in full, and only then make the change. If the old TTL was a day, you need to lower it a day ahead. That waiting period feels wasteful. It is the price of a clean cutover, and it is far cheaper than an hour of split traffic.

A staged approach that works

For anything that matters — a mail server move, a hosting change, an apex repoint — I use the same sequence.

• Set the stage. Lower the TTL on the records you intend to change to 300 seconds. Do not change the values yet.
• Wait one full old-TTL cycle. If the previous TTL was 3600, wait at least an hour, ideally a couple. This lets the shortened TTL propagate everywhere.
• Verify the low TTL has landed. Query a few public resolvers and confirm they now report 300. There is no point proceeding until they do.

• Make the change. Update the records. Because every cache is now short-lived, the new answer spreads in minutes rather than hours.
• Watch it settle. Check several resolvers, confirm the new answer is coming back everywhere, and keep an eye on your logs.
• Wait for the dust to clear. Give it at least one more old-TTL cycle before you are confident.
• Raise the TTL again. Once stable, put it back to something sensible so you are not paying for extra queries forever.

That is the whole discipline. Boring, sequential, and it has never let me down.

The negative caching trap nobody warns you about

There is one more cache with a TTL you did not set on the record: the cache for names that do not exist.

When a resolver asks for a name and gets told it does not exist, it remembers that answer too. The length of that memory is taken from the SOA record's minimum field — the negative caching TTL. So if your zone has a generous SOA minimum of, say, 86400, resolvers may keep insisting a newly created record does not exist for up to a day after you add it.

This shows up in the wild as "I created the record and it works locally but not for my colleague." Locally, you may be querying the authoritative server directly, which knows the truth. Your colleague is talking to a resolver that is still serving yesterday's "not found."

If you are adding records frequently, either keep the SOA minimum modest or expect these ghost delays. Either way, know why they happen so you do not chase a problem that is really just a timer.

Choosing TTL values on purpose

There is no single correct TTL, but there are sensible defaults. Static records that rarely change — NS, MX, a stable apex A — are happy with 3600 or higher. Records you tune frequently, like a CDN or a load-balancer target, can sit at 300 without any real cost.

A practical rule I use: pick the TTL based on how fast you would need a mistake undone, not how fast you expect changes. If a wrong value could take the site down, a shorter TTL is cheap insurance. If a record is effectively permanent, caching it hard is a favour to everyone's resolver.

One more consideration is cost. Very short TTLs across a large, busy zone mean many more queries hitting your authoritative servers. For most small sites this is irrelevant. For a heavily queried domain, it can turn into real load — and, with some managed DNS providers, a line on your invoice.

Where provider TTLs come from, and why yours sometimes changes

Occasionally you will set a TTL, check it later, and find a different number published. You did not edit it. This is more common than it sounds, and the cause is usually one of three things.

Some managed DNS providers enforce a minimum TTL on their cheaper plans, or on records served through their global anycast network. You can type 60, but the panel quietly publishes 300 or 600 because that is the granularity their infrastructure supports. Always read the published TTL rather than trusting the value you entered.

Some providers run a traffic-steering or health-check feature that rewrites TTLs for the records it manages. If a record is tied to a failover or weighting policy, the provider may control the TTL on your behalf so it can react quickly. That is a reasonable design, but it means your mental model of the zone is no longer complete.

And some services — certificate automation, CDN integrations, dynamic DNS clients — update TTLs as a side effect of their own logic. If a record changes value and TTL at three in the morning with no human involved, look for an automation holding your API key before you suspect a bug.

The practical takeaway is simple: never assume. Query the authoritative server and read the TTL that is actually being served. If it does not match what you intended, find out why before you plan a change around it, because a migration built on the wrong TTL estimate is a migration that runs long. Try it on DNS Checkers Lookup All DNS Records

Measuring instead of guessing

The instinct after a change is to refresh a browser and declare victory. Resist it. A browser can be showing you a cached answer from any layer, and it tells you nothing about what a stranger's resolver sees.

A better routine is to query a handful of independent resolvers and compare. If they agree and the answer is the one you intended, you are done. If they disagree, you are watching caches expire in real time, and the useful information is which resolvers still hold the old value. That difference is the actual state of the world. Try it on DNS Checkers Domain Health Check

It also helps to record what you changed and when. A migration that goes sideways is far easier to reason about with a timeline than from memory, especially once three people are involved and two of them are certain the other one caused it.

The mindset

DNS is eventually consistent, and there is no override button. You can shorten the window of uncertainty, but you cannot eliminate it, and no amount of refreshing will hurry it along.

Once that stops being frustrating and starts being the plan, DNS changes become calm. Lower the TTL early, wait, change, verify, and put the TTL back. Do it in that order and the worst case is that your cutover is uneventful — which is exactly what you want.