LookalikeLedger

Fence the domains that read like a brand you own, and record the ones somebody already took.

Comment

Inspiration

Defensive domain registration is one of those chores everybody agrees with and nobody finishes. You check a handful of typos by hand, register two of them, and the rest of the list dies in a spreadsheet. Six months later somebody registers the one you skipped.

What bothered me more is the half of the problem no purchase can fix. Some of those lookalikes are already taken, and that is not a shopping list — that is a finding. I wanted a tool that treats it that way.

What it does

You give it a domain you already own. It generates the names that read like it — single-character typos, adjacent-key slips, transpositions, hyphen insertions, and homoglyph rewrites where rn reads as m and 1 reads as l — plus the same label in the other zones you care about.

Then it does three things in one pass:

  1. Checks every candidate against name.com and splits them into already taken and still free.
  2. Registers the highest-risk free ones, capped at two per run.
  3. Gives each newly registered name an A record pointing at an address you control and a TXT marker saying why it exists.

It finishes with a receipt: what was fenced, what was already gone, and a SHA-256 over the whole thing.

The output people actually stop and read is the already taken list, ranked by how convincing each name is. acrnepay.com sitting at the top of that list is a different kind of message than a row in an availability table.

How I built it

Plain Node with no framework. The variant generator is pure and deterministic, so the risk model could be tested without spending a single API call — every emitted label is checked against the syntax a registrar will actually accept before it ever reaches the network.

Three name.com Core API endpoint families do the real work: POST /core/v1/domains:checkAvailability classifies, POST /core/v1/domains registers, and POST /core/v1/domains/{domain}/records anchors. The registrar's own purchasable, premium, and purchaseType fields decide what may be bought; nothing is inferred.

Everything runs against the name.com sandbox, and the client refuses any other host. The tool registers domains — pointing it at production would spend real money on every run, so that is a hard gate rather than a config flag.

Challenges I ran into

Deciding what "risk" means was harder than the integration. My first ranking treated every single-character edit equally, which is wrong: a keyboard slip needs the reader to make a mistake, but a homoglyph does not. Weighting homoglyphs and same-label TLD swaps above ordinary typos, and discounting typos outside the brand's own zone, made the top of the list match what a person would actually worry about.

The other thing I got wrong first was treating registration as the finish line. A defensive domain that resolves nowhere quietly becomes somebody's parked-page problem, so the DNS call had to move inside the run rather than sit in a follow-up task. That is why a failed registration records the failure and stops, instead of leaving a name half-fenced.

Accomplishments that I'm proud of

The fencing budget is spent whether a run succeeds or fails. That sounds like a bug until you think about what the alternative does: a freely retryable failure is a failure that can register the same name twice.

Fifteen network-free tests cover the ranking, the registrar gates, and the failure paths — including one that asserts the API token never reaches an error message, and one that catches a response policy strict enough to block the page's own calls. The server binds to loopback, exchanges a startup capability for an HttpOnly cookie, and never lets the browser see the credentials.

What I learned

Availability data alone makes a search box. What turns it into a control is holding search, registration, and DNS in the same transaction and refusing to call the run finished until all three agree.

I also learned to read a registrar API as an authority rather than a data source. purchasable and premium are not hints to be second-guessed — they are the only correct basis for deciding what to buy.

What's next for LookalikeLedger

Watching certificate transparency for the already-taken names, so a lookalike that starts serving HTTPS raises something louder than a row in a receipt. Beyond that, a scheduled re-run that only reports the delta, because this is a chore that needs to happen quarterly and nobody wants a fresh wall of text each time.

Built With

Share this project:

Updates