---
title: "When Your Field Predicts Wrong"
canonical: https://dxdev.com/blog/2026-09-07_proxy-signal-inference-trap/
datePublished: 2026-08-05
---
## The field that lied

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 actually an inference chained off a single string match, no different in kind from guessing someone's employer from their email provider.

The inference held for a while because most of our domains actually did come through us, so the correlation looked like causation until it wasn't. A high school girls' golf team's domain broke it. The customer forwarded a confused reply to that line, and pulling the thread back showed the registrar name pointed at a major third-party registrar, which was true, but the reseller account behind that registration wasn't ours. It was a different reseller entirely, on the same registrar. Same registrar, wrong owner, and the page had no way to tell the difference because it never checked ownership. It checked a string.

## Where I went wrong first

My first fix was to distrust the registrar field and swap in a different derived field: the nameservers. My reasoning was that if the domain pointed at our nameservers, that's a stronger signal of "came through us" than the registrar name ever was. I 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, which for a chunk of customers is us even when the registration itself sits with a reseller we don't control. The NS check flipped 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." I'd traded one wrong inference for another wrong inference, both derived from fields that don't actually encode the fact I needed. I caught it only because I ran the new check against that same known-bad case and it produced a different wrong answer instead of the right one.

## What actually answers the question

The only thing that tells you who owns a domain registration is asking the registrar who owns the registration. So the fix was a reseller lookup: hit that registrar's reseller API directly and check whether the domain's account ID matches ours, instead of inferring it from any field that merely correlates with ownership. That's the only version of the check with no derived signal in the chain.

Shipped as part of one release along 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, regardless of whether 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, because the reseller lookup that fixes the page going forward doesn't retroactively verify who received bad copy already. That's a queue, not a query: each one needs a lookup against the reseller API and a corrected reply if the guess was wrong.

The generalizable failure here isn't "the registrar field was bad data." It's that inferring an identity claim from a correlated field, then swapping it for a different correlated field when the first one breaks, still isn't verification. Only asking the actual source of truth is. The registrar name and the nameservers were both closer to gossip about who owns the domain than to the record of it. The reseller API is the record.