Release the DNS Cache: Where It Actually Lives and How to Clear Each Layer

ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, and sudo resolvectl flush-caches on modern Linux. Those clear the operating system’s cache — which is one of at least four layers holding an answer, and often not the one that is stale.

You changed a DNS record, it has been twenty minutes, and the old address is still being resolved. The instinct is to flush the local cache, and when that does not help, to flush it again.

The useful move is to work out which layer is actually holding the old answer first. There are four, they expire independently, and only two of them are yours to clear.

Table of contents

• The four layers
• Clearing each layer
• Why it is still wrong after flushing everything
• Things that look like DNS caching and are not
• Verifying a DNS change properly
• How this fits the rest of the stack
• FAQ

The four layers

1. The browser. Chrome and Firefox keep their own DNS cache, entirely separate from the OS. This is why a record can look stale in one browser and correct in another.
2. The operating system. The stub resolver on your machine, which is what flushdns and friends clear.
3. The recursive resolver. Your router, your ISP, or a public resolver such as 8.8.8.8. You cannot clear this one, and it honours the record’s TTL.
4. The TTL itself. The record says how long it may be cached. Until that expires everywhere, some resolvers will keep serving the old answer whatever you do locally.

That ordering matters, because people spend time on layer two when the problem is layer one or layer three.

Find out what is authoritative right now, bypassing every cache between you and the source:

dig +short example.com @8.8.8.8          # a public resolver's view
dig +short example.com @ns1.yourdns.com  # the authoritative nameserver
dig example.com | grep -A1 "ANSWER SECTION"  # with the remaining TTL

If the authoritative nameserver returns the new value and your machine does not, it is a caching problem and clearing helps. If the authoritative server still returns the old value, no amount of flushing will do anything — the change did not take effect at the registrar or DNS provider.

Clearing each layer

Windows:

ipconfig /flushdns
ipconfig /displaydns          # inspect what is cached
ipconfig /release             # release the DHCP lease (different thing)
ipconfig /renew

/release and /renew concern your IP address lease, not DNS. They frequently appear together in guides, and they solve a different problem.

macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Both lines are needed on any recent version. The first clears the directory service cache and the second restarts the resolver that actually answers queries.

Linux depends on what is running, which is the part guides usually skip:

# systemd-resolved (most modern distributions)
sudo resolvectl flush-caches
resolvectl statistics          # confirm the cache emptied

# dnsmasq
sudo systemctl restart dnsmasq

# nscd
sudo systemctl restart nscd

Many Linux desktops do not cache DNS at all. If none of those services are running, there is nothing local to flush and the stale answer is coming from your router or upstream resolver.

Browsers — visit chrome://net-internals/#dns and clear the host cache, or about:networking#dns in Firefox. Restarting the browser also works and is easier to remember.

Why it is still wrong after flushing everything

Because of the TTL, and it is not really a caching bug — it is the system behaving as designed.

When you publish a record with a TTL of 3600, you are instructing every resolver in the world to cache it for an hour. Changing the record does not reach out and invalidate those copies. They expire on their own schedule, and a resolver that fetched the old value 59 minutes ago will keep serving it for another minute; one that fetched it 5 minutes ago has 55 to go.

Check what you are dealing with:

dig example.com | grep -A1 "ANSWER SECTION"
# example.com.  3247  IN  A  203.0.113.10
#               ^^^^ seconds remaining on this resolver's copy

The professional habit is to plan for it. Before a planned migration, lower the TTL to 300 and wait for the old TTL to elapse fully. Then when you make the real change, the world converges in five minutes instead of a day. Raise it back afterwards, because a permanently low TTL means more queries and a harder dependency on your DNS provider being reachable.

Some resolvers also ignore very short TTLs and enforce a floor of their own, so 60 seconds is not meaningfully better than 300.

Things that look like DNS caching and are not

• The hosts file. An entry there overrides DNS entirely and no flush will touch it. Check /etc/hosts on Linux and macOS, or C:\Windows\System32\drivers\etc\hosts on Windows. This is the answer surprisingly often, usually from a debugging session someone forgot to undo.
• Browser HSTS. If a site sent an HSTS header, the browser forces HTTPS regardless of what you type. That looks like a stubborn cache and is a separate store — clear it at chrome://net-internals/#hsts.
• A CDN or proxy. DNS resolves correctly to the CDN, and the CDN serves cached content from the old origin. Purge at the CDN, not on your machine.
• Connection reuse. An open HTTP/2 connection keeps using the existing socket, and therefore the old IP, until it closes. A hard reload or a new browser session fixes it.
• DNS over HTTPS. If the browser is doing its own DoH resolution, it bypasses your OS resolver entirely — so flushing the OS cache genuinely cannot help.

That last one is increasingly common and worth checking early, because it makes every OS-level diagnostic misleading.

# does the system resolver agree with the browser?
dig +short example.com
nslookup example.com

Verifying a DNS change properly

Check from outside your own network before concluding anything, because your view is the least representative one available.

dig +short example.com @8.8.8.8      # Google
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9

Different resolvers cached at different moments, so seeing the new value on some and not others is normal mid-propagation and tells you the change is working its way through.

Trace the full delegation when something is genuinely broken rather than merely slow:

dig +trace example.com

That walks from the root servers down and shows exactly where the chain breaks — a missing delegation, a nameserver that does not answer, a mismatch between what the registrar publishes and what your DNS provider serves.

For certificate and domain changes specifically, remember that the DNS record is only half the job. A record pointing at a host that has no certificate for that name gives you a TLS error, not a DNS error, and flushing caches will not help with that either.

How this fits the rest of the stack

DNS is a caching system with no invalidation, which is why every fix is really about waiting for the right thing to expire. The layers that matter are the ones you do not control, and the only real lever is the TTL you set before you make the change.

This is one reason domain and certificate handling is worth having managed rather than assembled. RunxBuild handles custom domains and certificates for static sites and services, so pointing a domain at a deploy does not also mean coordinating a certificate issuance against a record that has not propagated yet. If you are working out what a site with a custom domain, a backend service and a database comes to, the RunxBuild hosting calculator lists them separately.

Useful related references:

• What Does Flushing DNS Do? Clearing the Local Cache of Stale Answers
• Clear the DNS Cache on macOS: The One Command, and Why You Rarely Need It
• Clear DNS Cache on Mac: The Command, and Why It Usually Is Not the Problem
• Custom domains and certificates on RunxBuild

FAQ

Why is my DNS still wrong after flushing the cache?

Because you cleared your machine’s cache, not your ISP’s resolver or the record’s TTL. Every resolver that fetched the old value keeps it until the TTL expires. Check the remaining time with dig example.com and look at the number in the answer section.

What is the difference between ipconfig /flushdns and /release?

/flushdns clears the DNS resolver cache. /release gives up your DHCP-assigned IP address, which is unrelated to name resolution. They appear together in a lot of guides but solve different problems.

How do I clear the DNS cache on Linux?

It depends on what is running. sudo resolvectl flush-caches for systemd-resolved, or restart dnsmasq or nscd if you use those. Many Linux systems do not cache DNS locally at all, in which case the stale answer is coming from your router or upstream resolver.

How long does DNS propagation take?

As long as the previous record’s TTL, since that is what you instructed resolvers to cache. Lower the TTL to 300 seconds and wait a full old-TTL period before making a planned change, then the switch converges in about five minutes rather than up to a day.

Why does the site resolve correctly in one browser but not another?

Browsers keep their own DNS cache separate from the operating system, and some perform DNS over HTTPS independently of your system resolver. Clear it at chrome://net-internals/#dns or about:networking#dns, or just restart the browser.