Nameserver propagation checker

How to check whether a nameserver change has propagated

Three steps, all on this page. The check reads public DNS over HTTPS from your browser — it never touches your registrar account, and there is nothing to install or sign up for.

1. Enter the domain. Type the domain, hostname or URL and press Check. The page queries dns.google and cloudflare-dns in parallel for NS, SOA, A, AAAA, MX and TXT — two independent views of the same public DNS.
2. Read the delegation line first. It is one of three states. NOERROR with nameservers means the delegation is intact and you are waiting for caches. NXDOMAIN means the parent zone has no delegation for you and waiting will not help. SERVFAIL means the delegation is there but the nameservers behind it are not serving the zone.
3. Then compare the two resolvers. If dns.google and cloudflare-dns return different nameservers or different addresses, one of them is still holding an older cached copy — that is propagation, and it ends on its own. If both agree and the answer is still wrong, nothing is in flight: the change never reached the registry.

Three answers, not two: NOERROR, NXDOMAIN, SERVFAIL

Almost every page about this topic sorts the world into two boxes: it works, or it is still propagating. That is the wrong cut, and it is why people wait three days for something that was never going to fix itself. An NS query at your apex has three answers, not two: NOERROR with NS records = the delegation is there and you are waiting for caches to expire; NXDOMAIN = the parent zone holds no delegation for your domain; SERVFAIL = the delegation exists but no authoritative server answered.

The tool above reads that state and then reads a second thing that separates the first two cases beyond doubt: the SOA. Ask for SOA at your domain and a healthy zone answers with its own SOA — proof that the chain from the root through the TLD to your nameservers resolved end to end. A domain with no delegation answers NXDOMAIN and puts the parent's SOA in the authority section, which is the registry zone telling you, in as many words, that it has nothing for you. Those two responses look identical in a browser: a page that will not load. They are not remotely the same problem.

What "propagation" actually is

There is no propagation. Nothing is copied from server to server, no wave is moving across the world, and no map of green and red dots is tracking it. When you change your nameservers, the registry writes the new delegation and every authoritative server involved has the new answer immediately. What takes time is the opposite: resolvers that already asked the old question are still holding the old answer until its TTL runs out. Propagation is a set of caches expiring, one by one, on their own clocks.

That single correction changes what you should do. The ceiling is not "24 to 48 hours" — it is the TTL that was on the old records when the last resolver cached them, plus whatever the parent zone's NS TTL is (48 hours at many registries, two days at some). If your old records carried a five-minute TTL, the whole thing is over in five minutes. If they carried two days, no amount of refreshing will help, and neither will a dozen browser tabs pointed at global propagation maps: those maps show you which caches have expired, not whether your change is correct.

The check above gives you the number instead of the folklore. Every answer comes back with the remaining TTL on the copy that resolver is holding — that is exactly how much longer that particular cache can keep lying to you. Two resolvers that return different nameservers are the visible form of propagation. Two resolvers that agree on an answer you did not configure are not propagation at all; they mean the change never reached the registry, and you should go back to the registrar rather than wait.

Negative caching: why a repaired delegation still answers NXDOMAIN

The nastiest version of this is the one where you fix the problem and nothing happens. After a delegation is repaired, NXDOMAIN can keep coming back for the length of the negative-cache TTL — the SOA minimum. Resolvers cache "this name does not exist" the same way they cache addresses; RFC 2308 sets the lifetime of that memory to the smaller of the SOA minimum field and the TTL of the SOA record itself, which is why the tool reports it as one number. At com. it is 900 seconds. At some ccTLDs and at the root it is a full day.

We have watched this play out on our own domains. In June 2026 four .app domains lost their registry delegation and went NXDOMAIN worldwide for about four days. The registrar pushed the delegation back on 30 June at 17:30 UTC — and the domains did not come back for most of the internet that evening. Resolvers that had asked during the outage were still inside their negative-cache window. Two dashboards told us everything was fine the entire time: the Cloudflare zone still reported active, and the registrar's own field still said verified. Public authoritative DNS, read from two independent resolvers, was the only signal that was true. That is why the four-layer domain health check starts at the registry layer and not at any vendor's status field.

Practical consequence: if the tool shows NXDOMAIN and a negative-cache TTL of 900 seconds, fix the delegation and then give it fifteen minutes before you conclude the fix did not work. If it shows a day, expect a long tail, and do not "fix" it a second time in the meantime.

What actually breaks after a nameserver change

Seven failures cover almost all of it. The delegation state above tells you which family you are in; this tells you what to go and look at.

