What is TTL in DNS - why your change is not showing

TTL stands for Time To Live, and in DNS it's a number, in seconds, attached to every DNS record that tells any computer or server that looks it up how long it's allowed to remember the answer before asking again. If your website's IP address just changed and some visitors are still landing on the old server, the direct cause is almost never a broken DNS record — it's a resolver somewhere still sitting on a cached answer whose TTL hasn't run out yet.

Jake had already re-pointed his shop's website to a new server twice that week, each time convinced the first attempt "didn't take." Both times it had taken — on his phone, at his desk, using his phone's carrier network, five minutes after he made the change, the old site was still there. His actual DNS record was fine both times. What he was fighting was a cache that had nothing to do with the change he'd just made and everything to do with a number he'd never looked at before he touched anything.

"You keep treating this like the internet forgot to tell everyone," Ethan told him, watching Jake refresh the same browser tab for the fourth time. "It's the opposite. The internet remembered exactly what you told it, back before you changed your mind. That's the whole bug — and it's not a bug, it's the design working correctly."

What TTL actually is (and why it exists at all)

Start with what DNS is doing in the first place, because the acronym gets thrown around like everyone already knows it. DNS, the Domain Name System, is the address book that turns a name a human can remember — like example.com — into a numerical address a computer can actually connect to. Every time you type a website name or open an app, something on your device (or on a server sitting between you and the internet) has to look that name up.

Looking it up every single time, for every single request, would be slow and wasteful. So the answer gets cached — stored temporarily in memory, the way you'd leave a pan you're about to use again sitting out on the stove instead of putting it back in the cupboard. Grabbing it again is faster than digging it out. A DNS resolver is the piece of software doing that looking-up and that storing — it could be a service run by your internet provider, a public one like the ones Google or Cloudflare operate, or even a small piece of software running quietly on your own computer.

TTL is the label on that pan that says how long it's allowed to sit out before someone has to put it back and get a fresh one. Concretely: Time to Live (TTL) is a field on DNS records that controls how long each record is cached and — as a result — how long it takes for record updates to reach your end users. The party that sets that number is whoever manages the DNS record — you, or your host, or your DNS provider — and it's attached to the record itself, not to any one resolver's settings.

The authoritative nameserver is the server that holds the real, current, "official" version of your DNS records — the source everyone else is ultimately asking. When you update a record there, the update is immediate on that server. What isn't immediate is every other resolver on the planet that already asked, got an answer, and is sitting on a cached copy with a TTL clock still running.

"People hear 'cache' and think of it as something shady, like the internet is hiding something from them," Ethan said. "It's the opposite of shady. Every layer that caches your DNS answer is doing you a favor every other day of the year — it's just that on the one day you change something, that favor works against you for a while."

The one-question diagnostic: did you lower the TTL before you made the change, or after?

This single question splits almost every "TTL isn't working" case into two completely different situations, and readers almost always assume they're the same one.

Case one: you lowered the TTL and made the change at the same time

This is the case that catches almost everyone, and it's the one true counterintuitive reveal in this article: lowering TTL at the moment you change the record does nothing to speed up that change for anyone who already had the old record cached. Resolvers that cached your record before you touched anything are still working off the old TTL, because that's the number they saved along with the answer. Your new, lower TTL only applies to lookups that happen after a resolver's existing cache entry expires and it comes back to ask again. Editing the TTL field doesn't retroactively shrink a clock that's already running elsewhere.

"This is the single most common mistake I see, and it's not even a mistake in judgment — it's a mistake in timing," Ethan said. "People treat the TTL field like a volume knob they can turn down mid-song. It's not. It's more like a note you leave for the next person who asks — and the people who already walked away with the old note aren't coming back to read the new one until their note expires."

Case two: you lowered the TTL well ahead of time, then changed the record

