DNS Propagation Checker

"Propagation" is a slightly misleading name, because nothing is actually being pushed anywhere. DNS is a pull-based system: when you update a record, your authoritative nameservers start answering with the new value immediately. The delay you experience comes entirely from caching — every recursive resolver on the internet that looked up your domain before the change is still holding the old answer, and it will keep serving that answer until the record's TTL (Time To Live) counts down to zero. There is no mechanism to notify those resolvers early; the old data simply has to expire.

This is why the single most effective migration technique happens before the change, not after it. If your record carries a TTL of 86400 seconds, some resolver somewhere may serve the stale value for a full day. Lower the TTL to 300 seconds 24-48 hours in advance — long enough for the old, high TTL to expire everywhere — and the actual cutover completes in minutes for virtually all users. Once you have confirmed the new values are stable, raise the TTL back up so resolvers are not hammering your nameservers unnecessarily.

One less obvious wrinkle is negative caching. If a resolver looks up a record that does not exist yet — say, a subdomain you are about to create — it caches the "no such record" answer too, for a duration controlled by your zone's SOA record. So querying a brand-new hostname before you have created it can actually delay when that resolver picks it up. When staging a launch, create the records first and test second, and remember that each resolver's cache is independent: seeing the new value on Google's 8.8.8.8 tells you nothing about what your office ISP resolver is still holding.