`quien`: The Domain Intel Tool That Refuses to Trust Just One Protocol

A modern Go TUI that merges RDAP, WHOIS, DNS, TLS, and SEO signals into one response, using a resolver smart enough to follow referrals, normalize registrable domains, and fill in missing data.

8-10 min read · retlehs/quien

By Repo Explainer • AI-assisted • Published by Ron Kurti

Published Apr 14, 2026 • AI Dev CLIs

A wide editorial scene shows a terminal operator at a desk surrounded by fragmented domain intelligence sources, including paper dossiers, a registry ledger, DNS maps, and network cables. The image explains how the tool turns scattered protocol data into one coherent investigation. — `quien` treats domain lookup like investigation work. One query fans out across several protocols, then recombines into a single answer.

Key Takeaways

`quien` is interesting because it treats domain intelligence as a reconciliation problem, not a single lookup problem.
Its hybrid resolver uses RDAP as structured truth, then backfills missing details from WHOIS instead of pretending either source is complete.
The public suffix logic matters as much as the network calls, because registrable-domain normalization prevents bad queries and false confidence.
The TUI is not decoration. It turns a messy multi-protocol workflow into something you can actually use under pressure.

The internet’s identity crisis, solved one lookup at a time

A domain name looks simple until you ask it useful questions. Then you discover the data lives across WHOIS, RDAP, DNS, TLS, HTTP, SEO, and BGP, each with different syntax, different coverage, and different failure modes.

`quien` is built around that mess. It does not try to replace the old world with one clean protocol. It accepts that the internet’s identity data is fragmented, then stitches it together into one terminal workflow.

What `quien` actually does when you ask about a domain

The core design is a pipeline, not a menu of commands. `quien` normalizes first, resolves in parallel, and merges at the end.

That pipeline is the project’s main idea. RDAP and WHOIS are queried in parallel, but they are not treated equally. RDAP is the structured baseline. WHOIS exists to fill gaps, especially when registries omit contact or registrar detail.

That is a subtle but important choice. A lot of tools stop at the first answer. `quien` keeps going until the answer is more complete, or at least more honest about what is missing.

Why the normalization step matters

The resolver does not just split strings and hope for the best. It uses public suffix logic to decide what the registrable domain actually is, which is the difference between querying a real domain and interrogating a registry boundary that does not mean what you think it means.

That matters for ccTLDs and nested suffixes, where naive parsing quietly breaks. In other words, `quien` is not just protocol-aware. It is domain-aware.

A close-up editorial scene shows two trays feeding a dossier assembly line. One tray labeled RDAP drops in neat structured cards, while a WHOIS tray drops in messy index cards with a few missing fields. A careful hand sorts and merges them into one complete file. The image explains how structured and unstructured data are reconciled into a single result. — RDAP gives structure. WHOIS gives coverage. `quien` uses both, but it trusts structure first.

The trick is not fetching data. It is deciding what counts as truth

The most interesting code in `quien` is not the network plumbing. It is the decision logic around authority. RDAP bootstrap discovery finds the right server dynamically through IANA. WHOIS referral handling follows the trail when an initial server punts you to a registrar.

That makes the resolver feel less like a scraper and more like a detective. It asks the obvious source first, then follows the chain until the answer stops moving.

// Conceptual shape of the resolver
rdapResult, whoisResult := lookupRDAP(domain), lookupWHOIS(domain)
merged := mergeFromWhois(rdapResult, whoisResult)

if merged.Registrar == "" {
    merged.Registrar = whoisResult.Registrar
}
if merged.Contacts.Empty() {
    merged.Contacts = whoisResult.Contacts
}
return merged

The codebase also leans on the Public Suffix List so it can normalize domains correctly before any lookup starts. That prevents the whole pipeline from wasting time on the wrong target.

This is the kind of detail that separates a flashy CLI from an infrastructure tool. The output may look simple. The reasoning behind it is not.

Why the terminal interface matters

Bubble Tea is not just aesthetic sugar here. It gives the resolver room to work asynchronously while the interface stays alive, responsive, and honest about state. That matters when one lookup fans out into several network calls and referrals.

In practice, the TUI turns a pile of latency into a workflow. You can see the tool loading, branching, and resolving instead of staring at a blank prompt and wondering whether it hung.

Tool	Sources	Referral handling	Domain awareness	User experience
`whois` CLI	WHOIS only	Manual	Limited	Fast, but brittle
Basic RDAP client	RDAP only	Usually none	Better, but incomplete	Clean, but narrow
`dig` / `nslookup`	DNS only	No	No	Great for DNS, nothing else
`quien`	RDAP, WHOIS, DNS, TLS, HTTP, SEO, BGP	Automatic	Public-suffix aware	One interactive investigation

That comparison is the point. `quien` is not trying to beat `whois` at being `whois`. It is compressing a whole investigative workflow into one terminal session.

A domain is more than a name

The repo’s extra tabs are not feature creep. They reflect a useful truth: a domain is a bundle of operational signals. DNS says how it resolves. TLS says how it presents itself. HTTP and SEO add surface context. Mail and stack checks can expose whether the domain is healthy, configured, or quietly broken.

That broader surface area is why the tool feels practical rather than academic. A single answer is nice. A useful answer is better.

What `quien` is really competing with

The real competitor is not one binary. It is a habit: open several tools, keep several mental models in your head, and manually reconcile the results. `quien` removes that context switching.

It also makes a nice distinction between breadth and bloat. The project collects more signals, but the resolver keeps them organized around one core question: what is this domain, and what can we actually trust about it?

Workflow	What you do	What you get
Manual stack	Run `whois`, `dig`, browser checks, and separate RDAP clients	More work, more context switching
`quien`	Ask once in a terminal UI	A merged domain dossier with fewer blind spots

Why this repo feels mature

The structure looks deliberate. Protocol clients live in their own packages. Display logic stays separate from retrieval. The resolver owns orchestration, not presentation. That separation makes the code easier to test and easier to extend.

Packaging matters too. GoReleaser, Homebrew, and AUR support turn a good CLI into something people can actually adopt. The project reads like something designed for repeated use, not a demo that happened to ship.

That maturity shows in the product philosophy as well. `quien` is trying to be dependable under messy conditions, which is exactly what domain intelligence tools need to be.