The Domain Search That Couldn't Find Its Own Domain

A small search-driven domain-availability tool on Labinate's roster, Handle & Domain Scout, had a bug that undercut its entire premise: type labinate.dev into it, and it would tell you about the availability of labinate.dev.com instead — a domain nobody typed, checking a TLD nobody asked about.

The root cause was almost embarrassingly simple. Before checking a query, the tool stripped every character outside [a-z0-9-] — a sanitizer meant to catch stray punctuation and whitespace. Dots fell into that category too. So labinate.dev collapsed to labinatedev, and the tool did what it always does with a bare name: expanded it across its own default TLD list (.com, .net, .io, .ai, .co). The dot the user actually typed — the part that made the query mean something specific — never survived long enough to matter.

The fix wasn't a regex patch. Domain suffixes aren't a pattern you can guess at: some are a single label (.dev), some are two (.co.uk, .com.tr), and the only reliable way to tell them apart is a canonical list. So the fix pulls in the ICANN section of the Public Suffix List — the same reference browsers and registrars use — bundled as a local snapshot, and checks the query against it before deciding whether it's looking at a full domain or a bare name.

Verified on the live site: labinate.dev now returns exactly one result — labinate.dev, available — instead of a .dev.com phantom. A bare labinate still expands across the default TLD set, unchanged. Multi-label suffixes like .co.uk resolve correctly too.

Nothing about this bug was exotic. It's the same failure mode any input sanitizer risks: strip first, ask questions never. The fix is boring in the right way — reach for the actual reference data instead of a pattern that happens to work for the common case.