DNS Propagation Checker
Why your change has not taken effect yet

What DNS Propagation Actually Is — and Why Nothing Propagates

Nothing spreads outward across the internet when you change a DNS record. The moment you save it, your own nameservers serve the new value to anyone who asks. What you are waiting for is the opposite of spreading: you are waiting for other people’s computers to forget the old value. “Propagation” is a misleading name for the expiry of thousands of independent timers.

Every answer a resolver receives arrives stamped with a TTL. RFC 1035 section 4.1.3 defines it as “a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded.” That number is permission you gave in advance. A resolver that fetched your old address one minute before you changed it, with a one-hour TTL, is behaving perfectly correctly when it keeps serving that old address for the next fifty-nine minutes.

This is why the question “has it propagated yet” has no single answer. Different resolvers fetched your record at different moments, so their copies expire at different moments. The check above does not try to produce a percentage out of that; it shows you which distinct answers exist right now, how long the stale ones may still be served, and — the part that actually decides what to do next — whether the record is correct at its source. For the step-by-step version of what to change and when, our guide on fixing DNS propagation delay for new domains covers the procedure; this page is about reading the state you are in.

How to Read Your DNS Propagation Check Result

The verdict is one of eight states, and each one implies a different next action. Four of them mean stop waiting and go and change something. There is no score and no percentage, because a number would hide exactly the distinction that matters: whether the problem is in someone else’s cache or in your own zone.

One detail is worth knowing before you read the table of answer sets: the comparison is between sorted sets, never first records. A domain with several addresses hands them out in a rotating order, so a naive comparison would show seven different answers for a domain where nothing is wrong at all. If you want the full record inventory for a domain rather than a propagation check, our DNS lookup tool lists every type at once.

Your Own Nameservers Are the Only Ones That Matter

Public resolvers can only ever tell you what they were given some time ago. Your own nameservers tell you the truth right now. So this tool asks each of them directly, by address, with the recursion-desired bit switched off — which means “answer from your own zone, do not go and look this up for me”. A server that is genuinely authoritative for the zone sets the AA flag in its reply. One that answers without it is not speaking for your zone, and that is reported separately as not authoritative rather than being mixed in with the real answers.

Why the SOA serial is in the table

Most zones have one primary nameserver and one or more secondaries that copy the zone from it. Each copy carries a serial number in the zone’s SOA record, and the secondaries use it to decide whether they need a fresh copy. If two of your nameservers report different serials, they are serving different versions of your zone. That is the classic invisible fault: half the internet gets the new record and half gets the old one, forever, and no amount of waiting changes it because both servers think they are right.

Seeing it requires asking each server individually, which is precisely what a resolver will never do for you — it picks whichever nameserver answers fastest and caches that. If the serials in your result differ, the fix is at the DNS provider: force a zone transfer, or find out why one secondary has stopped pulling.

Delegation: When the Registry and Your Zone Disagree

Two separate systems both hold a list of your nameservers. Your registrar pushes one list into the registry for your extension — that is the delegation, and it is what the rest of the internet follows. Your DNS host publishes another list inside the zone itself. They are supposed to match. When somebody moves DNS provider and only updates one of them, they do not.

A recursive resolver hides this problem rather than showing it, because it follows the registry’s list and hands you back whatever it finds. To see the disagreement you have to ask the parent zone directly, with recursion off, which is what the delegation panel above does: it walks down from the root, asks the registry for your extension what it holds for your domain, and compares that with what your own nameservers say.

Glue records, and the failure that looks like nothing happening

If your nameservers are named inside the domain they serve — ns1.example.com serving example.com — there is a bootstrapping problem. To find ns1.example.com a resolver must ask example.com’s nameservers, which is the thing it is trying to find. The registry breaks the loop by publishing the nameservers’ addresses alongside the delegation. Those are glue records. Without them nothing resolves, and the symptom is the one that brings people to a propagation checker in the first place: three days have passed and absolutely nothing has changed.

Glue is set at the registrar, usually under a name like “host records”, “registered nameservers” or “private nameservers”. If you are not sure which company is your registrar, a WHOIS lookup names it. If a name resolves nowhere at all rather than to the wrong place, our guide to fixing “IP address not found” errors covers the wider set of causes.

Why a Record You Just Added Still Shows as Missing

There is a second kind of caching, and almost nobody is told about it. When a resolver asks for a name that does not exist, it does not just shrug — it remembers the absence. That memory has its own lifetime, and the lifetime does not come from the record you just created, because there was no record to carry a TTL. It comes from your zone’s SOA.

RFC 2308 section 4 makes this explicit: the SOA minimum field is “the TTL to be used for negative responses”. So if your SOA minimum is 3600, a resolver that asked one minute before you published can keep telling people the record does not exist for the next hour, and re-checking will not shorten it by a second.

This is the single most common reason a brand-new record “has not propagated”, and it is why the verdict above treats it as its own state rather than lumping it in with ordinary caching. The two need different waits: ordinary caching clears in one record TTL, negative caching clears in one SOA minimum, and those numbers are often very different.

Reading the Countdown: What the Remaining TTL Tells You

The TTL shown next to each resolver is not the TTL you configured. It is what is left of it: the number of seconds that resolver may still serve the copy it holds. That difference turns a vague “up to 48 hours” into an actual clock, and it carries a second piece of information most people miss.

If a resolver is serving an answer that differs from your nameservers and its remaining TTL is close to your full configured TTL, that copy was fetched moments ago. A copy fetched moments ago is not a stale cache. It means that resolver was given a different answer — which happens when a domain deliberately serves different addresses by location, when a nameserver is out of sync, or when something between the resolver and your zone is not what you think it is. The tool surfaces that as evidence and stops there, because from a single vantage point those explanations are indistinguishable.

Checking it yourself

Run the first command twice a minute apart and the TTL will have fallen by roughly sixty. That falling number is the whole of “propagation”. If you want to watch a server actually respond rather than watch a cache expire, our ping test answers the different question of whether the machine at the other end is up.

What This DNS Propagation Check Cannot See

Every query on this page leaves one server in one location. What varies between the rows is which resolver was asked, not where the asking happened. That is a real limit and it is worth stating plainly, because a grid of country flags implies something this method does not provide.

• Anycast. All seven of these resolvers run the same address from many sites at once. We reach whichever site is nearest to our server. A visitor elsewhere may be served by a different machine with a different cached copy, and it will not appear here.
• Your visitors’ own resolvers are invisible. Most people use whatever their ISP, their employer or their router hands them. None of those can be queried from outside, and a corporate resolver with a long minimum cache can lag everything shown here.
• Why, not just what. When two resolvers differ, this page says they differ. It does not say why, because a stale cache, a withheld answer and a deliberately location-specific answer produce identical evidence from one vantage point. Any tool that tells you the reason is guessing.
• One moment in time. A TTL that reads 40 seconds will read 10 seconds half a minute later. The result is a snapshot, which is why the shareable link re-runs the check rather than storing an old one.

The part that is not a snapshot, and not subject to any of the above, is the answer your own nameservers give. That is why the verdict is anchored there. Two related checks complete the picture from a different angle: our reverse IP lookup shows what else lives at the address you are being sent to, and the cluster’s background explainer, how DNS resolves domain names to IPs, walks the whole query path from browser to authoritative server.

Frequently Asked Questions About DNS Propagation