DNS Checker

What it does

DNS Checker queries authoritative and recursive DNS resolvers in multiple geographic regions simultaneously and reports the record values each resolver returns. It surfaces propagation lag, regional inconsistencies, and stale caches that a single-resolver lookup would miss, letting you confirm whether a recent DNS change has rolled out worldwide or is still in transit. To inspect every record type for a domain in one shot, use DNS Lookup; to verify mail-specific records, use MX Lookup.

When to use it

• You changed an A or CNAME record at your registrar and need to confirm the new value is visible to users on every continent before flipping production traffic.
• Customers in one country report your site is unreachable while everyone else loads it normally — you want to confirm whether their local resolver is serving a stale answer.
• You migrated email to a new provider and need every region to see the updated MX records before decommissioning the old mail server. Pair with MX Lookup for the full mail audit.
• You shortened the TTL ahead of a planned cutover and want to verify the lower TTL is now being honored everywhere.
• You're diagnosing a CDN failover and need to see which POP each region is being steered to. Reverse the returned IP with IP Lookup to confirm the AS path.

How to read the results

Each row shows the resolver location, the record value returned, and the remaining TTL in seconds. All resolvers returning the same value means propagation is complete. Mixed answers mean some resolvers still hold the old record in cache and will refresh when the TTL expires. A "no answer" or SERVFAIL response from one location usually points to a regional resolver outage rather than a problem with your zone. Once propagation is complete, run SSL Certificate Checker against the new host to confirm the certificate covers it.

Common mistakes

• Assuming propagation is "broken" when in fact you're inside the original TTL window — DNS caches are working as designed, you just have to wait the TTL out.
• Querying the apex (example.com) when the change was made to the www subdomain (or vice versa) and concluding nothing has propagated.
• Forgetting that your ISP, browser, and OS each cache DNS independently — a "stale" result locally doesn't mean public resolvers are stale.
• Comparing AAAA results when the record type isn't published; an empty IPv6 answer is correct, not a failure.
• Treating DNS as the only diagnostic surface — if the records look right but the site is still unreachable, also check HTTP Headers for redirect loops and SSL for certificate errors.