1. The registrar accepted the change and never pushed it to the registry. The panel says saved, the public internet still returns the old set. Some registrars surface this as Domain update at registrar failed; most surface nothing at all. Symptom in the tool: both resolvers agree, and they agree on the old nameservers.
2. The zone was never created on the new nameservers. The delegation points at servers that have never heard of your domain, so they refuse to answer for it. Symptom: SERVFAIL from both resolvers. Create the zone first, change the delegation second — that order is the whole trick.
3. DNSSEC was left on across the move. The DS record still sits in the parent zone and still points at the old provider's keys, so every validating resolver refuses the answers from the new one. Symptom: SERVFAIL everywhere, while the new nameservers answer perfectly if you query them directly. Remove the DS at the registrar, wait out its TTL, then re-enable DNSSEC on the new side.
4. The records were not copied. Delegation perfect, zone live, and no A or AAAA for the hostname anyone actually types. Symptom: the tool shows the delegation green and the address row empty. This is the single most common reason a site is down after a nameserver change that "worked".
5. MX, SPF, DKIM and DMARC were forgotten. Mail breaks more quietly than the website and it breaks later, because sending servers retry for days before anyone notices bounces. Check the MX and TXT rows in the output above, not just the address rows. If the domain runs a mailbox your agent depends on, the inbox side of it goes dark at the same moment.
6. You are simply inside an old, long TTL. Nothing is wrong. The old records were published with a long lifetime and some caches are still holding them. The remaining TTL on each answer above is the countdown.
7. The domain expired, or was removed from the TLD zone, during the move. This is the one nobody looks for, because it is indistinguishable from the others in a browser and impossible to miss in a DNS answer. Symptom: NXDOMAIN with the parent zone's SOA in the authority section. Renew, restore, or talk to the registrar — waiting does nothing.

The same checks from a terminal

Nothing here is proprietary; the page is a convenience wrapper around two public resolvers. Every line of output can be reproduced with dig, and the tool prints the exact commands for whatever domain you entered. The four that matter:

dig NS example.com +short          # what the delegation resolves to
      dig @8.8.8.8 NS example.com +short # the same question, asked of one specific cache
      dig @1.1.1.1 NS example.com +short # and of another — two different answers = propagation
      dig SOA example.com                # on NXDOMAIN, the authority section names the zone that denied you

If you want the whole chain rather than the final answer, dig +trace NS example.com walks it one delegation at a time, from the root to the TLD to your nameservers, and shows you exactly which hop stops working. And if you have no dig — Windows, a locked-down laptop, a phone — the same two resolvers answer over plain HTTPS:

curl -s -H 'accept: application/dns-json' \
        'https://dns.google/resolve?name=example.com&type=NS'

That request is literally what this page runs. Reading the raw JSON is worth doing once: the Status field is the RCODE (0 NOERROR, 2 SERVFAIL, 3 NXDOMAIN), Answer holds the records, and on a denial Authority holds the SOA of the zone that issued it.

What a browser cannot see — and what the full check adds

Be clear about the boundary of this page. A browser can only talk to recursive resolvers over HTTPS, so it reads the two things a recursive resolver knows: whether the delegation chain resolves, and what the zone answers. It cannot query your TLD's nameservers directly, it cannot see your registrar's account, and it cannot see anything above or below public DNS — a proxy in front of your site, a certificate that has not been issued yet, a hosting binding that was never created, an origin returning 502. Those failures all look like "the site is down after I changed nameservers" and none of them are DNS.

clize domain check <domain> is the same first layer with three more stacked on top. It runs the identical dual-resolver DoH probe — dns.google first, cloudflare-dns as the fallback, RCODE read as three states — and then checks the Cloudflare zone, the hostname's binding to the site worker, and whether the site content is actually being served. Four layers, one command, so a green light means reachable rather than merely delegated. Without a domain argument it sweeps every domain on the account. The platform also probes on a schedule: a cron every 30 minutes, and an alert email only after two consecutive rounds fail, so a single flaky DoH answer never pages anyone.

That check exists because of the June outage described above — it is the fix that came out of the incident, along with delegation verification that runs after every deploy. If you want the rest of the surface, Agent Domains covers buying, importing and pointing domains from the CLI, registering domains programmatically covers doing it from code, and the command reference lists everything the CLI exposes. Deploying the site that lives on the domain is a separate command and a separate layer — which is exactly why the health check reports them separately.

$ npm i -g @clize/clize && clize install
$ clize domain check yourdomain.com