quien: one terminal view of a domain's WHOIS, DNS, mail, TLS, SEO and stack

RDAP first, WHOIS as the fallback

quien is described as a better whois and domain intelligence toolkit, and the first design decision in the README is the lookup strategy. The features list opens with RDAP-first lookups with WHOIS fallback for broad TLD coverage, and IANA referral for automatic WHOIS server discovery.

That is a sensible order. RDAP is the structured successor to WHOIS, it is a documented JSON API, and it returns fields a whois client has to scrape out of a formatted text blob. The problem is coverage, because RDAP is not universally deployed across registries, and for the TLDs where it is missing, a whois client is still the only way in. Hence the fallback.

The interesting engineering is the middle case, the domain that has no RDAP endpoint but does have a whois server, and where the whois server itself is not published anywhere obvious. IANA referral is the mechanism: the whois server for a TLD is recorded in the IANA root zone database, so a client that asks IANA for the referral for the TLD learns which whois server to query, and the query proceeds as normal. The result is that quien can do a whois lookup for an obscure TLD without a hardcoded per-registry table, which is exactly the maintenance burden that makes most whois clients rot.

The IP side follows the same pattern. IP lookups include reverse DNS, network info, abuse contacts and ASN discovery via RDAP, with a BGP fallback for origin ASN and prefix when RDAP does not include ASN data, and then PeeringDB enrichment for ASN context, giving network and organisation, peering policy, peering locations, traffic profile and IX and facility counts.

The layering of three sources for one number is worth noting. RDAP is authoritative where it exists, BGP is the ground truth for routing, and PeeringDB is the human-maintained context that tells you what kind of network you are looking at and who you would peer with. A tool that consults all three is giving you a picture rather than a record.

The primary language is Go, the licence is MIT, and the release history is a steady minor-version line, v0.10.0, v0.11.0 and v0.12.0 in the second half of 2026, with the last push on 2026-10-15.

The mail audit, which is where the real analysis is

Among the feature list, the mail configuration audit is the one that does actual analysis rather than retrieval. The README describes it as MX, SPF with lookup-count and include/redirect tree expansion, DMARC, DKIM, and BIMI with VMC chain validation.

Read that carefully, because it is the difference between a tool that prints records and a tool that judges them.

SPF by itself is a string. A correct SPF record has a hard limit on DNS lookups, typically ten, and it consists of mechanisms that can trigger further lookups, includes and redirects, each of which can pull in another domain's record. A record can be syntactically valid and still fail because the expansion exceeds the limit, and a naive client that prints the raw TXT record will not show you that. The lookup-count and include/redirect tree expansion in quien is what makes the SPF check meaningful.

DKIM has a similar problem in a different shape. The selector is part of the DNS name, so a DKIM key is only findable if you know which selectors the domain publishes, and the common ones are a short list of conventions, default, google, selector1, selector2, mail, dkim, s1, s2 and similar. The README says user selectors are probed in addition to the built-in common-selector list, which is the honest way to handle it, because a domain using a non-standard selector is invisible to any tool that only tries the common list. The command line support makes that explicit:

quien mail example.com --dkim-selector mySelector --dkim-selector other

or with an environment variable, QUIEN_DKIM_SELECTORS=mySelector,other quien example.com. The README states the precedence rules for both settings, and that the user selectors are probed in addition to the built-in list.

BIMI with VMC chain validation is the deepest of the four. A BIMI record points at a logo, and a Verified Mark Certificate is a separate document that has to chain up to a trusted root, so a BIMI entry that looks fine can still fail because the VMC does not validate. That is the kind of check that only appears in a tool written by someone who has actually had to debug a BIMI deployment.

Taken together, the mail tab is the part of quien that would justify installing it on its own, and it is the part most likely to save you an afternoon of manual digging.

SEO signals, and Core Web Vitals when you have a CrUX key

The SEO analysis is broken into four groups in the README. Indexability covers robots.txt, canonical and sitemap. On-page covers title, description, headings and images. Structured data covers JSON-LD, Open Graph and Twitter Cards. And performance hints cover compression, caching and render-blocking resources.

Those are the checks a human auditor does by opening four browser tabs. Doing them in one place is a convenience, and the performance hints in particular are the kind of thing you would otherwise only notice with a page-speed tool that wants an API key and a few seconds of measurement.

Core Web Vitals are handled differently, because the local checks are local checks. The README is explicit: the SEO tab includes local checks out of the box, and for field data, which is real-user metrics from Chrome, you need a CrUX API key:

export QUIEN_CRUX_API_KEY=your-api-key

With that set, the tool reports LCP, INP, CLS, FCP and TTFB p75 values with good, needs-improvement and poor ratings, plus an 8 to 25 week trend sparkline.

The p75 is the right number to look at, since p75 is the threshold Google uses, and the trend sparkline is the part that answers the question a single reading cannot, which is whether a metric is getting better or worse.

The README also flags the coverage limit: not all domains have field data, because a site needs enough Chrome traffic to be included in the Chrome User Experience Report. That is a real constraint and it is stated up front rather than discovered when the numbers do not appear. The detailed steps for creating and restricting the API key are in a collapsed section, including the instruction to select Chrome UX Report API under API restrictions, which is a sensible default for a key that only needs one API.

The JSON subcommands, and the resolver precedence rules

The README lists JSON subcommands for scripting: quien whois, quien dns, quien mail, quien tls, quien http, quien seo, quien stack and quien all. That is the difference between a tool for a person and a tool for a pipeline, and it is the feature that makes quien usable in CI.

# JSON output
quien --json example.com

# JSON subcommands
quien whois example.com
quien dns example.com
quien mail example.com
quien tls example.com
quien http example.com
quien seo example.com
quien stack example.com
quien all example.com

