Who-Is Domain Listings: How to Look Up Domain Ownership Data

"Who is domain listings" is how most people describe the act of looking up who registered a domain name. The underlying systems are WHOIS and its structured successor RDAP. This article explains what those protocols actually return in 2026, why registrant contact fields are almost always redacted, and what kinds of domain data can still be obtained in bulk — including what WebTrackly publishes and, just as importantly, what it does not.

TL;DR / KEY TAKEAWAYS

• WHOIS answers one narrow question: what a registry and registrar record about a domain's registration — creation and expiry dates, registrar, status codes, and name servers.
• Registrant contact fields are redacted. Since GDPR came into force in 2018, ICANN's temporary specification and its successor policy require most gTLD WHOIS/RDAP responses to hide registrant name, address, phone and mailbox. There is no legitimate way to obtain those fields at scale.
• RDAP replaced WHOIS as the standard protocol. It returns JSON over HTTPS instead of unstructured text, with a documented bootstrap mechanism for finding the right server.
• What does scale well is infrastructure data: which domains exist in a TLD, their name servers, mail exchangers, resolved IP addresses, and the CMS or web platform detected on the live site.
• WebTrackly publishes that infrastructure data as downloadable files — 1,538 packages covering 279,944,703 domains, delivered as CSV inside a ZIP, generated at the moment of purchase.
• The files contain no personal contacts. No registrant names, no mailbox addresses, no phone numbers, no intent data. If you need those, this is not the right dataset.

TABLE OF CONTENTS

• What "Who Is Domain Listings" Actually Means
• What a WHOIS Record Contains, Field by Field
• Why Registrant Contacts Are Redacted After GDPR
• RDAP: The Structured Successor to WHOIS
• The Limits of Per-Domain Lookups
• What WebTrackly Actually Publishes
  • Catalog Structure
  • Coverage Figures
  • The File Schema
  • What the Files Do Not Contain
• The Real Workflow: Buy, Download, Process Locally
• The API: A Catalog, Not a Domain Search
• Pricing and Delivery
• Common Mistakes When Working With Domain Data
• Frequently Asked Questions
• RELATED RESOURCES

What "Who Is Domain Listings" Actually Means

Every domain name is registered through a registrar, which in turn reports the registration to the registry that operates the top-level domain. Both parties keep a record of that registration, and both expose a query interface to the public. WHOIS, defined in RFC 3912, is the oldest of those interfaces: a plain TCP service on port 43 that takes a domain name and returns free-form text.

That text is what people mean by a "who is domain listing." It is a registration record, not a business profile. It describes the administrative relationship between a registrant, a registrar and a registry. It says nothing about what the website does, who works there, or how the business makes money — and it was never designed to.

Confusion arises because the record used to include a name, a postal address, a telephone number and a mailbox for the registrant. For roughly two decades that made WHOIS a de facto public directory. That era ended in 2018, and most of the disappointment people feel when they run a lookup today traces back to that change.

What a WHOIS Record Contains, Field by Field

A typical gTLD response, whether from WHOIS or RDAP, carries the following categories of information:

• Domain name and its internationalised form, plus the registry's internal domain ID.
• Registrar — name, IANA ID, abuse contact, and the registrar's own WHOIS server.
• Dates — creation, last update, and expiry. These are the most reliably populated fields in the whole record and the reason registration-date data is usable at all.
• Status codes — EPP statuses such as clientTransferProhibited, serverHold, pendingDelete or redemptionPeriod. These describe the lifecycle state of the registration and are genuinely informative: a domain in redemptionPeriod has expired and is inside its recovery window.
• Name servers — the authoritative DNS servers delegated for the domain. This field is public by policy and is one of the few that remains complete.
• DNSSEC — whether the delegation is signed.
• Contact objects — registrant, admin, tech and billing. In the overwhelming majority of gTLD records these are now redacted placeholders.

Coverage varies by TLD. ccTLD registries set their own policy: some publish a fuller record than gTLDs, many publish considerably less, and a number rate-limit or CAPTCHA-gate their WHOIS service entirely. There is no single global standard for what a "who is domain listing" must contain beyond the ICANN contract, which binds gTLDs only.

Why Registrant Contacts Are Redacted After GDPR