This is the version that actually works the way people expect. Once enough time has passed for the old, longer TTL to fully expire everywhere, every resolver that asks again will receive your new, shorter TTL along with the current answer. From that point on, if you make your real change, most caches will pick it up within that shorter window. This is why professional migration guidance is consistently phrased the same way: lower it first, wait, then change the record — never lower and change in the same sitting.

Route 1: it's just your own device holding the old answer

Before assuming the whole internet is stuck, rule out the machine in front of you. Your operating system keeps its own local DNS cache, separate from anything your ISP or a public resolver is doing, and on top of that your browser often keeps a second cache of its own. Both need clearing separately.

Windows 11

These steps are the same on Windows 10 as well — Microsoft hasn't changed the underlying command.

1. Right-click the Start button and choose Terminal (Admin) — this opens a command-line window with the permissions the flush needs. If you don't see an admin option, press Win + R, type cmd, then press Ctrl + Shift + Enter to run it elevated.
2. Type ipconfig /flushdns and press Enter. This flushes and resets the contents of the DNS client resolver cache — every dynamically added entry, and anything cached as a "this doesn't exist" negative answer, is cleared out.
3. You should see a confirmation message that the resolver cache was flushed. If you want to see what was cached before flushing, run ipconfig /displaydns first — this displays the current contents of that cache.
4. If your app or browser needs your device to re-announce its own name to the network (common on a domain-joined machine), ipconfig /registerdns re-registers your DNS name and IP address.

Windows 11 UI trap: if you're trying to do this by right-clicking Start and hunting for an old-style "Command Prompt" entry, you may not find one — Windows 11's Start menu and right-click context menus have moved things around repeatedly. The reliable path is Win+R, or search for "Terminal" directly; don't waste time hunting through relocated menus for a shortcut that may not be where it used to be.

Windows 10

Identical command, identical result: open an elevated Command Prompt (right-click it, "Run as administrator") and run ipconfig /flushdns. There is no Windows-10-specific variant of this — Microsoft's own documented syntax for flushing the client resolver cache hasn't changed across versions.

macOS

Apple's own guidance for modern macOS (from OS X Yosemite onward) is to open Terminal and run:

sudo killall -HUP mDNSResponder

This sends a signal telling the process responsible for DNS lookups on your Mac to reload rather than continue serving what it already has cached. You'll be asked for your Mac's password; nothing visibly happens afterward, which is normal — there's no "success" message, so don't assume it failed just because the Terminal window looks unchanged.

Linux (including Kali and other systemd-based distributions)

Most current Linux distributions, Kali included, run DNS resolution through systemd-resolved, a background service that is part of systemd. To flush everything it has cached locally, run:

resolvectl flush-caches

This is systemd's own documented behavior for the command: it flushes all DNS resource record caches the service maintains locally, and is functionally the same as sending the service a specific low-level signal to force the flush. If your distribution's networking setup doesn't run systemd-resolved (some minimal or older setups don't), this particular command won't apply — check whether the service is active before assuming it's the culprit.

Your browser has its own separate cache

Flushing the operating system's cache doesn't automatically clear a browser's own DNS cache, and Chromium-based browsers (Chrome, Edge, Brave, and others built on the same engine) keep one. Type chrome://net-internals/#dns into the address bar, and there's a dedicated host resolver cache section with a "Clear host cache" button built directly into the browser's own diagnostics page — this is Chromium's own internal tooling, not a third-party add-on.

Route 2: everyone else's resolver is still holding the old answer

This is the harder truth, and the one every guide should say plainly instead of dancing around: you cannot force a resolver you don't control to drop its cached copy of your record early. Not your ISP's resolver, not a coworker's phone on a different carrier, not a public resolver somebody else configured on their router. If they asked for your record before you changed it, they're holding a cached answer with its own countdown, and that countdown belongs to them, not you.

What you actually control is only ever the number that goes into new lookups going forward, plus whatever cache sits on your own device. Anyone who's already cached the old answer has to either wait out the TTL naturally, or manually flush their own device the same way you'd flush yours — which isn't something you can do for them.

