DNS Propagation Checker

What is DNS propagation

"Propagation" is just the lag between you publishing a DNS change and the rest of the internet actually noticing. And here's the bit nobody warns you about: the second your authoritative nameserver starts handing out a new IP, MX or TXT record, almost nobody's asking it directly. Browsers and mail servers talk to recursive resolvers instead. Those resolvers cling to whatever they last fetched for as long as the record's TTL tells them to. Until that cached copy expires, you get the stale answer. No exceptions. So propagation isn't some switch that flips. It's a slow sweep, paced by your per-record TTL and the resolver's own quirks and whatever the network happens to be doing between it and your nameserver that day.

So I point three separate vantage points at the same name and put their answers next to each other. Two are the giants you almost certainly already lean on (Google Public DNS, Cloudflare 1.1.1.1), hit straight from your browser. The third is our own server resolver, which slips in a European (OVH) angle without you leaving the page. Same record everywhere, with TTL countdowns that roughly line up? Your change is out clean. One resolver still coughing up the old value, or TTLs scattered all over? Yeah, it's still cooking.

How a DNS propagation checker works

Under the hood? Not complicated. The page builds one request per resolver, fires them all off together, and stitches the replies into a single table. Google and Cloudflare each get a DNS-over-HTTPS (DoH) call to their public JSON endpoint. The PeopleAreGeek vantage point goes through our REST API, which just runs a plain recursive lookup on the OVH box and hands the result back. All three come home in the same shape (record list, TTL, status code like NOERROR or NXDOMAIN or SERVFAIL), so comparing them is trivial. Sampling a handful of resolvers at once gives you a decent read on how the wider internet resolves the name right this second. And you skip installing dig or SSHing around a pile of boxes to get it.

1. Validate the input. I trim the domain, strip off any scheme or path you pasted by accident, then tidy up the record type so the lookups don't choke on it.
2. Send DoH requests to Google Public DNS and Cloudflare 1.1.1.1, plus a server-side recursive query through the PeopleAreGeek REST API.
3. Parse the responses. Pull out the answer records, the TTL, the status, and whatever CNAME chain got followed on the way.
4. Group the unique answers across resolvers so you can see at a glance what each one's handing out. And, just as telling, what it isn't.
5. Score consistency. Everyone agreeing on the same record set means you're propagated. A minority still stuck on the old value means it's mid-roll. A resolver that fails outright or comes back empty? That usually points at something broken upstream, not just slow.

Common use cases for a DNS propagation checker

• Right after you edit a record at the registrar. You just flipped an A record to a new IP. Now you want to know how many resolvers are already on it before you go tell anyone the migration's done. This is the one I open it for the most, by a mile.
• Mid hosting migration. Point a domain at a new server and for hours you'll get back both the old and new value, depending on who you ask. The comparison view shows roughly how much of the pool has flipped. That's what I lean on to decide it's finally safe to kill the legacy box.
• Chasing a "works on my machine" report. One teammate sees the new site, another's still landing on the old one. Nine times out of ten their resolver is just parked on a stale cache, and a quick run here pins down exactly which public resolver is dragging its feet.
• Email gone weird. A new MX, SPF or DMARC record does nothing until the receiving mail server's resolver actually picks it up. Lining up the TXT and MX answers across resolvers is a fast way to rule out stale DNS as the reason mail's bouncing or sitting in quarantine.
• SSL cert validation that won't pass. DNS-01 challenges for Let's Encrypt and other ACME flows need a fresh TXT record, and when validation keeps failing it's genuinely hard to tell whether you fat-fingered the record or it just hasn't propagated. Comparing resolvers usually settles that in seconds.
• Subdomain takeover audits. When a CNAME points off to some third-party service, checking the CNAME chain across several resolvers can catch a dangling delegation: gone from the authoritative server already, but still cached and exploitable elsewhere.
• Sizing up a sketchy domain. Answers that wildly disagree across resolvers can hint at fast-flux DNS or a geo-targeted hijack. One signal among many. Not proof. But it costs nothing to grab, so I grab it.

