WhatsMyDNS Alternatives: DNS Propagation Checker

WhatsMyDNS.net is a popular DNS propagation checker: has a record (A, CNAME, MX, TXT) updated on public resolvers around the world. Useful after moving hosting, changing an IP or updating mail settings. Its focus is Western resolvers with no adjacent DNS tooling on the page.

Honestly: WhatsMyDNS has more global check points (20+ locations). If you need the widest possible geographic spread, it covers more countries.

• You changed hosting/IP and want to verify propagation with RU/CIS resolvers included;
• You want to inspect all records via DNS Lookup at the same time.

• DNSChecker.org — similar check, many locations;
• dig / nslookup — terminal, but only your own resolver;
• Google Dig (toolbox) — checks via Google's resolver.

Nothing propagates. There is no wave of updates travelling across the internet. What actually happens is narrower and easier to reason about: every recursive resolver that previously answered a query for your name cached that answer, and it will keep serving the old value until the TTL it was given expires. Independently of every other resolver.

That single fact explains everything people find confusing about these tools:

• Different locations show different answers. Not a partial rollout — those resolvers cached at different moments, so their TTLs expire at different moments.
• You cannot speed it up after the change. The TTL that governs the wait was attached to the old record, and it was handed out before you edited anything. Lowering TTL now affects the next change, not this one.
• «48 hours» is folklore. The real ceiling is the old record's TTL. If it was 300 seconds, you wait five minutes. If someone set 86400, you wait a day — and no tool and no support ticket shortens it.

So a propagation checker does not measure progress. It samples the cache state of a fixed set of public resolvers at this moment — useful, but a different thing from what the name suggests.

The wait is decided before you make the change, not after. The sequence that removes it:

1. Lower the TTL first, and wait out the old one. Set the record to 300 seconds, then wait at least the length of the previous TTL so every cached copy carrying the old value has expired.
2. Now make the actual change. From this point the worst case is five minutes, because that is what resolvers were last told.
3. Raise the TTL back afterwards. A permanently low TTL means more queries and a harder failure if your DNS provider has an outage.

Skipping step one is the reason migrations feel like they take a day. Doing it costs one extra wait, scheduled in advance, instead of an unscheduled one during the cutover.

A frequent and confusing case: the global checker shows the new value everywhere, and your laptop still opens the old site. The checker queries public resolvers directly; your machine goes through several caches that the checker never touches.

• The OS cache. Separate from the browser and from the resolver.
• The browser's own cache. Chrome keeps its internal one; a hard reload does not clear it.
• Your router or corporate resolver. Often the actual culprit, and often with a long TTL of its own.

Check with dig @1.1.1.1 example.com and then dig example.com: if the first is correct and the second is not, the stale copy is between you and the internet, not in the DNS system at large.