"I get asked at least once a week whether there's a way to reach out and clear someone else's cache remotely," Ethan said. "There isn't, and honestly, there shouldn't be. If any website operator could reach into a stranger's resolver and force it to forget things on command, that's not a DNS feature, that's a security hole."

How long should you actually expect to wait?

The honest answer is: as long as the TTL that was live on the record before you changed it. If nobody had touched that record in a while and it was set to a common default, here's roughly what that translates to in human time.

These are the seconds-to-time conversions, not guesses about resolver behavior — the actual delay depends on whatever number was already sitting in the record's TTL field before your change went out.

The nameserver TTL trap nobody warns you about

Here's the case that eats far more time than a normal A record change: switching your entire domain from one DNS provider to another, or pointing your domain at a completely different set of nameservers. This isn't governed by the TTL on any individual record you can see in your new provider's dashboard — it's governed by the NS records held at the domain registrar level, and those are usually set to a long TTL by default.

Domain registrars typically use a TTL of 24 to 48 hours for name servers. This means that when a DNS resolver gets the name servers for your domain, it uses that information for up to 48 hours before it submits another request for the current name servers. That's a completely separate clock from whatever TTL you've set on the individual A record for your website, and it's the one that actually governs how quickly the switch to a new DNS provider becomes visible.

On the provider side, a typical default TTL for the NS record itself in a newly created zone is around 172,800 seconds — two days. If you're planning a migration between DNS providers, the accepted approach is to lower that NS record's TTL, on both the old provider and the new one, to something in the 60–900 second range (1–15 minutes), and then wait for that old, longer TTL to fully expire before actually flipping providers. Skipping that step is why "I moved my DNS yesterday and it's still not showing" so often turns out to be exactly two days, not a sign of anything broken.

"This is the one that gets small businesses more than anything else on this page," Ethan said. "Somebody switches hosting providers over a weekend, doesn't touch the NS TTL beforehand, and spends Monday convinced their new host broke something. Nothing's broken. Two days is just how long the old note takes to expire."

Negative caching: when "it doesn't exist" gets remembered too

This is the case that confuses people more than a simple stale-record situation, because it feels backwards: you create a brand-new record — say a subdomain that didn't exist before — and it still shows as "doesn't exist" for a while, even though you just created it.

Resolvers don't only cache successful answers. When a resolver asks for something and gets back "no such record" (an NXDOMAIN response), it caches that negative answer too, so it doesn't keep pestering the authoritative server about a name that isn't there. How long it remembers that "no" is set by a different field entirely — the minimum TTL value in the SOA (Start of Authority) record for your domain's zone, which controls negative caching specifically. On Route 53, for example, the length of that negative caching is the lesser of two values: the minimum TTL field in the SOA record, or the TTL set on the SOA record itself — and the recommended default for that negative caching value is 900 seconds.

If someone (or some automated system) queried your new subdomain before you'd finished creating it, their resolver may hold onto that "it doesn't exist" answer for the length of that negative caching window — completely independent of how quickly you finish setting up the actual record.

Doing it right the next time: lower TTL first, change second

This is the sequence that actually front-loads the benefit of a low TTL instead of applying it too late to matter.

1. Check the record's current TTL in your DNS provider's dashboard, well before you plan to make any change. If it's set to something like 3600 or 86400 seconds, that's the number governing how stale things can get once you act.
2. Lower the TTL — and stop there. Set it to something short, commonly in the 60–300 second range, but change nothing else about the record yet.
3. Wait out the old TTL fully. If it was set to 3600 seconds before your edit, wait at least an hour (some guidance suggests roughly double the old TTL, to be safe against resolvers that don't refresh the instant they're supposed to) before assuming the shorter TTL is now in effect everywhere.
4. Make the real change — the new IP address, the new server, the new nameservers, whatever the actual migration is. Because the short TTL is now the one resolvers are honoring, most caches pick up the new answer quickly.
5. Confirm it's live using a direct query against a public resolver, not just your own browser (see the "Route 2" section above).
6. Raise the TTL back up once you're confident the change has settled — a permanently tiny TTL means every resolver on the internet is asking your authoritative server far more often than it needs to, purely for records that aren't changing anymore.

