A registrar field rarely tells you much on its own. Aggregated across millions of records, it starts describing how the domain landscape is actually distributed: who registers domains, in which TLDs, in what years, with what expiry windows and what operational settings. Today we are publishing those aggregates as a public page — WHOIS Facts, at primitive.host/whois-facts.
The page summarises almost seven million WHOIS and RDAP records collected from domains discovered through ICANN zone files and web crawling. It refreshes daily, it requires no login, and it deliberately contains no registrant data.
What the page shows
Coverage. How many records the WHOIS collection holds, how that compares to the full tracked inventory (nearly 366 million domains), and the RDAP/WHOIS protocol split. Collection is rate-limited by registry rules and prioritised by TLD, so coverage sits around 2% today — and grows with every collection run. We publish the number rather than hide it.
Registrar distribution. Every registrar in the dataset, ranked by record count, searchable. Raw registrar spellings are folded mechanically — punctuation and case only, never fuzzy matching — so "Namecheap, Inc." and "NAMECHEAP INC" are one row while genuinely different providers stay separate. Registrars whose names are absent from the response are grouped under "Unknown" instead of being dropped.
Registration years. A histogram of when the domains in the set were registered, from the mid-1990s to today. Records with impossible registration dates — before 1990 or in the future — are excluded from the chart and counted openly in the methodology section. Registry data is messy; a public statistics page should say so rather than silently round it away.
Expiry outlook. How many collected records expire within 30 days, 90 days and 12 months, plus how many were already expired when collected. These windows are cumulative — a 30-day record is also in the 90-day count — and the page labels them that way.
TLD coverage and operational signals. Which TLDs the collection covers most, each row linking to the matching domain list, plus nameserver-count distributions, DNSSEC adoption and transfer-lock status across the dataset.
Why publish this at all
Two reasons, both boring on purpose.
First, context. We sell domain data, and data buyers keep asking the same question: what does this dataset actually look like? A coverage page answers that better than a sales conversation — record counts, completeness of registration and expiry dates, per-TLD depth, all recomputed daily.
Second, transparency as a discipline. Every number on the page derives from one counted payload — no hand-tuned percentages, no pre-rounded shares. The methodology section states what is excluded and why, down to the count of records with broken dates. When your statistics page documents its own red flags, readers stop guessing which numbers were massaged.
How it is produced
A scheduled job rebuilds the entire payload once a day from the WHOIS store — a few full-column aggregates, no per-request database work. The page serves a single cached document, so it stays fast regardless of dataset size, and the timestamp at the top tells you exactly when the aggregates were last rebuilt and when the most recent record was collected. If a rebuild ever fails, the previous payload keeps serving with its honest timestamp instead of the page going blank.
One implementation note worth recording: the per-TLD breakdown originally joined every record against the domain index at rebuild time. That join measured over ten minutes against a 365-million-row table, so the TLD is now written onto each WHOIS record when it is classified — the daily rebuild reads one column instead of walking the index, and only new records are classified each run.
What is deliberately absent
Registrant contact details. Emails, phone numbers, postal addresses — none of it is selected by the aggregation, at any layer. WHOIS data carries personal information by nature; a public statistics page can be useful precisely because it publishes counts and never people. The methodology section states this constraint so readers can hold us to it.
Who this is for
Security and threat-intelligence teams benchmarking registrar and TLD distributions against their own case load. Registrars and registries checking how they appear in the wild. Researchers tracking DNS-adjacent trends over time. And anyone evaluating domain datasets who would rather read a methodology section than a positioning deck.
The page is live now at primitive.host/whois-facts. If you find a number that looks wrong, that is exactly the kind of email we want.