The global --json flag applies to the interactive TUI path, and the subcommands give you one tab's worth of data as JSON, which is what you want in a script. quien all is the one to reach for when you want a complete record of a domain in one call.

The precedence rules are documented precisely, and they are the kind of thing that matters when you are debugging why a script produced a different answer from your terminal. Resolver precedence is --resolver over QUIEN_RESOLVER over the system resolver. DKIM selector precedence is --dkim-selector over QUIEN_DKIM_SELECTORS, with user selectors probed in addition to the built-in common list.

# Use a specific DNS resolver for this run
quien mail example.com --resolver 9.9.9.9

# Set a default resolver via environment variable
QUIEN_RESOLVER=1.1.1.1 quien dns example.com

The Troubleshooting DNS section explains when you need this. If your system resolver is unreliable, which it says is common in WSL, VPN or container setups, you force a resolver. That is a real operational detail, because a whois or SPF lookup that returns NXDOMAIN because your local resolver is broken looks exactly like a misconfigured domain, and the difference between those two diagnoses is a resolver override.

There is also an automatic retry with exponential backoff on all lookups, which matters for a tool that makes many DNS queries per domain.

Two more conveniences are documented. quien automatically detects your terminal background and picks light or dark colours, with QUIEN_THEME set to light, dark or auto to override, and the detection getting it wrong is described as common in tmux, screen or remote shells. And there is a tip for replacing your default whois tool with an alias, alias whois=quien, in your shell config, which tells you something about the author's intent: quien is meant to be the whois command you already type.

Installing it, and the SSH demo

The install section covers five routes, and the first thing in the README is the one that requires nothing.

Try it without installing: `ssh quien.sh`. A binary served over SSH for a tool whose whole value is that you can run it against a domain without changing anything is a sensible design for a trial.

The package managers follow. Homebrew:

brew install quien

Ubuntu and Debian, via an install script:

curl -fsSL https://apt.quien.dev/install.sh | sudo sh

Arch Linux through the AUR:

yay -S quien

NixOS and Nix through a flake:

nix shell github:retlehs/quien

And from Go source:

go install github.com/retlehs/quien@latest

The Go module path is github.com/retlehs/quien, and go.mod requires go 1.26.4. The dependency list is short and tells you the shape of the thing: charm.land/bubbletea/v2 for the TUI framework, bubbles for the components, lipgloss for the styling, miekg/dns for the DNS queries, cobra for the command tree, and golang.org/x/net and golang.org/x/term. The build is a single Go binary with a .goreleaser.yml for releases, and the repository has a packaging/ directory, a cmd/ directory, an internal/ directory and a main.go.

There is one more feature aimed squarely at a particular audience. The README describes an agent skill, so that agents use the tool for domain and IP lookups:

npx skills add retlehs/quien

The SKILL.md file at the repository root is the skill definition. For a tool that answers structured questions about domains, exposing it to an agent as a skill is a sensible move, and it tells you the author expects the tool to be driven by machines as much as by people.

For a personal or scripted use, the Go install or the SSH demo is the shortest path. The Debian install script pipes to sudo sh, which is a common convenience and also a habit worth thinking about, since it runs a remote script as root.

Where quien is the wrong tool

There are three limits, and the first is about scale.

The first is that this is an investigation tool, not a scanning platform. The JSON subcommands are what make it scriptable, and the automatic retry with exponential backoff on all lookups is what makes a single domain's worth of queries reliable. But a single domain's worth of queries means a whois, a set of DNS lookups, MX and SPF expansion, DKIM selector probing, a TLS handshake, an HTTP request and a page parse. Doing that for ten thousand domains is a distributed-systems problem with a rate limit problem inside it, and the README describes nothing like that. A tool built for continuous monitoring of a portfolio, or for a scanner that needs a list of domains, is a different program.

The second is that the data is only as authoritative as its sources, and the sources are heterogeneous. RDAP is authoritative, WHOIS is scraped text, BGP is routing reality, PeeringDB is human-maintained, the CrUX field data is a sample of real Chrome users, and the SEO checks are the tool's own opinion about what a good page looks like. The README is careful to distinguish local checks from field data, which is the right instinct, but a user reading a report can easily treat a local heuristic and a p75 field measurement as the same kind of statement.

The third is the offline and air-gapped case. The tool is built to reach out to the internet, to IANA, to RDAP endpoints, to whois servers, to DNS resolvers, to the PeeringDB API, to the CrUX API and to the site itself. There is no offline mode described, no cache file, and no way to point it at a saved copy of the data. For an investigation of a domain you have already captured, or for a review of a zone file in an isolated network, it is the wrong shape.

There is a fourth point about the DNS resolver override that is worth stating plainly. Forcing a resolver is a diagnostic tool, and it changes what you can see. An authoritative resolver and a recursive resolver can return different answers for a split-horizon domain, and a resolver that is authoritative for your own zone will answer from the zone rather than from the public root. So when you override the resolver to work around a broken local setup, you may be looking at a different view of the domain than the rest of the world sees, and the SPF and DKIM results in particular can differ.

Editorial conclusion

Adopt quien if you do domain or IP investigations from a terminal and want one tool that returns the registration, the mail configuration, the certificate and the site signals together instead of a dozen separate lookups. Do not adopt it for bulk scanning or continuous monitoring, because the design is an interactive investigation tool with per-lookup retries rather than a high-throughput pipeline. Verify first that the RDAP coverage of the registries you care about is adequate, that the SPF and DKIM expansion reflects the record you actually publish, and that the resolver you force with --resolver or QUIEN_RESOLVER is one that answers authoritatively for the zone.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. retlehs/quien on GitHub