Edge cases: VPNs, corporate networks, mobile data, and everything with its own idea of DNS

Every device that resolves DNS keeps its own idea of what's cached, and the more unusual the setup, the more separate caches are stacked between you and the answer.

VPNs and split tunneling

When a VPN is active, your device may be sending DNS queries through the VPN's own resolver instead of your regular network's — which means it has an entirely separate cache from the one you'd flush normally. If a site looks fixed with the VPN off but broken with it on (or vice versa), you're looking at two different caches with two different clocks, not a broken fix. Disconnect, flush, reconnect, and flush again on that connection specifically if you need both paths current.

Corporate networks and domain-joined machines

On a company network, DNS often routes through an internal server before it ever reaches the public internet, and that internal server keeps its own cache in addition to whatever your laptop is holding locally. Flushing your own laptop's cache with ipconfig /flushdns won't touch the company DNS server's cache — that typically needs an administrator to act on the server itself, which is a conversation with IT, not something an end user can do from their own machine.

Switching from Wi-Fi to mobile data

Your phone's cellular carrier runs its own DNS resolvers, entirely separate from your home Wi-Fi's. It's common to see a change reflected instantly the moment you switch off Wi-Fi and onto mobile data, purely because the carrier's resolver hasn't cached the old answer yet — not because anything about the fix changed.

Smart TVs, game consoles, and other devices you can't easily flush

A surprising number of connected devices don't offer any user-facing way to clear a DNS cache at all. For those, the practical workaround is usually a full network-level reboot — restart the router itself, which typically clears the router's own DNS cache and forces every connected device to re-resolve on its next request, even though it won't have flushed the individual device's internal cache directly.

Managed DNS and CDNs: what "propagated" really means there

If your domain sits behind Amazon Route 53, updates to your records are designed to propagate across Route 53's own worldwide network of authoritative DNS servers within 60 seconds under normal conditions — and once the API reports that as complete, that's the authoritative side done. It's separate from, and outside the control of, whatever caching DNS resolvers out on the internet decide to do with your record's TTL from that point forward. Notably, Route 53 doesn't set a default TTL for you at all — every record requires you to specify one explicitly, which forces the decision instead of letting a hidden default surprise you later.

If your domain sits behind Cloudflare with the orange-cloud "proxied" setting turned on, the TTL you see is fixed: proxied records default to an "Auto" TTL that's set to 300 seconds and can't be edited, specifically because that setting exists to make sure a changed IP address behind Cloudflare's own network takes effect quickly. Unproxied ("DNS only") records give you more control — a configurable TTL ranging from as low as 30 seconds on an Enterprise plan (60 seconds on other plans) up to a full day.

Third-party propagation checkers: useful, and where they mislead you

Public DNS-checker sites that query your domain from multiple locations around the world can be genuinely useful for one specific thing: showing you that your new record actually exists and is reachable from somewhere other than your own network. That rules out "did I actually save the change" as the problem.

Where they mislead people is in implying that a green checkmark from twenty locations means the change has "propagated" everywhere. It doesn't mean that, and it can't — those tools are themselves just resolvers making fresh queries, and a fresh query from a tool that's never cached your record will always show the new answer immediately, regardless of what a resolver that cached the old answer three hours ago is still serving your actual visitors. A propagation checker showing 100% green tells you the new record is correctly published. It tells you nothing about whether a specific stubborn resolver somewhere is still handing your visitor the old one.

Automating this so you don't have to remember it every time

