💾 DNS Cache Checker

🔍 What Is a DNS Cache Checker?

A DNS cache checker queries a domain against multiple independent resolvers and reports what each one currently has stored — the resolved value and the remaining time-to-live on that cached entry. It exists specifically to answer a question that comes up constantly during DNS changes, troubleshooting, and migrations: "is this actually resolving correctly right now, or am I just seeing an old cached answer?" Because caching happens at several independent layers simultaneously, a single lookup from your own device often isn't enough to answer that question with confidence.

📜 How DNS Caching Actually Works

When a resolver looks up a domain for the first time, it walks the DNS hierarchy to find an authoritative answer, and then stores that answer locally for a duration specified by the record's TTL, measured in seconds. Every subsequent query for that same domain, from any client using that resolver, is answered directly from the cached copy — no fresh lookup — until the TTL expires, at which point the next query triggers a fresh authoritative lookup and the cycle repeats. This is what makes DNS fast at scale: without caching, every single web request would require a full recursive lookup.

📦 The Layers of DNS Caching

Caching doesn't happen in just one place — it happens independently at the browser level, the operating system level, and the recursive resolver level, each with its own cache, its own expiration logic, and no shared awareness of the others. A change that's already visible at the resolver level can still appear "stuck" on a specific device simply because that device's browser or OS cache hasn't yet expired its own separately-held copy.

🌐 Browser DNS Cache

Most modern browsers maintain their own internal DNS cache, separate from the operating system's, specifically to avoid the overhead of a full OS-level lookup for every navigation. Browser caches are typically short-lived and cleared automatically on restart, but they can still be a source of confusion during active troubleshooting — a browser showing an old result while a fresh command-line lookup on the same machine shows the new one is a classic symptom of exactly this layer being out of sync.

🖥️ Operating System DNS Cache

Windows, macOS, and most Linux distributions running a local resolver service each maintain their own system-wide DNS cache, sitting between individual applications and the network-configured resolver. This cache serves every application on the device, which means flushing it — see our Flush DNS Commands guide for the exact command per platform — clears stale entries for every app at once, not just the browser.

🌐 Recursive Resolver Cache

Beyond your own device, the recursive resolver your network is configured to use — your ISP's default, or a public resolver like Google or Cloudflare if manually configured — maintains its own independent cache, shared across every user of that resolver. This is the layer this tool directly queries, since it's often the most consequential one during a DNS migration: a change can be fully live at the authoritative nameserver while a widely-used public resolver is still serving a cached pre-change answer to potentially millions of users.

🏢 Authoritative Nameservers Don't Cache

It's worth being precise here: a domain's authoritative nameservers don't cache in the same sense — they're the definitive source of truth, always answering with the current configured record. Caching happens downstream of them, at every recursive resolver and client that queries them. This is exactly why checking directly against the authoritative nameserver, rather than a public resolver, is the fastest way to confirm a DNS change has actually taken effect at the source.

⌛ TTL Explained in Depth

TTL, or time-to-live, is a value in seconds attached to every DNS record, instructing any resolver that caches it exactly how long to keep serving that cached copy before checking again. A TTL of 3600 means a resolver that just cached the record won't check again for a full hour, regardless of how many other resolvers might have already picked up a more recent change. Lowering a TTL in advance of a planned migration is a deliberate, well-established practice specifically because it shrinks this caching window, making a subsequent change propagate to a fresher state faster once it happens.

❌ Negative Caching

Resolvers don't just cache successful answers — they also cache the fact that a lookup failed or that a particular record type doesn't exist for a domain, a behavior called negative caching, governed by a TTL specified in the domain's SOA record rather than the individual record's own TTL. This matters practically because a domain that briefly had no valid record during a misconfiguration can continue returning that same negative result for a period afterward, even once the record is correctly published, until the negative cache entry itself expires.

⚖️ DNS Propagation vs DNS Cache

These two terms get conflated constantly but describe different things. "DNS propagation" colloquially refers to the overall process of a change becoming visible across the internet, which is really just the combined effect of every individual resolver's cache expiring and re-fetching at its own pace. There's no separate "propagation mechanism" beyond caching itself — understanding TTL and caching behavior is functionally the same as understanding propagation, just described from a different angle.

🎯 Cache Hit vs Cache Miss

