Check DNS propagation across public resolvers.

Why DNS Changes Are Not Instant

DNS propagation delay occurs because recursive resolvers cache DNS answers based on the TTL (Time to Live) value set on each record. When you change a DNS record, resolvers that previously queried the old record continue serving the cached answer until the TTL expires. There is no central "push" mechanism — each resolver learns about changes independently when its cache expires and it queries the authoritative nameserver again.

The propagation checker queries multiple public resolvers simultaneously (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, OpenDNS 208.67.222.222, and others) so you can see which resolvers still have the old record and which have the new one. If some resolvers show the new value and others show the old, the change is in progress — wait for all TTLs to expire.

Propagation Troubleshooting

Changes Visible on Some Resolvers Only

This is normal mid-propagation. Check the TTL on your record — if it was 3600 (1 hour) before the change, some resolvers cached it up to an hour ago. Wait for the oldest possible cache entry to expire.

Changes Not Visible After 48 Hours

Check that you changed the record on the authoritative nameserver, not a local copy. Verify NS records point to the correct nameservers. Some registrars cache zone data. Check that the zone serial number incremented.

Negative Caching (NXDOMAIN)

If a domain previously did not exist, resolvers cache the NXDOMAIN response for the SOA minimum TTL (often 86400 seconds = 24 hours). Adding a new record to a previously non-existent domain can take up to 24 hours to propagate.

4 Propagation Gotchas

1. TTL is a maximum, not a minimum: Resolvers MAY cache for less than the TTL but MUST NOT cache longer. However, some ISP resolvers ignore TTL and cache for 24+ hours. You cannot force an ISP to refresh.
2. Lower TTL before changes: If you plan a DNS migration, lower the TTL to 300 seconds at least 24 hours (old TTL duration) before the change. This minimizes the propagation window to 5 minutes instead of hours.
3. Anycast DNS complexity: Large DNS providers use anycast — the same IP serves from multiple locations. The resolver you test from London may hit a different authoritative server instance than a resolver in Tokyo, showing different results.
4. Browser DNS cache: Chrome has its own internal DNS cache separate from the OS. Even after OS cache is cleared, Chrome may serve stale DNS for 60 seconds. Test with curl or dig, not a browser.

CLI Equivalent

dig +short example.com @8.8.8.8
dig +short example.com @1.1.1.1
dig +short example.com @9.9.9.9
# Check authoritative directly:
dig +short example.com @ns1.yourhost.com

Related Tools