When the registrar lost our nameservers: four days of NXDOMAIN, timestamped

What happened: four domains dropped out of the .app zone

The domains were diagramgen.app, freeheadshot.app, freevideocompressor.app and nichelogo.app — all registered on 13 June 2026 through one registrar, all pointed at Cloudflare within hours, all live and climbing in Search Console for two weeks. Then, on 27 or 28 June, the delegation for all four disappeared from the registry. We cannot give you the exact minute, because nothing on our side was watching the registry layer. That is the story.

The failure mode matters more than the cause. A domain with wrong records still resolves — you get an address, it is merely the wrong one. A domain with no delegation does not resolve at all: ask any resolver and the parent zone, app., answers NXDOMAIN. No server to reach, no origin to time out, no certificate to fail. To a browser it looks like a typo. To Googlebot it looks like the site was never there.

The damage:

• About four days unreachable, 27/28 June to 1/2 July, on all four domains at once — web and mail together, since MX lookups fail the same way.
• Deindexed on 2 July, after consecutive days of failed crawls. Not instant, and not instantly reversed either.
• Recovery split down the middle. By 17 July two domains had roughly 70–90% of their search traffic back; two were still near zero — with no relationship to how each had been repaired.
• One consequence we found only by going looking, three weeks later: the outage stopped Google reading our sitemaps, and that did not heal on its own for a month.

The evidence chain, timestamped

All times UTC. We are deliberately not naming the registrar: the failure is documented in our logs, its cause sits inside a system we cannot see, and a page ranking for this query is not the place to assign blame we cannot prove. The shape of the failure is registrar-agnostic anyway.

Ruled out one by one, so that "the registry lost the delegation" is a conclusion and not a guess: the Cloudflare zones were never deactivated (activated_on still reads 13/14 June, zero audit events since); bindings, routes and stored content all intact; and the NXDOMAIN was visible from public authoritative resolvers, not just one office network.

Why it happened is not answerable from data we can see. What we can say: the loss hit several domains registered in the same batch, and the restoration was one bulk action that got half the nameserver sets wrong — both point at a registrar-to-registry sync pipeline rather than anything domain-specific. The exposure worth naming: a domain registered at one provider but delegated to another has two systems that disagree about its nameservers, and the registry only listens to one of them.

Run the same checks yourself, line by line

An incident report you cannot verify is a story. These are the checks we used, in order, and each one works on any domain with no account and no vendor tooling.

1. Is there a delegation at all? The question that separates "still propagating" from "gone". Ask two independent resolvers so one broken cache cannot fool you:

dig NS example.com +short
dig @8.8.8.8 NS example.com +short
dig @1.1.1.1 NS example.com +short

2. Which zone denied it? On NXDOMAIN the answer section is empty and the authority section carries the SOA of the zone that issued the denial. If that SOA belongs to the TLD — app., com., de. — the registry itself is saying it has nothing for you. The same record's minimum field is the negative-cache TTL that keeps the denial alive after a repair:

dig SOA example.com
dig +trace NS example.com     # the whole chain, root → TLD → your nameservers

3. The same without a terminal. Both resolvers answer over plain HTTPS — which is what our health check uses, and what the nameserver propagation checker runs from the browser. In the JSON, Status is the RCODE: 0 NOERROR, 2 SERVFAIL, 3 NXDOMAIN.

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

4. What does the registry hold, and when did it last change? RDAP is the registry's own public record. Its last changed event is what proved the 30 June repair happened at 17:30:04 and was not ours, and its nameserver list is the authoritative answer to "did my registrar actually push my change":

curl -s https://rdap.org/domain/example.com | jq '.events, .nameservers[].ldhName'

5. Did anyone on your side touch the zone? Ruling ourselves out turned a suspicion into a finding. Ask your provider's account-level audit log for the outage window; getting nothing back is a real answer.

curl -s -H "Authorization: Bearer $CF_API_TOKEN" \
  "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/audit_logs?since=2026-06-18"

6. When did search traffic stop? In Search Console read impressions by day, not totals: a vertical cliff to zero on one date is the fingerprint of an availability failure, never of a ranking change. Then check the sitemap's last-read date and run URL Inspection on a page that used to rank. All three mattered here; the second one mattered most.

Steps 1 and 3 are also the first layer of clize domain check <domain>, which adds the three layers a public resolver cannot see.

Why every dashboard said "fine"

For four days we had two status indicators and both were green. Neither was lying about its own layer; both were answering a question we were not asking.

The Cloudflare zone said active. A zone status describes the zone's relationship with its provider — created, nameservers confirmed once, being served. It is stored state, set at activation, not re-derived from the public internet. Ours had activated on 13–14 June and nothing had changed it since, because nothing about the zone had changed. The delegation pointing the world at that zone was gone, and the zone had no way to know.

The registrar's field said verified: true. That reports what the registrar believes it has configured: intent, not outcome. Here it was the single most misleading signal available — the system that had lost the delegation was also the system reporting it as fine, and it kept saying so while accepting a re-submission with an HTTP 204 that changed nothing.

Whether a domain is alive on the public internet can only be read from public authoritative DNS, from at least two independent resolvers. A provider's zone status is a cached snapshot; a registrar's verification field is a claim about its own intentions. In this incident both said "fine" for four consecutive days.

Deploy success is not evidence either. Every deploy in that window succeeded, because deploys write into storage that was never broken. Green at the end of a deploy means the deploy worked, not that anyone can reach the result — two different claims needing two different checks, which is the boundary the four-layer domain health check exists to cross.

NOERROR, NXDOMAIN, SERVFAIL: how to tell in 30 seconds

