DNS Propagation Checker

A DNS propagation checker is a diagnostic tool that queries multiple recursive DNS resolvers around the world to determine whether a DNS record change has been picked up globally. When you update an A record, change MX records, or switch nameservers, the change takes effect immediately on your authoritative nameserver — but recursive resolvers worldwide continue serving their cached copy until the TTL (Time to Live) expires. A propagation checker shows you which resolvers have fetched the new record and which are still serving the old one.

Most propagation checkers stop there — a list of servers with green or red icons. DNSChkr goes further. Every result includes the remaining TTL countdown in real time, so instead of wondering “has it propagated yet?” you can see that a resolver in Frankfurt has 247 seconds of cache remaining while one in Singapore already fetched the new record 30 seconds ago. The cache freshness percentage tells you whether each resolver is serving a record that was just fetched (100% fresh) or one that is about to expire (close to 0%). This turns DNS troubleshooting from guesswork into precise, data-driven monitoring.

Any time you make a DNS change that affects production traffic, a propagation checker is the only way to confirm the change has taken effect globally. DNS changes are invisible — there is no deployment log, no webhook, and no notification from the thousands of recursive resolvers around the world. The only way to know is to query them directly.

The most common scenarios where propagation checking is critical: server migrations where you update A or AAAA records to point to a new IP address and need to confirm all regions see the new server before decommissioning the old one. Email provider switches (Google Workspace, Microsoft 365, Zoho) where incorrect MX records mean bounced emails and potential data loss. Nameserver changes when moving DNS hosting to providers like Cloudflare, AWS Route 53, or DNSimple — NS record changes are the highest-impact DNS update since they delegate authority for the entire domain. SSL certificate verification via CAA records, where certificate authorities check DNS before issuing certificates and stale CAA records can block issuance. And email authentication updates (SPF, DKIM, DMARC TXT records) where mismatched records across resolvers can cause intermittent delivery failures that are extremely difficult to diagnose without per-resolver visibility.

The term “DNS propagation” suggests that records spread outward across the internet like a broadcast. That is not how DNS works. DNS records do not propagate — they are cached. When you update a DNS record, the change takes effect immediately on your authoritative nameserver. The delay people call “DNS propagation” is actually the time it takes for cached copies to expire on recursive resolvers around the world, as defined by the caching model in RFC 1035.

Every DNS record carries a TTL (Time to Live) value measured in seconds. When a recursive resolver like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1 caches your record, it serves that cached response until the TTL expires. A resolver in Tokyo and one in London maintain completely independent caches that expire at different times based on when each one last queried the authoritative nameserver. There is no coordination between them. This is why changes appear to “roll out” gradually — each resolver independently refreshes on its own schedule. Understanding this distinction is what separates guessing from informed troubleshooting, and it is exactly the data that DNSChkr’s TTL countdowns and freshness percentages provide.

DNSChkr sends real DNS queries to recursive resolvers in over 30 locations across North America, Europe, Asia, South America, Africa, and Oceania. Each query is sent to the resolver’s actual recursive service — not to authoritative nameservers directly — so the results reflect what real users in each region would see. For every server, DNSChkr reports the resolved record value, the original TTL set by the authoritative nameserver, the remaining TTL on the cached copy, the cache freshness percentage, and the response time in milliseconds.

Results stream in real time over a WebSocket connection. As each resolver responds, its result appears immediately — the fastest servers (typically Cloudflare and Google) return within 10 to 50 milliseconds, while some regional ISP resolvers may take 200 to 500 milliseconds. A consistency percentage at the top shows what fraction of resolvers are returning the same answer. If you set an expected value in the advanced settings, results are also color-coded based on whether they match your target, making it easy to see at a glance which resolvers have picked up the change and which are still serving the previous record.

If DNSChkr shows that all 30+ resolvers have picked up your new record but your browser still shows the old one, the issue is almost certainly a local cache. DNS caching happens at multiple layers between your browser and the recursive resolver, and each layer must be cleared independently.

Your browser maintains its own internal DNS cache that is separate from the operating system cache. Chrome, Firefox, and Safari all cache DNS lookups internally for performance. Your operating system has a second cache layer. And if you use a local DNS forwarder (common on routers and corporate networks), that adds a third. To clear all layers: flush the OS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS, sudo systemd-resolve --flush-caches on Linux), restart your browser completely, and if possible restart your router. On Chrome specifically, you can clear the browser-level DNS cache at chrome://net-internals/#dns without restarting.