The Registry Check That Split Eleven Dead Domains

Eleven customer web addresses were already dead. Visitors got nothing. I treated that as a DNS problem, and Claude was ready to turn the same label into a batch notice.

The label was true as far as it went. Every address failed to resolve. The mistake was assuming that a shared symptom was enough to decide what had happened and what to say next. I had grouped eleven customers under one operational description, then given Claude an action: send their own notice. That looked like a clean handoff. It was an incomplete diagnosis.

The timing made the shortcut more tempting. A prior campaign had already contacted 53 accounts whose sites were headed toward failure. These eleven had been deliberately left out because that final notice would have been false for them. Their addresses had already stopped working entirely, and none of the eleven customers had been contacted about that state.

I had the right instinct about the copy. I had the wrong model for the investigation. A resolver gives a useful external symptom. It does not, by itself, tell us whether every affected name has the same registry state behind it. I let the visible failure stand in for the mechanism, and I was one send away from telling a customer whose nameservers had changed that their domain had lapsed, or telling ten customers with lapsed domains something closer to a nameserver problem, depending on which explanation the merged letter happened to lean on. Either direction is wrong for someone, and it goes out under our name rather than as a generic system error.

The DNS label hid two different states

Claude’s failure was specific to the task I handed it. It could organize a mailing job around the no DNS label, but it could not recover the diagnostic distinction that label had erased. The request already said the copy had to be new rather than a variant of the earlier notice. I still had not made the next step explicit: check every name against its actual registry before deciding who belongs in the same letter.

That check changed the shape of the work. Ten of the eleven had lapsed registrations. One had gone nameservers. A visitor saw the same empty result from both cases. The customer did not have the same problem, and a message that collapses them together turns a technical support notice into a guess.

The batch stopped being one batch

I wrote and sent a new notice to all eleven customers, but the campaign no longer had one generic explanation. The registry checks split it into two different problems and two different letters. That is a small operational change with a larger implication. The unit of work was not eleven dead domains. It was eleven customer situations whose browser symptom happened to match.

Two customers also received handwritten notes instead of the batch copy. That decision came out of the same refusal to treat the list as mechanically uniform. The earlier work had identified at least one account that had already received two emails and would need explicit approval before a third. Even when the technical state is clear, contact history changes what responsible automation looks like.

I also kept the work inside a deliberate send path. The original instruction required each account to be shown with its detail page before sending. That is a modest check, but it counters the exact temptation the first label created. A batch is efficient only after the individual records have been inspected enough to justify grouping them.

There is a narrow technical lesson here. DNS resolution is a poor substitute for a registry check when the customer-facing decision depends on why a name is unavailable. It can signal that something is wrong. It cannot safely choose the explanation, the letter, or the next action by itself.

The response arrived before the campaign felt finished

All eleven notices went out with no failures. One customer bought the lapsed domain back 12 minutes after reading the message and later pointed it at us. That was a real result, but it was not proof that the process had become automatic in the comforting sense. It proved that the notice contained an actionable explanation for at least one person.

The unresolved part is how often our operational labels are only the outer shell of a state machine. No DNS sounded precise because it named a visible failure. The registry check showed that it was a bucket holding two different causes, two letters, and a separate decision about handwritten contact.

The 12-minute renewal is the number I keep beside the registry result. The resolver found the symptom. The registry check made the message usable.

dxdev LESSON · paste into your AI coding agent
LESSON: A Shared Symptom Is Not a Shared Cause
SOURCE: dxdev.com/blog/2026-08-24_dead-domains-registry-check-over-dns
WHAT HAPPENED: Eleven customer domains had all stopped resolving, and the plan was to send all eleven the same "no DNS" batch notice. A registry check before sending revealed two different causes: ten had lapsed registrations, one had changed nameservers. Sending the merged explanation would have been factually wrong for at least one customer. The batch was split into two letters plus two handwritten notes for accounts with prior contact-frequency concerns, and one customer bought their lapsed domain back 12 minutes after receiving the corrected, specific notice.
THE RULE: A visible technical symptom (a resolver failure, an error code, a blank page) tells you something is wrong; it does not tell you which of several possible mechanisms caused it, and grouping affected accounts into one communication based on the symptom alone risks sending a factually incorrect explanation to some fraction of them. Check the actual mechanism per account before merging accounts into one message.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any customer-facing batch communication (email, notice, alert) planned around a shared surface-level symptom without a per-account check of the underlying cause.
  2. Any incident response that treats "N accounts show the same error" as "N accounts have the same problem" without a verification step that could split the group.
  3. Any automated or semi-automated outbound message process with no check for prior contact history before adding an account to a new batch send.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.