Propagation Studio A DNS Studio tool
Studio tools

How to flush your DNS cache

Clear the stale answer on your own machine — and know when the cache you need to clear is somewhere else entirely.

Flushing your DNS cache tells your computer to forget every DNS answer it has stored and look each name up fresh on next use. It is the right fix when your machine is holding a stale record after a change. It is the wrong fix — and a common source of confusion — when the stale answer lives in a resolver or cache you do not control. This guide gives the exact commands per platform and then explains where flushing actually helps.

What a flush does and does not do

Your operating system keeps a small local cache of recent DNS lookups so it does not re-query for every connection. Flushing empties that local cache. On the next lookup your machine asks its configured resolver again.

So if a change looks correct from your phone but wrong from your laptop, flush the laptop. If it looks wrong everywhere, the authoritative record or an upstream cache is the issue — check it from multiple locations with Propagation Studio rather than flushing local caches in a loop.

Windows

Open Command Prompt or PowerShell and run:

You should see "Successfully flushed the DNS Resolver Cache." To inspect what is cached before flushing, use ipconfig /displaydns. If entries return immediately and stubbornly, confirm the DNS Client service is running and that a VPN client is not layering its own resolver on top.

macOS

On modern macOS (10.11 El Capitan onward) run both commands together in Terminal — one clears the directory-services cache, the other nudges the multicast DNS responder:

You will be prompted for your password. There is no confirmation message; silence means success. Both halves matter: dscacheutil -flushcache alone does not always fully reset resolution, and signalling mDNSResponder is what makes the change take effect.

Linux

Linux has no single cache — it depends on what resolver runs locally, so identify yours first:

Many minimal Linux setups run no caching resolver at all, in which case there is nothing local to flush — every lookup already goes upstream.

Browsers

Browsers keep their own in-process DNS cache separate from the OS, so a page can stay stale even after an OS flush:

Public resolvers: purge upstream caches

When the stale copy sits in a big public resolver, the operators provide self-service purge tools that drop a name from their cache immediately rather than waiting out the TTL:

These only affect that one provider. You cannot purge your ISP's resolver — there you simply wait for the TTL to expire, which is exactly why lowering TTL before a change (see lowering TTL before a migration) beats flushing after the fact.

When flushing is not the answer

Reach for a different tool if:

In short: flush your own machine and browser when you know the change is correct upstream and you just want to see it now. For everything beyond your own device, TTL — not the flush command — is what sets the clock.

← Back to the propagation checker