Free DNS tool
DNS Checker
Look up the records for a domain across major public DNS resolvers at once, and see whether a recent change has finished propagating.
$HTTP_PROTOCOL = (isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on' || $_SERVER['HTTPS'] == 1)) || (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') ? 'https://' : 'http://'; $SITE_URL = $HTTP_PROTOCOL . $_SERVER['SERVER_NAME'] . '/'; ?>
Free DNS tool
Look up the records for a domain across major public DNS resolvers at once, and see whether a recent change has finished propagating.
Try , ,
Compares the public resolvers Google, Cloudflare, DNS.SB and AliDNS over DNS-over-HTTPS, in your browser. They cache independently, so differences usually mean a record is still propagating (large CDN or geo-routed sites can differ by design).
A change is only live once it propagates everywhere. Pulsetic monitors your domain and SSL certificate from multiple regions around the clock.
When you change a DNS record, the new value does not reach the whole internet at once. Resolvers around the world cache the previous value for the length of its TTL, and only fetch the new one after that timer expires. During that window the same name can resolve differently depending on which resolver answers. That window is DNS propagation.
This DNS checker makes the window visible. It asks several major public resolvers for the same record at the same time and lines up their answers, so you can see at a glance whether a change has reached them all or is still rolling out.
Every resolver keeps its own cache. The moment one of them fetches your new record, it serves the new value until the TTL expires; a resolver that cached the old value a minute earlier keeps serving the old one for the rest of that TTL. With independent caches across different operators, a mid-propagation record shows up as a split: some resolvers on the new value, some on the old.
Name server (NS) changes are the slowest, because the delegation is cached at the top-level domain and by every resolver below it, often for up to 48 hours. Address records usually settle within their TTL, commonly an hour or less.
You cannot force a resolver to drop a cached record early, but you can plan ahead. A day or two before a planned change, lower the record TTL to a small value such as 300 seconds. Resolvers then cache the old value for only five minutes, so when you make the switch it propagates almost immediately. Once the change has settled, raise the TTL again to reduce lookup load.
After a migration, confirm the new value here, then run a normal DNS lookup and an outside is-it-down check to be sure the server behind the record is actually serving traffic.
It is the lag between editing a DNS record and that edit reaching resolvers everywhere. Each resolver holds onto the old value for as long as its TTL says to, which is why the same change shows up at one place sooner than another.
A few minutes at best, up to roughly 48 hours at worst. What decides it is the TTL the record carried before you touched it, since resolvers keep handing out the cached copy right up until that timer runs out. Name server (NS) changes tend to drag on the longest.
Every resolver runs its own cache, on its own schedule. Mid-propagation, some are still serving the record they grabbed yesterday while others have already picked up your new one. The checker hits several public resolvers in one go, so that split is right there in front of you.
Type your domain into the box above and choose the record type. Once all the resolvers hand back the same value, you are done for those resolvers. As long as they disagree, the change is still working its way through.
Plan ahead. A day or two before you make the change, drop the record TTL so resolvers only hang onto the old value briefly. Once everything has settled, put the TTL back up.
No. What it does is line up the big public resolvers (Google, Cloudflare, DNS.SB and AliDNS), each running on its own global anycast network with its own cache. You get the lag between operators, not a city-by-city view.
Plenty of big sites, CDN-backed ones in particular, hand back different addresses by region on purpose. The checker reads that as out of sync even though nothing is actually propagating. Your own records normally point at a single address, so for those a split really does mean the change has not finished.
Trusted by teams at companies around the world
2-minute setup · Cancel any time
No credit card needed
Stay online, all the time, with Pulsetic's uptime prime.
By Designmodo
Designmodo Inc. 169 Madison Ave, #79627, New York, NY 10016, United States
Copyright © 2010-2026