When the General Data Protection Regulation became enforceable in May 2018, publishing the personal details of every EU-resident domain registrant in an anonymously queryable directory became untenable. ICANN adopted a Temporary Specification that required contracted parties to withhold most registrant contact fields from public output, later formalised through the Registration Data Policy. In practice, registrars applied redaction globally rather than trying to determine which registrants were covered by EU law.

The practical consequences for anyone building on this data:

• Registrant name, organisation, street, city, postal code, telephone and mailbox are replaced with strings such as REDACTED FOR PRIVACY or Data Protected.
• Country and sometimes state or province survive in many records, which is why country-level distributions are still partially derivable from registration data.
• Registrars typically expose an anonymised relay — a web form or a per-domain forwarding address — that lets someone reach the registrant without disclosing their identity. Relays are not extractable contact data and are rate-limited by design.
• Access to unredacted data exists only through gated, request-based channels for parties with a demonstrated legal basis, evaluated case by case. It is not a bulk feed, and no commercial dataset can lawfully substitute for it.

Privacy and proxy services predate GDPR and add a second layer: even where a registry would publish contact data, the registrant may have paid for a proxy to stand in as the nominal holder. Between redaction and proxying, treating WHOIS as a source of contact information is no longer a viable strategy at any scale.

RDAP: The Structured Successor to WHOIS

RDAP — the Registration Data Access Protocol, specified in RFC 7480 through RFC 7484 and RFC 9082/9083 — was designed to fix WHOIS's structural problems. It runs over HTTPS, returns JSON, supports internationalisation properly, and defines a bootstrap file published by IANA so a client can determine which server is authoritative for a given TLD or IP range. All gTLD registries and registrars have been required to operate RDAP services since 2019, and the WHOIS port-43 requirement was subsequently sunset.

A minimal lookup looks like this:

# Find the authoritative RDAP base URL for the TLD
curl -s https://data.iana.org/rdap/dns.json | jq '.services[] | select(.[0][] == "com")'

# Query a domain
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '{
  ldhName,
  status,
  events: [.events[] | {eventAction, eventDate}],
  nameservers: [.nameservers[].ldhName]
}'

The important thing to notice in that output is the shape of what comes back. Events, statuses and name servers are structured and populated. The entities array — where registrant, admin and tech contacts live — will contain a registrar entity with an abuse contact, and a registrant entity whose vCard fields are redacted. RDAP changed the encoding, not the disclosure policy.

RDAP is also rate-limited, per-query and per-domain. It is the correct tool for investigating one domain, verifying an expiry date, or checking a status code before a transfer. It is the wrong tool for building a dataset of a million domains.

The Limits of Per-Domain Lookups

Suppose you want to answer a question like "how many domains in this TLD run WordPress" or "which name servers are most common in .de." A per-domain protocol cannot answer it. You would need to know the population of domains first, then query each one, then fetch each website separately because WHOIS and RDAP say nothing about what software the site runs.

Three separate data sources are required:

1. The population — which domains exist in a zone at all. This comes from zone files or equivalent registry-derived listings, not from WHOIS.
2. DNS resolution — the name servers, mail exchangers and A records for each domain, obtained by resolving them.
3. Platform detection — what the live site returns, obtained by fetching it and matching signatures in the HTML, headers and asset paths.

Doing this yourself is a real engineering project: zone file access agreements or equivalent sources, a resolver farm that will not get you rate-limited into oblivion, a polite crawler, and storage for hundreds of millions of rows. Buying the output of that pipeline as a file is usually cheaper than rebuilding it.

What WebTrackly Actually Publishes

Catalog Structure

WebTrackly's catalog contains 1,538 packages, split into four kinds:

Zone packages are browsable at /zones/, curated compilations at /datasets/, and the full catalog at /packages/.

Coverage Figures

• 279,944,703 domains across all zones.
• 163,422,083 domains in .com alone.
• 21,639,326 domains with WordPress detected.
• 607,765 domains with Joomla detected.
• 272,614,863 rows in the all-registered-domains dataset.

Those numbers are worth reading carefully. The WordPress figure is a count of domains where WordPress was detected on the live site — not a count of WordPress installations in existence, and not a claim about every domain in the catalog having been fetched. Detection requires a responding website; parked, redirected and non-resolving domains are present in the zone lists but carry no platform value.

The File Schema

An enriched per-zone package is a CSV with roughly this shape:

domain,created,ns,mx,ip,cms
example.com,2011-04-17,ns1.example-dns.net;ns2.example-dns.net,mx1.mailhost.net,203.0.113.14,WordPress
sample.com,,ns1.hoster.io;ns2.hoster.io,,198.51.100.7,

Field notes, because the caveats matter more than the header row:

• domain — always present. This is the primary key.
• created — the registration date, populated only where the registry publishes it. A large number of ccTLDs do not, so expect this column to be sparse outside the major gTLDs.
• ns — delegated name servers. Useful for hosting and DNS-provider analysis, and one of the most complete columns in the file.
• mx — the mail exchange records for the domain: the hostnames of the servers that accept mail for it, such as a Google Workspace or Microsoft 365 endpoint. These are server names, not mailbox addresses.
• ip — the resolved address at collection time. Sites behind a CDN resolve to the CDN's edge, which is a fact about the CDN, not about where the origin lives.
• cms — the platform detected on the live site, blank where nothing was detected or the site did not respond.

What the Files Do Not Contain

Stated plainly, so there is no ambiguity before you buy:

• No personal contact data. No registrant names, no mailbox addresses, no telephone numbers, no named individuals at any company. This is a deliberate design decision and a consequence of the redaction described above — that data is not lawfully available at this scale, and any vendor offering it at volume should be questioned closely.
• No intent or buying signals. Nothing about whether an organisation is evaluating a purchase.
• No traffic, revenue or headcount estimates.
• No per-domain lookup service. The product is bulk files, not a query API over individual domains. For a single domain, use RDAP directly as shown above.
• No technology search in the interface. Technology grouping exists as a set of prepared packages; it is not an interactive query builder.

The Real Workflow: Buy, Download, Process Locally

The flow is deliberately simple, and everything after the download happens on your own machine:

1. Pick a package from /packages/, /zones/ or /datasets/, based on the zone or platform you care about.
2. Buy it. The export is generated fresh at the moment of purchase rather than served from a stale pre-built archive.
3. Download the ZIP immediately — delivery is a direct download, with CSV inside the archive.
4. Unpack and query locally. No API round-trips, no per-row metering.

unzip com-enriched.zip
wc -l com-enriched.csv

# Quick filtering with standard tools
grep -c ',WordPress$' com-enriched.csv
awk -F, '$6 == "Joomla" { print $1 }' com-enriched.csv > joomla-domains.txt

For anything larger than a few million rows, a columnar engine is far more comfortable than shell tools. DuckDB reads CSV directly with no import step:

-- DuckDB: top name server providers in a zone
SELECT
    regexp_extract(split_part(ns, ';', 1), '([^.]+\.[^.]+)$', 1) AS ns_domain,
    count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE ns IS NOT NULL AND ns <> ''
GROUP BY 1
ORDER BY domains DESC
LIMIT 25;

-- Registration cohorts, where the registry publishes creation dates
SELECT date_trunc('year', created) AS cohort, count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE created IS NOT NULL
GROUP BY 1
ORDER BY 1;

ClickHouse is the better choice if you intend to keep several zones loaded and query them repeatedly:

CREATE TABLE domains
(
    domain  String,
    created Nullable(Date),
    ns      String,
    mx      String,
    ip      String,
    cms     LowCardinality(String)
)
ENGINE = MergeTree
ORDER BY domain;

INSERT INTO domains
SELECT * FROM file('com-enriched.csv', 'CSVWithNames');

Typical analyses this supports: hosting and DNS market share by zone, CMS distribution across TLDs, mail-provider concentration, registration cohort curves for zones that publish creation dates, and IP-range clustering to identify infrastructure operated by a single provider.

The API: A Catalog, Not a Domain Search

The API exposes the package catalog. It lets you discover and inspect what is available and automate purchasing decisions; it does not search individual domains, because domain data is delivered as files.

# List zone packages
curl -s "https://webtrackly.com/api/v1/packages/?type=zone" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Find technology packages matching a term
curl -s "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Inspect a single package
curl -s "https://webtrackly.com/api/v1/packages/{slug}/" \
  -H "Authorization: Bearer YOUR_API_KEY"

A minimal Python client over the same endpoints:

import requests

BASE = "https://webtrackly.com/api/v1"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}

zones = requests.get(f"{BASE}/packages/", headers=HEADERS,
                     params={"type": "zone"}).json()