A cache hit occurs when a resolver already has a valid, non-expired answer stored and returns it immediately without contacting any other server. A cache miss occurs when no valid cached entry exists — either because it's the first-ever query for that domain at that resolver, or because a previously cached entry's TTL has expired — triggering a fresh recursive lookup all the way to the authoritative nameserver. Cache misses are inherently slower, which is the entire performance rationale behind caching in the first place.

⚠️ Cache Poisoning Overview

DNS cache poisoning refers to an attack where a malicious actor injects a forged record into a resolver's cache, causing it to serve an incorrect, attacker-controlled answer for a legitimate domain until the poisoned entry expires or is manually cleared. Modern defenses — including randomized query IDs and source ports, and DNSSEC validation where deployed — have significantly raised the difficulty of successful poisoning compared to DNS's early history, though it remains a recognized category of risk worth understanding conceptually even if this tool isn't itself a poisoning-detection utility. For validating cryptographic trust specifically, see our DNSSEC Checker.

🔒 DNS Cache Security

Beyond poisoning specifically, DNS caching intersects with security in several practical ways worth being aware of: a compromised or misconfigured resolver can serve stale or incorrect answers long after an underlying security issue is fixed, and organizations running their own internal caching resolvers should treat cache invalidation as part of their standard incident response process whenever a domain's records need to change urgently for security reasons.

⚙️ How This Tool Works

This page queries the A record for the domain you enter against three major DNS-over-HTTPS resolvers — Google, Cloudflare, and Quad9 — directly from your browser, in parallel, and displays each resolver's currently cached value alongside its reported TTL. Comparing these side by side is often enough to immediately spot whether a domain is in a consistent, fully-cached state or actively mid-propagation across different resolvers following a recent change.

📋 Step-by-Step Usage

📋 Testing Methodology & Local Commands

To check your own device's local cache directly — something this browser-based tool structurally cannot do — use your operating system's native lookup tools. On Windows, ipconfig /displaydns lists the current local resolver cache. On macOS, local DNS caching is largely handled transparently by the system's mDNSResponder process. On Linux systems using systemd-resolved, resolvectl statistics and related commands expose cache state. Full platform-specific instructions, including flush commands, are covered in our Windows DNS Cache, macOS DNS Cache, and Linux DNS Cache guides.

👤 Use Cases by Role

🏢 Enterprise & Developer Scenarios

Hosting providers and ISPs operating their own caching resolvers benefit from actively monitoring cache hit ratios and TTL distributions across their customer base as a standard performance-engineering practice, since cache efficiency directly affects both resolver load and average end-user latency. Support and QA engineers troubleshooting a "works on my machine" DNS discrepancy report frequently find the root cause is simply two machines querying resolvers with different cache states — a comparison tool like this one shortcuts a significant amount of otherwise confusing back-and-forth.

📊 Comparison Tables

⚡ Performance Considerations

Caching is fundamentally a performance optimization — without it, every DNS lookup would require a full recursive walk of the DNS hierarchy, adding meaningful latency to nearly every network request on the internet. Setting an appropriately long TTL for stable, rarely-changing records reduces both resolver load and end-user latency; the tradeoff, addressed elsewhere in this guide, is slower propagation whenever that record does eventually need to change.

🔒 Privacy Considerations

DNS caching itself has modest privacy implications worth noting: a resolver's cache reveals which domains have been recently queried by its user base in aggregate, and on a shared or multi-user system, a local DNS cache can, in principle, reveal recently visited domains to anyone else with access to that device. This is a separate concern from DNS leaks specifically — see our DNS Privacy guide for a broader treatment of DNS-related privacy exposure.

⚠️ Common Mistakes

• Assuming a local cache flush affects DNS resolution for anyone but yourself
• Forgetting to lower TTL in advance of a planned migration
• Not checking negative caching when a record briefly had a misconfiguration
• Comparing results from only one resolver during a migration and assuming it's representative
• Confusing "propagation isn't done" with an actual DNS misconfiguration

✅ Troubleshooting Checklist

• Check the record directly against the authoritative nameserver first
• Compare cached values across multiple independent public resolvers
• Confirm the TTL that was active before your most recent change
• Flush your own local cache only after confirming resolver-level state
• Allow time proportional to the previous TTL before escalating further

⚖️ Advantages & Limitations

📚 Technical Glossary

🎓 Expert Tips

🔗 More Ways to Investigate Your DNS

Check raw records directly with DNS Lookup, verify authoritative nameservers with NS Lookup, confirm DNSSEC deployment with DNSSEC Checker, and check for VPN DNS leaks with DNS Leak Test.