--- title: "DNS Cache Explained: How to Flush and Clear It" description: Learn what a DNS cache is and how to flush DNS cache, clear DNS cache, and fix connection issues across devices. image: https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-11-35-35-7799-PM.jpeg --- [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜Learn โ–พ](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [CDN Fundamentals](https://blog.blazingcdn.com/cdn-fundamentals?hsLang=en-us) [By Content Type](https://blog.blazingcdn.com/by-content-type?hsLang=en-us) [Advanced Concepts](https://blog.blazingcdn.com/advanced-concepts?hsLang=en-us) [Glossary](https://blog.blazingcdn.com/glossary?hsLang=en-us) [โšก Web Performance](https://blog.blazingcdn.com/web-performance?hsLang=en-us) [๐ŸŽฌVideo & Streaming โ–พ](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿ”ด Live Streaming](https://blog.blazingcdn.com/live-streaming?hsLang=en-us) [๐Ÿ“บ VOD & OTT](https://blog.blazingcdn.com/vod-ott?hsLang=en-us) [๐Ÿ’ฐ Bandwidth & Costs](https://blog.blazingcdn.com/bandwidth-costs?hsLang=en-us) [๐Ÿญ Other Industries โ–พ](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ“บ Media & Broadcasting](https://blog.blazingcdn.com/media-broadcasting?hsLang=en-us) [๐Ÿ’พ Software & SaaS](https://blog.blazingcdn.com/software-saas?hsLang=en-us) [๐Ÿ—๏ธ DevOps & Cloud Infra](https://blog.blazingcdn.com/devops-cloud-infra?hsLang=en-us) [๐Ÿ“š AdTech & Advertising](https://blog.blazingcdn.com/adtech-advertising?hsLang=en-us) [๐ŸŽฎ Gaming & Esports](https://blog.blazingcdn.com/gaming-esports?hsLang=en-us) [๐Ÿ“ฑ Mobile Apps & Developers](https://blog.blazingcdn.com/mobile-apps-developers?hsLang=en-us) [๐Ÿค– AI & Machine Learning](https://blog.blazingcdn.com/ai-machine-learning?hsLang=en-us) [๐Ÿ›๏ธ Enterprise & Corporate](https://blog.blazingcdn.com/enterprise-corporate?hsLang=en-us) [๐Ÿ“š E-Learning & EdTech](https://blog.blazingcdn.com/e-learning-edtech?hsLang=en-us) [๐ŸŸ๏ธ Sports & Live Events](https://blog.blazingcdn.com/sports-live-events?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs โ–พ](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [Provider Pricing](https://blog.blazingcdn.com/provider-pricing?hsLang=en-us) [Cost Optimization](https://blog.blazingcdn.com/cost-optimization?hsLang=en-us) [Decision Support](https://blog.blazingcdn.com/decision-support?hsLang=en-us) [โšกCompare โ–พ](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [Provider Comparisons](https://blog.blazingcdn.com/provider-comparisons?hsLang=en-us) [Strategy Comparisons](https://blog.blazingcdn.com/strategy-comparisons?hsLang=en-us) [Ratings & Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ”’ Security โ–พ](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [Attack Protection](https://blog.blazingcdn.com/attack-protection?hsLang=en-us) [Encryption & Access](https://blog.blazingcdn.com/encryption-access?hsLang=en-us) [Video & DRM Security](https://blog.blazingcdn.com/video-drm-security?hsLang=en-us) [๐Ÿ“ Case Studies](https://blog.blazingcdn.com/case-studies?hsLang=en-us) [๐Ÿ”Œ Integrations](https://blog.blazingcdn.com/integrations?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [Get Started](https://blazingcdn.com/sign-up-contact-form/) [Learn](https://blog.blazingcdn.com/en-us/tag/learn) # DNS Cache Explained: How to Flush and Clear It Vadym Borovskyi Nov 2, 2026, 12:37:45โ€ฏAM ![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-11-35-35-7799-PM.jpeg) Your DNS cache holds every resolved record until its TTL (time to live) runs out. After a DNS or CDN change, you fix stale answers in two moves: flush each cache layer between you and the authoritative name server, then confirm that the answer you get matches the one that server publishes. On Windows the command is **ipconfig /flushdns**. On macOS it is **sudo dscacheutil -flushcache** followed by **sudo killall -HUP mDNSResponder**. On systemd Linux it is **sudo resolvectl flush-caches**. Plan on about 10 minutes for the full playbook, validation included. As of 2026, the Windows DNS Client service caps positive cache entries at 86,400 seconds (one day) and negative answers at 900 seconds (15 minutes) by default, and every other layer applies its own limits on top. Flushing your machine clears only your local stub cache. Recursive resolvers keep serving the old record until the TTL they received from the authoritative server expires. ## **What the DNS cache stores and where it lives** A DNS cache stores resolved resource records (A, AAAA, CNAME, and so on) together with a countdown that starts at the record's TTL. It also stores negative answers. Per RFC 2308, an NXDOMAIN or empty answer is cached for the shorter of the SOA record's TTL and its minimum field. That is why a hostname you created five minutes ago can keep failing on a machine that queried it before it existed. Between a browser tab and your authoritative zone there are usually four to six independent caches: - **Application or runtime cache**: browsers keep their own host cache, and the JVM caches lookups inside the process. Node.js and Go's pure resolver do not cache by default, so they lean on the OS. - **OS stub resolver cache**: the Windows DNS Client service, mDNSResponder on macOS, and systemd-resolved, nscd or dnsmasq on Linux. - **Local network resolver**: home routers, office forwarders, and Kubernetes CoreDNS with its cache plugin. - **Recursive resolver**: your ISP, corporate resolvers, or public services such as Google Public DNS and Cloudflare's 1.1.1.1. - **Authoritative server**: the source of truth. It caches nothing for your zone, but secondaries can lag on zone transfers. TTL-respecting caches hand downstream the remaining TTL, not the original, so their staleness does not stack. Caches that impose a fixed hold time regardless of TTL do stack, and those are the ones that surprise people after a cutover. ## **How TTLs decide how long stale records survive** After a DNS change, worst-case staleness equals the old record's TTL at the recursive layer, plus any fixed-duration cache below it that grabbed the record just before expiry. A 300-second TTL with a browser that holds entries for 60 seconds gives a ceiling near 360 seconds, not 300. The table below is this blog's staleness budget for a client behind a public recursive resolver, worked from documented defaults. Use it to predict how long you will wait if you do nothing, and which layer to flush to shorten that wait. | Layer | Hold behavior (defaults) | Adds to staleness? | Worst case with old TTL 300 s | | --- | --- | --- | --- | | Recursive resolver | Respects TTL; some apply a minimum floor | Base value | 300 s | | OS stub (Windows, macOS, systemd-resolved) | Respects remaining TTL; Windows caps at 86,400 s | No | 300 s | | Firefox (native resolver) | Fixed hold, network.dnsCacheExpiration default 60 s | Yes | 360 s | | JVM (no security manager) | Fixed 30 s unless networkaddress.cache.ttl is set | Yes | 330 s | | Long-lived connections (HTTP/2 keep-alive, connection pools) | No re-resolution until the connection closes | Yes, unbounded | Minutes to hours | The longest tail after a DNS change usually comes from pooled connections that never re-resolve, not from any DNS cache, so restarting the client often matters more than flushing it. ## **How to flush DNS cache on Windows, macOS and Linux** ### Prerequisites - Admin rights on the machine: an elevated prompt on Windows, sudo on macOS and Linux. - The dig utility for validation (bundled on macOS and in bind-utils or dnsutils on Linux). On Windows, Resolve-DnsName in PowerShell does the same job. - The hostname you changed, written below as **YOUR\_HOSTNAME** (for example, cdn.example.com), and the expected new value, written as **EXPECTED\_VALUE** (the new CNAME target or IP). ### Step 1: Confirm the authoritative answer first Flushing is pointless if the authoritative server still publishes the old record. Find your zone's name servers with **dig YOUR\_HOSTNAME NS +short**. If YOUR\_HOSTNAME is not the zone apex, query the apex domain instead. Then ask one of them directly, with recursion off: **dig @NS\_HOSTNAME YOUR\_HOSTNAME +norecurse +noall +answer**, where NS\_HOSTNAME is one of the name servers returned. Why: if this answer is not EXPECTED\_VALUE, the problem is your zone or a lagging secondary, and no flush will help. Query every listed name server, because a secondary that missed a zone transfer serves the old record to a share of resolvers. ### Step 2: Clear DNS cache on Windows From an elevated Command Prompt, run **ipconfig /flushdns**. In PowerShell, the equivalent is **Clear-DnsClientCache**. To inspect the cache before or after, run **ipconfig /displaydns** or **Get-DnsClientCache -Entry YOUR\_HOSTNAME**. Why: the DNS Client service caches positive answers for up to 86,400 seconds and negative answers for up to 900 seconds. The negative cache is the usual culprit when a brand-new hostname will not resolve. Entries from the hosts file show up in the cache too, and flushing does not remove them, so check that file if a stale value persists. ### Step 3: Flush the DNS cache on macOS Run **sudo dscacheutil -flushcache**, then **sudo killall -HUP mDNSResponder**. The second command does the real work on current macOS releases, because mDNSResponder owns the resolver cache. The HUP signal tells it to drop that cache without a restart. Why both: dscacheutil clears the Directory Services cache, which some lookups still pass through. Running the pair costs nothing and covers every macOS version still in support. ### Step 4: Clear DNS cache on Linux Linux has no single cache, so first identify what is running. On systemd distributions, **resolvectl status** confirms systemd-resolved is active. Then flush with **sudo resolvectl flush-caches** and confirm with **resolvectl statistics**, where the current cache size should read zero. For other stacks: - **nscd**: **sudo nscd -i hosts** invalidates the hosts table. - **dnsmasq**: **sudo pkill -HUP dnsmasq** clears its cache, and **sudo systemctl restart dnsmasq** also works. - **Unbound** (local or on your resolver): **sudo unbound-control flush YOUR\_HOSTNAME**, or **sudo unbound-control flush\_zone example.com** for a whole zone. - **BIND** recursive servers: **sudo rndc flushname YOUR\_HOSTNAME**. Why: many minimal server images run no local cache at all, so every lookup goes straight to the recursive resolver. If none of the above is running, there is nothing local to flush. ### Step 5: How to clear DNS cache in Chrome, Firefox and Safari Chrome and Edge keep a host cache separate from the OS. Open chrome://net-internals/#dns (or edge://net-internals/#dns) and click "Clear host cache". Then go to the Sockets page on the same tool and click "Flush socket pools", so existing connections to the old IP are closed. Without that second click, the browser keeps using connections it already has open. In Firefox, open about:networking#dns and click "Clear DNS Cache". Safari has no separate DNS cache and relies on mDNSResponder, so Step 3 covers it. Quit and relaunch Safari to drop pooled connections. ### Step 6: Clear runtime and resolver caches A JVM caches successful lookups for 30 seconds by default, or forever if a security manager is installed. The only way to clear that cache is a process restart. To bound it going forward, set networkaddress.cache.ttl to 60 in the JDK's java.security file. For recursive resolvers you do not control, Google Public DNS and Cloudflare's 1.1.1.1 both provide a public cache purge page for a single name. ISP resolvers offer nothing comparable, so they simply wait out the TTL. ## **Validate the change after a DNS cache clear** Run **dig YOUR\_HOSTNAME +noall +answer** twice, a few seconds apart. The second column is the remaining TTL. If it decreases between runs, you are reading from a cache. If it equals the full TTL from Step 1 and the value is EXPECTED\_VALUE, the recursive layer has fresh data. To compare resolvers, run **dig @1.1.1.1 YOUR\_HOSTNAME +noall +answer** and **dig @8.8.8.8 YOUR\_HOSTNAME +noall +answer**. On Windows, run **Resolve-DnsName YOUR\_HOSTNAME -Server 1.1.1.1**. To confirm traffic actually reaches the new CDN, open browser developer tools, reload with the cache disabled, and check the remote address and any provider-specific response headers on the asset request. ## **Rollback after a bad DNS or CDN change** Rolling back is the same change in reverse, and it is bound by the same TTL. If you raised the TTL as part of the change, every resolver that cached the bad record holds it for that full duration. That is why the TTL stays low until the new state is proven. Revert the record at the authoritative server, re-run Step 1 against every name server, then flush the layers you control. For internal clients, flush the forwarders and recursive servers you operate (Unbound or BIND, as in Step 4) before touching any endpoint. One recursive flush fixes every client behind it. ## **Failure modes: symptom, cause, fix** - **Symptom**: the new hostname returns NXDOMAIN on one machine only. **Cause**: a negative cache entry from a query made before the record existed. **Fix**: flush the OS cache. If the failure is resolver-wide, wait out the SOA minimum or purge at the public resolver. - **Symptom**: dig shows the new IP, but the browser still hits the old CDN. **Cause**: browser host cache or pooled HTTP/2 connections. **Fix**: clear the host cache and flush socket pools (Step 5), or restart the browser. - **Symptom**: services still call the old endpoint hours after the change. **Cause**: a JVM with a security manager caching forever, or connection pools with no maximum lifetime. **Fix**: roll-restart the service, then set networkaddress.cache.ttl and a pool connection max-age. - **Symptom**: some users get the old record, others the new one. **Cause**: a lagging secondary authoritative server, or ISP resolvers enforcing a minimum TTL floor. **Fix**: query every name server directly, and check the zone serial on each. - **Symptom**: flushing has no effect at all. **Cause**: a hosts file entry, or a VPN pushing its own resolver. **Fix**: check the hosts file, and confirm which server answers with resolvectl status or ipconfig /all. ## **Tuning TTLs before your next CDN cutover** The cheapest flush is the one you never need. A proven sequence: at least one old-TTL period before the change, drop the record's TTL to 60 seconds. With a 3,600-second TTL, do this an hour or more ahead. With 86,400 seconds, a full day ahead. Make the change, verify it, then raise the TTL back to 300 to 3,600 seconds once the new state has held through your peak traffic. The trade-off is real. A 60-second TTL multiplies query volume to your authoritative provider and adds a resolver round trip for more users, typically tens of milliseconds on a cache miss. It also makes you more exposed to an authoritative outage, because resolvers run out of cached answers within a minute. Keep low TTLs for the change window, not as a permanent setting. For CDN migrations specifically, a weighted DNS split avoids an all-at-once cutover: shift 5, then 25, then 100 percent of resolutions while caches drain. BlazingCDN can run as a second CDN behind DNS with a weighted traffic split, which is the setup described on its [**multi-CDN integration page**](https://blazingcdn.com/multi-cdn-integration/). ## **FAQ: flushing and clearing the DNS cache** ### Does flushing the DNS cache change what other users see? No, flushing the DNS cache on your machine affects only your own stub resolver and browser. Other users keep receiving whatever their recursive resolver has cached until the TTL it received from the authoritative server expires. To influence many clients at once, flush a recursive resolver you operate, or use the public purge pages offered by Google Public DNS and Cloudflare's 1.1.1.1. ### Does a DNS cache clear affect other users on my network? A DNS cache clear on one laptop does not affect anyone else on the same network. Shared caches live on the router, the office forwarder or the recursive resolver, and each must be flushed separately. On a home router, a reboot usually clears its forwarder cache. On Unbound or BIND, use unbound-control flush or rndc flushname for the specific hostname. ### How long does a DNS change take to reach everyone without a flush? Without a flush, a DNS change reaches everyone after roughly the old record's TTL, plus any fixed-duration cache below the resolver. With a 300-second TTL, expect about 5 to 6 minutes for browsers. Some ISP resolvers enforce minimum TTL floors, and long-lived HTTP connections can keep traffic on the old IP until they close, which stretches the tail further. ### Why does Chrome ignore my DNS cache flush on Windows? Chrome keeps its own host cache and pooled connections, so running ipconfig /flushdns alone does not reset it. Open chrome://net-internals/#dns and clear the host cache, then flush socket pools on the Sockets page. Existing HTTP/2 connections stay pinned to the old IP until they close, which is why a browser restart often appears to fix the problem. ## **Measure your own DNS staleness budget before the next cutover** This week, pick one non-critical hostname, lower its TTL to 60 seconds, and change its target. Then time three things: when dig against two public resolvers returns the new value, when a fresh browser profile reaches it, and when your longest-running service stops calling the old endpoint. The gap between the first and last numbers is your real staleness budget. It also points at the connection pools and runtime caches that need a max-age before any production DNS or CDN migration. If that cutover moves heavy video, software or file traffic to a new delivery layer, the BlazingCDN features page lists what every plan includes, from origin shield and purge to Prometheus metrics: [**BlazingCDN delivery features for DNS-based migrations**](https://blazingcdn.com/features/). Share: [f](https://www.facebook.com/sharer/sharer.php?u=https://blog.blazingcdn.com/en-us/dns-cache-explained-how-to-flush-and-clear-it) [in](https://www.linkedin.com/sharing/share-offsite/?url=https://blog.blazingcdn.com/en-us/dns-cache-explained-how-to-flush-and-clear-it) [๐•](https://twitter.com/intent/tweet?url=https://blog.blazingcdn.com/en-us/dns-cache-explained-how-to-flush-and-clear-it&text=) [โœ‰](mailto:?subject=%3Cspan%20id="hs_cos_wrapper_name"%20class="hs_cos_wrapper%20hs_cos_wrapper_meta_field%20hs_cos_wrapper_type_text"%20style=""%20data-hs-cos-general-type="meta_field"%20data-hs-cos-type="text"%20%3EDNS%20Cache%20Explained:%20How%20to%20Flush%20and%20Clear%20It%3C/span%3E&body=https://blog.blazingcdn.com/en-us/dns-cache-explained-how-to-flush-and-clear-it) ![BlazingCDN](https://blog.blazingcdn.com/hs-fs/hubfs/Logo/blog-logo-w.png?height=24&name=blog-logo-w.png) *Heavy traffic.* Light bill. The CDN for video and large traffic Their monthly bill vs ours - 20 TBFastly $2,087**$92.50** - 50 TBCDN77 $990**$215** - 200 TBCloudFront $11,965**$765** Published list prices, Aug 2026 [Calculate your cost](https://blazingcdn.com/cdn-cost-calculator/?utm_source=blog&utm_medium=sidebar&utm_campaign=blog_sidebar&utm_content=compare_calc) ## Related posts [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-11-25-16-1640-PM.jpeg)](https://blog.blazingcdn.com/en-us/amazon-cloudfront-vs-blazingcdn-price-performance?hsLang=en-us) Pricing - Pricing & Costs ### [Amazon CloudFront vs BlazingCDN: Price & Performance](https://blog.blazingcdn.com/en-us/amazon-cloudfront-vs-blazingcdn-price-performance?hsLang=en-us) Evaluated November 2026, list prices as checked August 2026. In a CloudFront vs BlazingCDN comparison, pay-as-you-go ... Nov 2, 2026, 12:28:53โ€ฏAM [Read more](https://blog.blazingcdn.com/en-us/amazon-cloudfront-vs-blazingcdn-price-performance?hsLang=en-us) [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-10-55-16-2638-PM.jpeg)](https://blog.blazingcdn.com/en-us/top-cdn-alternatives-to-akamai-and-cloudfront?hsLang=en-us) Compare ### [Top CDN Alternatives to Akamai and CloudFront in 2026](https://blog.blazingcdn.com/en-us/top-cdn-alternatives-to-akamai-and-cloudfront?hsLang=en-us) Akamai publishes no CDN price list, and Amazon CloudFront charges $6,965 for 100 TB of pay-as-you-go transfer before ... Nov 1, 2026, 11:58:20โ€ฏPM [Read more](https://blog.blazingcdn.com/en-us/top-cdn-alternatives-to-akamai-and-cloudfront?hsLang=en-us) [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜ Learn](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐ŸŽฌ Video & Streaming](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿญ Industries](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [โšก Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [๐Ÿ”’ Security](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [โœ๏ธ Publish with us](https://blog.blazingcdn.com/publish-with-us?hsLang=en-us) in f ๐• โœ‰ Copyright ยฉ BlazingCDN |. All rights reserved. ```json { "@context" : "https://schema.org", "@id" : "https://blazingcdn.com/#organization", "@type" : "Organization", "description" : "High-volume CDN for video, live streaming, OTT/IPTV, software, games, SaaS and large-file delivery.", "logo" : { "@id" : "https://blazingcdn.com/#logo", "@type" : "ImageObject", "height" : 560, "url" : "https://blazingcdn.com/wp-content/uploads/2024/08/logo-560-560.png", "width" : 560 }, "name" : "BlazingCDN", "sameAs" : [ "https://www.linkedin.com/company/blazingcdn", "https://x.com/BlazingCdn", "https://www.reddit.com/r/BlazingCDN/", "https://www.wikidata.org/wiki/Q141711074" ], "url" : "https://blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/#website", "@type" : "WebSite", "inLanguage" : "en-US", "name" : "BlazingCDN Blog", "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "url" : "https://blog.blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/dns-cache-explained-how-to-flush-and-clear-it#article", "@type" : "BlogPosting", "author" : { "@id" : "https://blog.blazingcdn.com/en-us/author/blazingcdn#person", "@type" : "Person", "description" : "Vadym Borovskyi is Chief Product and Marketing Officer at BlazingCDN, where he has led product strategy and growth since 2021. He has more than 11 years of experience in IT product management and B2B marketing. On this blog he writes about CDN pricing and egress costs, video and software delivery, cache configuration, and how teams evaluate and switch CDN providers. He is based in Warsaw, Poland.", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/vadym-borovskyi.jpg", "jobTitle" : "Chief Product and Marketing Officer", "knowsAbout" : [ "Content Delivery Networks (CDN)", "CDN pricing", "Video streaming delivery", "Software and game distribution", "Cache optimization", "Product Management", "B2B Marketing", "Digital Marketing", "Pay Per Click Marketing (PPC)", "Google Ads", "Search Engine Marketing (SEM)", "Marketing Strategy", "Artificial Intelligence (AI)", "Cloud Management", "SaaS Development", "IT Consulting", "Computer Networking", "Project Management", "Startups" ], "name" : "Vadym Borovskyi", "sameAs" : [ "https://www.linkedin.com/in/axelt/" ], "url" : "https://blog.blazingcdn.com/en-us/author/blazingcdn", "worksFor" : { "@id" : "https://blazingcdn.com/#organization" } }, "dateModified" : "2026-11-01T23:37:45Z", "datePublished" : "2026-11-01T23:37:45Z", "description" : "Learn what a DNS cache is and how to flush DNS cache, clear DNS cache, and fix connection issues across devices.", "headline" : "DNS Cache Explained: How to Flush and Clear It", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/Gemini-Blog/image-Nov-01-2026-11-35-35-7799-PM.jpeg", "inLanguage" : "en-us", "isPartOf" : { "@id" : "https://blog.blazingcdn.com/#website" }, "mainEntityOfPage" : { "@id" : "https://blog.blazingcdn.com/en-us/dns-cache-explained-how-to-flush-and-clear-it", "@type" : "WebPage" }, "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "wordCount" : 2404 } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/dns-cache-explained-how-to-flush-and-clear-it#breadcrumb", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us/dns-cache-explained-how-to-flush-and-clear-it", "name" : "DNS Cache Explained: How to Flush and Clear It", "position" : 2 } ] } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/dns-cache-explained-how-to-flush-and-clear-it#faq", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "No, flushing the DNS cache on your machine affects only your own stub resolver and browser. Other users keep receiving whatever their recursive resolver has cached until the TTL it received from the authoritative server expires. To influence many clients at once, flush a recursive resolver you operate, or use the public purge pages offered by Google Public DNS and Cloudflare's 1.1.1.1." }, "name" : "Does flushing the DNS cache change what other users see?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "A DNS cache clear on one laptop does not affect anyone else on the same network. Shared caches live on the router, the office forwarder or the recursive resolver, and each must be flushed separately. On a home router, a reboot usually clears its forwarder cache. On Unbound or BIND, use unbound-control flush or rndc flushname for the specific hostname." }, "name" : "Does a DNS cache clear affect other users on my network?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Without a flush, a DNS change reaches everyone after roughly the old record's TTL, plus any fixed-duration cache below the resolver. With a 300-second TTL, expect about 5 to 6 minutes for browsers. Some ISP resolvers enforce minimum TTL floors, and long-lived HTTP connections can keep traffic on the old IP until they close, which stretches the tail further." }, "name" : "How long does a DNS change take to reach everyone without a flush?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Chrome keeps its own host cache and pooled connections, so running ipconfig /flushdns alone does not reset it. Open chrome://net-internals/#dns and clear the host cache, then flush socket pools on the Sockets page. Existing HTTP/2 connections stay pinned to the old IP until they close, which is why a browser restart often appears to fix the problem." }, "name" : "Why does Chrome ignore my DNS cache flush on Windows?" } ] } ```