for pkg in zones.get("results", []):
    print(pkg["slug"], pkg.get("domains_count"))

detail = requests.get(f"{BASE}/packages/com/", headers=HEADERS).json()
print(detail)

Full endpoint documentation lives at /api/.

Pricing and Delivery

Individual packages are one-time purchases starting at $3.50, delivered as CSV inside a ZIP with an instant download and no subscription attached. Two subscription plans cover repeated use:

Current details are on /pricing/.

Common Mistakes When Working With Domain Data

1. Expecting WHOIS to identify a business. It identifies a registration. Even before redaction, the registrant was frequently a hosting company, an agency or a proxy service rather than the organisation behind the website. Use registration data for lifecycle and delegation questions, and infrastructure data for questions about the site itself.

2. Treating a resolved IP as the origin server. Any domain behind a CDN or reverse proxy resolves to the edge. Aggregating IPs without accounting for this produces a chart about CDN adoption while appearing to be a chart about hosting.

3. Assuming an empty CMS column means "no CMS." Blank means nothing was detected, which also covers sites that did not respond, redirected away, blocked the fetch, or run something with no reliable signature. Report detection rates alongside detection counts, or the denominator quietly lies.

4. Reading missing creation dates as new registrations. Many ccTLD registries do not publish creation dates at all. A sparse column is a policy artefact, not a signal about domain age.

5. Ignoring how quickly this data ages. Domains expire, name servers move, sites get rebuilt. Any snapshot is a point-in-time observation. If a decision depends on current state, re-pull the relevant package rather than reusing a file from last quarter.

6. Loading hundreds of millions of rows into a spreadsheet. Spreadsheets cap out long before these files do. A columnar engine on a laptop handles the full .com zone comfortably; a spreadsheet will not open it at all.

Frequently Asked Questions

Q: Can I get registrant names and contact details from a WHOIS lookup?
A: For most gTLD domains, no. Registrant contact fields have been redacted since ICANN's post-GDPR policy took effect in 2018. Registrars typically offer an anonymised relay to reach a registrant without disclosing identity, and gated request-based access exists for parties with a demonstrated legal basis. Neither is a bulk source, and WebTrackly's files do not contain personal contact data of any kind.

Q: What is the difference between WHOIS and RDAP?
A: RDAP is the standardised replacement. It serves JSON over HTTPS, supports internationalised text properly, and publishes an IANA bootstrap file so clients can locate the authoritative server for any TLD. WHOIS returns unstructured text over port 43 whose format differs between registries. RDAP changed the encoding and transport; it did not change what is disclosed.

Q: What format do WebTrackly packages arrive in?
A: CSV inside a ZIP archive, downloaded directly after purchase. The export is generated at the moment of purchase rather than served from a pre-built archive.

Q: How many domains are covered?
A: 279,944,703 across all zones, including 163,422,083 in .com. The all-registered-domains dataset contains 272,614,863 rows. Technology packages cover 21,639,326 domains with WordPress detected and 607,765 with Joomla.

Q: Can I look up a single domain through WebTrackly?
A: No. The product is bulk files organised by zone, technology or curated dataset. For a single domain, query RDAP directly — it is free, authoritative for registration data, and takes one HTTP request.

Q: Does the API let me filter domains by technology or country?
A: The API serves the package catalog, not a domain-level query engine. You can list and filter packages by type and search term, then buy and download the ones you need. Filtering individual rows happens locally, in DuckDB, ClickHouse or whatever tooling you prefer.

Q: How current is the data?
A: Exports are generated at purchase time from the current state of the catalog. Because the web changes continuously, treat any download as a snapshot and re-pull before decisions that depend on present-day state.

Q: What are the plan limits?
A: Pro is $29/month for 50 packages, 10 datasets and 30,000 API calls. Enterprise is $99/month for 200 packages, 50 datasets and 300,000 API calls. Individual packages can also be bought one-off from $3.50. See /pricing/.

WebTrackly publishes domain zone, DNS and CMS-detection data as downloadable files.
Browse Domain Data → | View Pricing →

Related Resources

• Package Catalog — 1,500+ downloadable domain databases
• Zone Files by TLD — .com, .net, .de and 700+ more
• Curated Datasets — all registered domains, MX servers, e-commerce
• Pricing — one-time purchases from $3.50