If you are reading this mid-incident, this part saves you a day of waiting. 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. Only the first is a waiting problem.

Then the trap that made our outage look longer than it was. After a delegation is repaired, NXDOMAIN can keep coming back for the length of the negative-cache TTL — the SOA minimum. Resolvers cache denials the way they cache addresses, and RFC 2308 puts that memory at the smaller of the SOA minimum field and the TTL of the SOA record itself. Ours were fixed at 17:30 on 30 June and the sites did not return for most people that evening: their resolvers were still inside the negative window. The DNS TTL calculator does that arithmetic for your own zone.

What Google did, and what it did not undo by itself

The widely cited guides to recovering from deindexing list causes like unnatural links, thin content, cloaking, spammy structured data, an accidental noindex, an expired domain, a crashed server. None of them list "the registry lost your delegation" — and from a crawler's point of view that is the most complete failure available: not a 500, not a timeout, but a name that does not exist.

What we observed, in order:

1. 28 June: impressions to zero on four unrelated sites on the same date. Ranking changes do not look like that.
2. 2 July: deindexed after consecutive failed crawls — the same day the domains came back, because the removal was a lagging response to days of failure.
3. Through mid-July: split recovery. Two domains climbed back to roughly 70–90%; two were still near zero on 17 July. The repair path made no difference — the domain the registrar had restored correctly by itself was among the two that did not recover.
4. 19 July: the finding nobody warns you about. The outage broke Google's sitemap-reading rhythm and it had not resumed a month later. Search Console showed the last successful read stuck on 19 June for one domain and 16 June for another — dates from before the outage. Re-submitting by hand produced an immediate read; on one domain the discovered-URL count went from 18 to 199 in that single re-read, and on another a page that used to rank came back from URL Inspection as "URL is unknown to Google".

That last point is the practical one. Crawl and sitemap scheduling are set by past behaviour, so a site that fails for a week gets scheduled less often — and the backoff keeps applying after the site is healthy. Waiting for it to unwind cost us weeks. Re-submitting the sitemap is not cleanup after an outage; it is part of the repair.

The recovery checklist we now run

1. Establish the state from public DNS, not from a dashboard. Two resolvers, NS and SOA, read the RCODE. Everything else waits on that answer.
2. If it is NXDOMAIN, go up a layer. Check the registry's RDAP record and the registrar. Re-saving your nameservers in the panel is worth exactly one attempt; if the RDAP record does not change, this is not fixable from your side and the next action is a support ticket with the RDAP output attached.
3. Read the negative-cache TTL before judging the fix. The SOA that carried the denial tells you how long the denial outlives the repair. Do not "fix" it a second time inside that window.
4. Verify the nameservers you got back, one by one. Our bulk restoration returned half the domains pointing at the wrong provider — a restored delegation aimed at servers that are not serving your zone is a second outage wearing the first one's clothes.
5. Rebuild what depends on DNS: records, certificate issuance, mail. MX failures stay silent for days because senders retry, so check them explicitly instead of waiting for a bounce.
6. Re-submit every sitemap. Do not wait for the crawler's schedule to recover; it may not for a month. This is the step that cost us most.
7. Request indexing for the pages that used to rank. If URL Inspection reports them as unknown, that is a queue position, not a verdict.
8. Put a probe on the layer that failed. If the lesson is that the registry layer was unobserved, the fix is not a better dashboard — it is a scheduled check that reads public DNS and shouts.

Steps 6 and 7 are search-engine work, not DNS work, and they are why the two halves of this page belong together: the people writing about NXDOMAIN do not write about deindexing, and the people writing about deindexing do not list delegation loss as a cause. It is one outage.

Three things we changed in the product because of this

All three shipped in v0.22.0. They exist because this outage was undetectable with what we had, not because they were on a roadmap.

1. A four-layer health check. clize domain check <domain> reads, in order: the registry delegation from public DNS over HTTPS (Google's resolver first, Cloudflare's as fallback, the RCODE read as three states — the NXDOMAIN branch in that code is annotated with this incident), then the provider zone, then the hostname's binding to the serving worker, then whether the content is actually being served. One command, because a green light at any single layer was exactly what misled us. Without a domain argument it sweeps every domain on the account.

2. Delegation verification after every deploy, warning when the domain it just published to is no longer delegated where it should be. That closes the gap that let dozens of successful deploys land on four unreachable domains.

3. A scheduled sweep with an observation window. A cron job probes every managed domain every 30 minutes and records the result; an alert email goes out only after two consecutive failed rounds, so one flaky DoH answer never pages anyone, and a second email goes out on recovery. Silence for a week is no longer an available outcome.

There is a fourth item, less flattering, and leaving it out would make this report worse. Our own records about these domains were wrong in three ways: the stored registrar was wrong for three of them, one was missing its zone id, and — the one that cost us time — importing a domain we already managed silently downgraded its access mode to "external". That downgrade made our own CLI refuse to change nameservers on a domain we had registered ourselves, on the night of the incident, which is why one of the two wrong delegations had to be repaired through the registrar's API by hand. The import path no longer downgrades a managed domain, and the production data was corrected under an audited migration. A tool that will not let you fix your own outage is worse than no tool, and we would rather that sentence sat on a page we wrote.

For the surface these commands live on: Agent Domains covers buying, importing, pointing and monitoring domains from the CLI, programmatic domain registration covers doing it from code, and the domains MCP server covers doing it from an agent's tool list.

$ npm i -g @clize/clize && clize login
$ clize domain check example.com
$ clize domain check          # every domain on the account