DNS Cache: Why Record Changes Don't Show Up and How to Flush It

You've changed the A record, the DNS panel is saved too, but the site still comes up on the old IP. Or worse: it opens from mobile but not from the laptop. This situation almost always means one thing; somewhere between your browser and the authoritative server, an old copy of the DNS answer is sitting there and its TTL hasn't expired yet. The problem is that "somewhere" has several layers, and each layer is flushed with its own tool.

First, figure out which layer is giving the old answer

Before any flushing, you need to understand where the answer is coming from. If you don't rule this out, you're just guessing and you might spend hours clearing the browser cache while the problem is actually in the ISP resolver.

The main tool is dig. Run this:

dig +short example.com A
dig @1.1.1.1 +short example.com A
dig @8.8.8.8 +short example.com A

The first line asks your system's default resolver. The next two lines ask Cloudflare and Google directly. If the answer from the first line differs from the other two, your local cache or your ISP resolver is poisoned. If all three are the same but the browser shows something else, the problem is inside the operating system or the browser itself.

To see the remaining TTL, drop the +short:

dig example.com A | grep -A1 "ANSWER SECTION"

The number you see next to the record is the seconds remaining until the cache expires. If you see 3600 and your record's TTL was 3600, it means it was just cached right now and you need to wait. If the number is small and decreasing, the cache is in the process of expiring.

Layer one: browser cache

Browsers have their own DNS cache and operate independently of the operating system. Both Chrome and Firefox keep this cache, and normally it isn't cleared by closing the tab.

In Chrome, go to chrome://net-internals/#dns and click "Clear host cache". In Firefox, about:networking#dns and the Clear DNS Cache button. If you use Edge, the same Chrome address works with the edge:// prefix.

A point many people don't know: Incognito mode doesn't have a separate DNS cache and uses the same system cache. So if you think you're getting a clean test with a private window, you're mistaken.

Layer two: operating system cache

Every operating system has a local resolver that caches answers for all applications. This layer is usually what explains "it opens from mobile but not from the laptop".

On macOS, if your version is older than Big Sur, the command is different and you should run only sudo killall -HUP mDNSResponder. On Linux, if you don't have resolvectl, systemd-resolved is probably not installed and you should go for nscd. With systemctl status systemd-resolved you can make sure which one is active on the system.

On Windows, if you still get the old answer after ipconfig /flushdns, there's one more step: ipconfig /release and then ipconfig /renew. This also refreshes the DHCP lease, and if the DNS server came from DHCP, it may get a new value.

Layer three: ISP resolver

This is where the most confusion arises. Your ISP resolver (or the internal resolver of a corporate network) caches answers with its own TTL and you have no control over it. You can't call and tell them to flush their cache; usually such an option doesn't exist.

The practical solution is to temporarily bypass the ISP resolver. Try one of these two:

dig @9.9.9.9 +short example.com A
dig @1.1.1.1 +short example.com A

If the correct answer comes from these but not from the default resolver, the problem is definitely that layer. For a real test in the browser, temporarily change the system DNS to 1.1.1.1 and after confirming, change it back. Or if you want only one application to use a different DNS, on Linux with systemd-resolved you can define a specific server for a specific domain.

Here's where people make a mistake: many people, after changing the record, immediately set the TTL to 300 seconds and think the problem is solved. But the new TTL only applies to subsequent answers; the record that's sitting right now in the ISP resolver cache with the old TTL of 86400 remains until the end of that same amount. The sign of this is that after several hours, some users still see the old site and some see the new site. If you know you have a migration tomorrow, lower the TTL a day before, not on the migration day.

Layer four: public resolvers

Google, Cloudflare, and Quad9 also have caches, but their behavior differs from ISPs. These usually respect your record's TTL, and if you've shortened the TTL, they refresh quickly. The main problem here is that many users use these resolvers, and if your record is sitting in their cache with the old value, a significant percentage of your traffic still goes to the old server.

The good news is that you can test this layer and make sure. If dig @8.8.8.8 gives the correct answer, it means Google has refreshed and the rest of the users will refresh soon too. If not, it just needs patience.

When the problem really isn't DNS

Sometimes you flush all these layers and the old site still comes up. In this case, two possibilities remain that are thought about less.

First, server-side cache. If you use a CDN or reverse proxy, that layer also keeps the old version of the page and has nothing to do with DNS. Second, application cache. If you work with WordPress and have a cache plugin, the old page may be served from the plugin's own cache. For these cases, a WordPress plugin audit helps you figure out which plugin is responsible for caching and whether it's even necessary.

A quick way to separate these two cases: look at the headers with curl -I https://example.com. If you see X-Cache: HIT or similar, the problem isn't DNS and you should flush the application-layer cache. If the headers are fresh but the browser shows something else, go back to the first and second layers.

The right way to test after every change

The order matters. If you don't follow this order, you may flush one layer several times and get no result.

1. First, with dig @1.1.1.1, make sure the record on the authoritative server is correct. If it's wrong here, no flushing will help.
2. Then flush the operating system cache and run dig again.
3. Then flush the browser cache and test in a fresh tab.
4. Finally, if the problem persists, temporarily change the system DNS to bypass the ISP resolver.

For a quicker check, you can use ServerNet's free tools to test DNS and check the server response; these look from several different geographic locations and show the differences between resolvers better.

Another practical point: if you work on your own server and want to see what the server sees, run dig from inside the server itself. If your server is on Linux hosting, this few-second test gives an answer and often shows the problem isn't on your side at all.

When waiting is the right thing to do

If your record's TTL was 86400 seconds (one day) and you just changed it now, no command in the world can flush the ISP resolver cache earlier than scheduled. In this case, waiting is the only way and anything else is a waste of time. The only exception is if you can temporarily direct users' DNS to another resolver, which is practically impossible for a public site.

The main lesson is: lower the TTL before the migration, not after. If you do this one thing, most of the DNS cache headaches go away.

Frequently asked questions

Why does the site still load the old version after changing the DNS record?

Because the old answer remains in one of the four cache layers: browser, operating system, ISP resolver, or public resolver. Until that old copy's TTL expires, that layer gives the same answer. With dig @1.1.1.1 you can figure out which layer is still old.

How do I flush the Windows DNS cache?

In Command Prompt with Administrator access, run the command ipconfig /flushdns. If it doesn't work, also try ipconfig /release and then ipconfig /renew. Note that this only flushes the operating system cache, not the browser cache and not the ISP resolver cache.

Does browser Incognito mode bypass the DNS cache?

No. Incognito mode doesn't have a separate DNS cache and uses the same operating system cache. If you want a clean test, you need to flush the system cache or test from another network with a different resolver.

What should I set the TTL to for an easy migration?

If you have a planned migration, lower the TTL to 300 seconds at least a day before, and after the migration and confirmation, return it to the previous value. If you lower the TTL on the migration day, the old record sitting in resolver caches with a long TTL remains until the end of that same period and nothing can be done.