Limitations and privacy notes

Let me be straight about what this won't do. Three vantage points give you a solid snapshot. But three out of thousands? That's a sample, not a census. Most home ISPs run their own resolvers, and plenty of corporate networks do split-horizon DNS that serves internal IPs for the exact same name. So when someone reports trouble from a network like that, the most this tool can honestly tell you is "the public side looks fine". The last mile still needs a query run from inside their network. Another gotcha worth knowing: the TTL each resolver shows is what it's handing out right now, not necessarily what you set on the authoritative server. Caching and forwarding chip that number down as it travels. And a few of the big public resolvers (Quad9, OpenDNS, AdGuard, NextDNS) I just can't reach from the browser yet, because their DoH endpoints don't send back the CORS headers browsers insist on. I'll route those through a server-side proxy in a later build.

On privacy: the domain you look up goes to Google's and Cloudflare's DoH endpoints, plus our own server for the third read. Google and Cloudflare each run their own privacy policy on resolver traffic. That's on them. Our server resolver doesn't log what you query. Everything gets worked out in your browser, then wiped the second you close or refresh the page.

Frequently asked questions

How long does DNS propagation usually take?

Honestly? It's all about the TTL on the old record. Most modern providers run a TTL somewhere between five minutes and an hour, so in practice you're usually visible globally within a few hours. The painful ones are old records still pinned to a 24-hour TTL. Those can drag on a full day. My trick, and it almost never lets me down: drop the TTL a few hours before any change you've got planned, and the whole thing wraps up way faster.

What is the difference between authoritative DNS and recursive DNS?

Think of the authoritative server as the single source of truth for your domain. It's where the real records live. Recursive resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) are the middlemen your browsers and mail servers actually talk to, and they cache hard. Your edit hits the authoritative server right away. But those recursive caches won't bother grabbing the fresh copy until their TTL runs dry. That gap, sitting between the two, is the whole reason propagation feels so slow.

Why do different resolvers sometimes return different IP addresses for the same name?

Usually one of a few things, and they're genuinely easy to mix up. Most often it's plain propagation still in flight after a recent change. Sometimes it's EDNS Client Subnet doing its thing on geo-routed DNS, where the authoritative side hands Google a different IP depending on where the asking resolver physically sits. And sometimes? Totally normal. Anycast and load-balanced CDNs will happily give you any one of several equivalent IPs, so different answers don't mean a thing is broken.

Does this tool query my ISP resolver?

It doesn't, no. The comparison runs across Google Public DNS, Cloudflare 1.1.1.1 and the PeopleAreGeek server resolver. Your ISP's own resolver never enters the picture. Want to see what yours is serving too? Run dig +short example.com from a terminal and drop that next to what this page shows you. That side-by-side is exactly how I catch an ISP quietly lagging behind everyone else.

Why does a resolver return SERVFAIL or no answer?

These trip people up constantly, so here's how I read them. SERVFAIL usually means the resolver reached your authoritative server fine but the answer came back malformed, or DNSSEC validation blew up on the way. A NOERROR with nothing inside it? The name exists, just not that record type. NXDOMAIN is the harsher verdict: the name itself doesn't exist at all. When you need to be dead sure which one you're staring at, the Raw JSON tab spells out the exact status code from every resolver.

Can I trust this for production go-live decisions?

For most consumer-facing sites and SaaS apps, I'd lean yes. If all three vantage points are showing the new record, you're propagated across the two biggest public resolvers plus a European server read, and that covers the bulk of real traffic. But if your audience sits behind enterprise networks running strict private DNS, or you genuinely need a deep multi-region view, please don't stake the go-live on this alone. Maybe I'm overly cautious here, but run at least one query from inside that network first. Then make the call.