If you're managing DNS for more than one site, doing every step above by hand every single time isn't sustainable. A few small habits turn this into a checklist instead of a fire drill.

1. Keep a running note of each record's "normal" TTL alongside your DNS provider's dashboard, so you're never guessing how long a stale answer could realistically persist before you start troubleshooting.
2. Build the lower-wait-change-verify-raise sequence into your migration checklist as fixed steps with dates, not something you improvise the day of. If step 2 (lower the TTL) doesn't happen at least one full old-TTL-length before step 4 (make the change), the checklist should flag it, not let it slide.
3. Script the local flush on machines you manage directly rather than doing it by hand each time — a simple scheduled task or shell alias that runs ipconfig /flushdns or resolvectl flush-caches saves the "wait, what was that command again" moment mid-incident.
4. Automate the verification step, not just the change itself — a small script that repeatedly queries a record against a public resolver and alerts you the moment the new value shows up removes the need to manually refresh a checker page every ten minutes.

The privacy angle: what your TTL and resolver choices reveal

DNS lookups, by default, aren't private — whoever operates the resolver you're querying (your ISP, most commonly) can see every domain name you're looking up, even if the connection to the site itself is encrypted afterward. This is separate from TTL, but it's the question that naturally comes up once you start deliberately switching resolvers to troubleshoot caching, so it's worth answering honestly rather than leaving it hanging.

Switching to a public resolver to test whether a record has propagated, as suggested earlier in this article, means that specific query is now visible to whichever provider operates that public resolver instead of your ISP. That's a reasonable trade-off for a one-off troubleshooting query. If you're considering switching your default resolver permanently for privacy reasons, that's a bigger decision than anything covered in this article, and worth researching on its own terms rather than deciding it in the middle of a DNS caching problem.

When nothing works: the hard cases

Every method above assumes the system is behaving the way it's documented to behave. Sometimes it doesn't, and it's worth being honest about which situations actually need a different answer entirely.

It's been well past the old TTL and it's still wrong

First, double-check you're actually looking at the record you think you changed — a surprising number of "TTL isn't working" cases turn out to be a typo in the new value, or an edit that was saved in a different DNS zone than the one actually serving your domain. Query the record directly against a public resolver rather than trusting your browser's address bar; if the public query already shows the correct answer and only your own network still shows the old one, the problem has moved from "propagation" to "something on your own network is stubbornly cached" — check for a router-level DNS cache and a hosts file entry, both of which sit outside the flush commands covered earlier.

A resolver that simply ignores your TTL

Not every resolver honors TTL faithfully, and there's no way to force one that doesn't. This is a limit worth stating plainly rather than dancing around: some heavily loaded or aggressively caching networks can hold onto records longer than the TTL technically permits, purely to reduce their own query volume. If you've confirmed the record is correct and enough time has genuinely passed, and one specific network is still the holdout, the honest fix is switching the DNS resolver on that device or network to a different provider — you cannot reach into someone else's infrastructure and force a flush.

Long-lived connections that never re-check DNS at all

TTL only governs new lookups. A client with an already-open, long-lived connection — a persistent app session, a database connection pool, a video call — typically doesn't perform a fresh DNS lookup mid-session just because a TTL expired somewhere. If you've failed over to a new server and an existing session simply keeps talking to the old one until it naturally disconnects and reconnects, that's not a TTL problem to chase; it's a session-lifetime problem, and the fix is usually closing and reopening the connection, not waiting longer.

Frequently asked questions

What does TTL stand for in DNS?

Time To Live. It's the number of seconds a DNS record is allowed to be cached before whoever cached it has to ask the authoritative server again.

Is a lower TTL always better?

No. A lower TTL means changes take effect faster, but it also means far more repeated lookups hitting your authoritative server, since cached answers expire and get re-requested constantly. For a record that rarely changes — like most NS or MX records — a longer TTL is the sensible default; short TTLs are for records you expect to touch soon, or that are tied to health checks and failover.

