Thirteen Wrong Lines Went Out in the July 31 Send

The domain setup page had a line that read the registrar name off the DNS record and turned it into a sentence: this domain came through the platform’s domain service. It looked like a fact. It was an inference chained off a single string match, no different in kind from guessing someone’s employer from their email provider.

One customer broke the correlation

The inference held for a while because most of our domains did come through us. The correlation looked like causation until it wasn’t. One customer’s domain broke it. They forwarded a confused reply to that line, and pulling the thread back showed the registrar name pointed at a major third-party registrar. That was true. But the reseller account behind that registration wasn’t ours. It belonged to a different reseller on the same registrar.

Same registrar, wrong owner. The page had no way to tell the difference because it never checked ownership. It checked a string.

The first fix swapped one guess for another

We distrusted the registrar field and swapped in a different derived field: the nameservers. Our reasoning was that if the domain pointed at our nameservers, that was a stronger signal of “came through us” than the registrar name had ever been. We shipped a version of the copy that read the NS records instead and pushed it to staging.

It was wrong in a different way. Nameservers get set by whoever manages DNS day to day, and for a chunk of customers that is us, even when the registration sits with a reseller we don’t control. The NS check turned some false positives into false negatives. Domains that really did come through the platform’s domain service, but had since been pointed at a customer’s own DNS panel, now read as “not ours.” We had traded one wrong inference for another, both derived from fields that don’t encode the fact we needed.

We caught it because we ran the new check against the same known-bad case. It produced a different wrong answer instead of the right one.

Asking the registrar

The only thing that tells you who owns a registration is the registrar’s own record of it. So the fix was a reseller lookup. We hit that registrar’s reseller API directly and check whether the domain’s account ID matches ours. No field that merely correlates with ownership sits anywhere in the chain.

It shipped in one release with a second fix on the same page. The failure-mode copy had been telling every customer that fixing the domain issue would break their site, whether or not that was true for their specific record. Both went out with per-record refresh timestamps, so a customer looking at stale text has a timestamp to point at instead of just a hunch.

The cleanup that isn’t done

Thirteen customers got the wrong line in the July 31 send. Twelve of those still need to be checked individually. The reseller lookup fixes the page going forward, but it doesn’t retroactively verify who already received bad copy. Each one needs a lookup against the reseller API and a corrected reply if the guess was wrong, so this is a queue of manual checks.

The registrar name and the nameservers were both closer to gossip about who owns the domain than to the record of it. Swapping one correlated field for another never verified anything. When a system states who owns something, the question is whether it read the owner’s own record or matched a string on a related field. Twelve customers are still waiting on the answer.

dxdev LESSON · paste into your AI coding agent
LESSON: Verify Identity Claims Against Their Source Of Truth, Not A Correlated Field
SOURCE: dxdev.com/blog/proxy-signal-inference-trap
WHAT HAPPENED: A page inferred that a domain came through the platform's domain service by matching the registrar name string, which worked until a customer's domain shared the registrar but belonged to a different reseller entirely. The first fix swapped in nameserver records as a stronger signal, but that just flipped some false positives into false negatives, since customers can manage DNS for domains registered elsewhere. The only real fix was a direct reseller API lookup checking whether the domain's account ID matched, shipped alongside a fix for failure-mode copy that wrongly warned every customer their site would break, both with per-record refresh timestamps. Thirteen customers had already received the wrong line, and twelve still need individual verification since the new check doesn't retroactively confirm past cases.
THE RULE: When a check needs to answer an identity or ownership claim, only a query to the actual source of truth counts as verification; any derived or correlated field, no matter how reliable it seems, is still a guess that will eventually diverge from the fact it's standing in for.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Trace each identity or ownership claim in the code back to whether it queries the authoritative source directly or infers it from a correlated field like a name string or a related record
      2. When a check breaks, verify a proposed replacement against the known failing case before shipping it, rather than assuming a different field is more reliable
      3. For any place a wrong inference was already served to users, confirm there's a queue to individually re-verify and correct past instances rather than relying on the fix applying only going forward
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.