Does flushing my own DNS cache fix it for other people too?

No. Flushing only affects the cache on the device you ran it on. It has zero effect on any other computer, phone, or resolver anywhere else, including a coworker sitting next to you on a different network.

Can I force someone else's DNS resolver to drop my old record early?

No. You have no access to, or control over, a resolver you don't operate. The only lever you control is the TTL you set on the record going forward, plus your own device's cache.

Why does one device show the new site while another still shows the old one?

Different devices, or devices on different networks, are very likely using different DNS resolvers, and each one cached your record at a different moment. Whichever one cached it earliest will keep showing the old answer the longest, since its countdown started first.

What TTL should I use for a normal A record?

Something in the range of a few minutes to an hour (300–3,600 seconds) is a reasonable middle ground for most day-to-day records, balancing update speed against unnecessary query load. If you're on Cloudflare with the record proxied, this is set for you automatically and can't be changed.

What TTL should I use right before a planned migration?

Lower it into the 60–300 second range well ahead of the actual change — ideally at least as long as the old TTL, so the short value has fully replaced the old one everywhere before you flip anything.

Does changing nameservers use the record's TTL, or something else?

Something else. Switching nameservers is governed by the NS record's own TTL, which registrars commonly cache for 24 to 48 hours — a separate, usually much longer, clock than whatever TTL is set on your individual A or CNAME records.

My TTL was already low before I made the change — why is it still slow?

A few possibilities worth checking in order: the record you edited might not be the one actually being queried (wrong zone, or a typo); a resolver on your own network might not be honoring TTL strictly; or you may be running into negative caching from an earlier failed lookup rather than a stale positive answer.

What is negative caching and why does it matter here?

It's a resolver remembering a "this record doesn't exist" answer, not just a successful one. That memory is controlled by the minimum TTL field in your domain's SOA record, separately from any individual record's own TTL — so a brand-new record can appear "missing" for a while even after you've created it correctly.

Does my browser keep its own separate DNS cache from Windows or macOS?

Yes, for Chromium-based browsers. Flushing the operating system's cache doesn't clear the browser's own host resolver cache — that needs to be cleared separately, for example through the browser's own internal diagnostics page.

How do I check what TTL a live record is actually serving right now?

Query it directly against a public resolver using a command-line tool like nslookup or dig. The response includes the record's remaining TTL in seconds at that moment, which tells you how much longer any resolver that just cached it will hold onto that answer.

Can my internet provider's resolver ignore my TTL and cache longer anyway?

It's possible, though not guaranteed to happen. Most resolvers respect the TTL faithfully, but you have no way to verify or control an ISP's caching behavior directly, and no way to force compliance if it doesn't.

Should I just set TTL to 0 or 1 second to be safe?

Generally, no. An extremely low TTL forces near-constant re-querying of your authoritative server for every single visitor, which adds load and latency for no ongoing benefit once your change has settled. It's a temporary tool for the window immediately around a planned change, not a permanent setting.

Does putting my site behind a CDN or a proxy change how TTL works?

The record pointing at the CDN still has its own TTL governing how fast that pointer updates — with some CDNs, like Cloudflare's proxied records, that TTL is fixed and not user-editable. Separately, the CDN itself may cache your actual page or file content for its own duration, which is a different setting entirely from DNS TTL and shouldn't be confused with it.

How long should I wait before assuming something is actually broken, not just caching?

Wait at least the full length of the old TTL that was live before your change — and for a nameserver switch specifically, budget up to 48 hours given how registrars commonly cache NS records. If you've confirmed via a direct public-resolver query that the record itself is correct, and that full window has passed with no change, the issue has likely moved from propagation into one of the hard cases covered above.

Revision note. Written September 2026. If you've been staring at a browser tab refreshing the same old page for the last hour, you're not doing anything wrong — you're just waiting on a clock that started ticking before you ever touched your DNS settings. See you on next post!