Who Owns .com Domains? Understanding .com Registration Data

"Who owns .com" is one question with two very different answers. At the registry level the answer is precise and public: .com is operated by Verisign under contract with ICANN, and the registry publishes a zone file listing the domains that exist. At the individual-registrant level the answer is mostly unavailable: since GDPR, most WHOIS records for .com are redacted. This article explains what .com registration data actually contains, what you can and cannot learn from it, and what WebTrackly ships — downloadable zone and enrichment datasets, including 163,422,083 .com domains.

TL;DR / Key Takeaways

• Registry vs. registrar: Verisign runs the .com registry; registrars such as GoDaddy or Namecheap sell and manage registrations. Registrant records live with the registrar, not in the zone file.
• The zone file answers "what exists": it lists delegated domains and their name servers — not names, not addresses, not contacts.
• WHOIS no longer answers "who": registrant details for .com are redacted by default for privacy reasons, so per-domain ownership lookup at scale is not realistic.
• Enrichment answers "what it runs and where it is hosted": NS, MX, IP and detected CMS are derived from DNS and HTTP responses, and they are the practical substitute for ownership data.
• What WebTrackly ships: 1,538 downloadable packages covering 279,944,703 domains, delivered as CSV inside a ZIP, generated at the moment of purchase. The .com zone alone is 163,422,083 domains.
• What it does not ship: no personal contacts, no intent data, no per-domain lookup, no interactive technology search.

Table of Contents

• Who Actually Owns .com: Registry, Registrar, Registrant
• What the .com Zone File Publishes — and What It Does Not
• Why WHOIS No Longer Answers the Ownership Question
• From "What Exists" to "What It Runs": DNS and Technology Enrichment
• What WebTrackly Actually Provides
  • Coverage and Package Types
  • Data Schema and What the Files Do Not Contain
• Working With the Data: Buy, Download, Process Locally
• The API: A Catalog of Packages
• Common Mistakes When Working With Domain Data
• Frequently Asked Questions (FAQ)
• Conclusion
• Related Resources

Who Actually Owns .com: Registry, Registrar, Registrant

Three distinct parties are involved in every .com domain, and confusing them is the source of most bad assumptions about domain data.

• The registry operates the TLD itself. For .com that is Verisign, under a registry agreement with ICANN. The registry maintains the authoritative database of which .com names are delegated and which name servers they point to, and it runs the authoritative DNS infrastructure for the zone.
• The registrar is the accredited company that sells a registration to an end customer — GoDaddy, Namecheap, Tucows, Cloudflare and hundreds of others. The registrar holds the customer relationship, the billing details and the registrant contact record.
• The registrant is the person or organisation holding the right to use the name for the registration period. Nobody "owns" a domain outright; a registration is a renewable right, not a freehold.

This split matters in practice. The registry can tell you, comprehensively, which names exist. It cannot tell you who is behind them, because it never holds that information in a form it publishes. The registrar holds registrant identity, but distributes it only through WHOIS/RDAP, subject to privacy redaction.

What the .com Zone File Publishes — and What It Does Not

A zone file is the DNS delegation list for a top-level domain. For .com it enumerates every second-level name that has active name servers, together with the NS records that delegate it and the glue A/AAAA records where those name servers live inside the zone itself. Access to registry zone files for gTLDs is provided through ICANN's Centralized Zone Data Service to approved parties.

What a zone file gives you:

• The complete set of delegated names under the TLD — the closest thing that exists to a census of the web at the naming layer.
• The name servers each domain is delegated to, which is a strong signal of the DNS provider and often of the hosting platform behind the site.
• A reliable basis for diffing: names that appear or disappear between two snapshots.

What a zone file does not give you:

• Registrant names, organisations, postal addresses or any contact details.
• Registration or expiry dates — those come from the registry's WHOIS/RDAP service, and only some registries publish them in bulk.
• Registered names that have no name servers configured. A domain can be registered and not delegated; it will simply be absent from the zone.
• Anything about the content, business model or size of the site.

In other words, the zone file is an answer to "what exists", and an unusually complete one. It is not, and was never designed to be, an answer to "who owns it".

Why WHOIS No Longer Answers the Ownership Question

The traditional answer to "who owns .com domain X" was a WHOIS lookup: a query against the registrar's or registry's database returning the registrant name, organisation, postal address and registration dates. That answer has largely stopped working.

• Privacy redaction. Following GDPR, registrars and registries redact registrant contact fields for most domains by default. A typical .com WHOIS response today shows the registrar, status codes, name servers and dates — and "REDACTED FOR PRIVACY" in place of identity.
• Privacy and proxy services. Where a record is not redacted, the name is frequently registered through a proxy service, so the visible registrant is the proxy provider.
• Rate limits. WHOIS and RDAP endpoints are built for occasional single lookups. Querying millions of names is neither permitted nor practical.
• Staleness. Registrant records are self-reported and often never updated after the initial registration.

The older alternatives fare no better. Manual lookups do not scale and are rate limited; custom scraping is resource-intensive, fragile and legally ambiguous; and purchased static lists go stale quickly and carry no verifiable provenance.

The honest conclusion: per-domain ownership identification at scale is not something public data supports any more. What remains available, and what is genuinely useful, is infrastructure and technology data.

From "What Exists" to "What It Runs": DNS and Technology Enrichment

If ownership is closed, the observable layer is still open. Every live site answers DNS queries and HTTP requests, and those responses describe the stack:

• NS records identify the DNS operator — often a hosting platform, a CDN or a managed WordPress provider.
• MX records identify the mail platform: Google Workspace, Microsoft 365, a hosting provider's default mail, or none at all. A domain with no MX record is frequently parked or non-operational.
• A/AAAA records resolve to an IP, which maps to an ASN and therefore to a hosting provider, cloud region or CDN edge.
• HTTP responses expose CMS and platform fingerprints — generator meta tags, characteristic paths, cookie names, header patterns.

None of this is personal data. It describes infrastructure rather than people, which is precisely why it can be compiled and distributed in bulk while WHOIS identity cannot.

What WebTrackly Actually Provides

WebTrackly is not a search interface over people. It is a catalog of downloadable datasets built from zone data and infrastructure enrichment.

Coverage and Package Types

The catalog currently contains 1,538 packages:

• 716 TLD zone files — the raw domain lists, one per top-level domain.
• 716 enriched per-zone sets — the same zones with NS, MX, IP and detected CMS attached.
• 79 site lists by CMS or technology — for example all detected WordPress or Joomla installations.
• 27 curated datasets — cross-zone compilations such as the full registered-domain list.

Headline coverage figures:

Data Schema and What the Files Do Not Contain

An enriched zone package is a CSV with, per row:

• domain — the registered name.
• registration_date — where the registry publishes it; empty for registries that do not.
• ns — the delegated name servers.
• mx — mail exchangers, where present.
• ip — resolved address of the apex record.
• cms — detected content management system or platform, where one is identified.

Stated plainly, the files contain no personal contacts: no named individuals, no company contact records, no behavioural or intent signals. There is no per-domain lookup tool and no interactive technology search. What you get is the bulk file, and everything you do with it afterwards happens on your own machine.

Working With the Data: Buy, Download, Process Locally

The flow is deliberately simple and has four steps.

1. Pick a package in the catalog, or go directly to zone files by TLD, domain data or curated datasets.
2. Buy it. One-time purchases start from $3.50. Subscriptions are available: Pro at $29/month includes 50 packages plus 10 datasets and 30,000 API calls; Enterprise at $99/month includes 200 packages plus 50 datasets and 300,000 API calls. See pricing.
3. Download. The export is generated fresh at the moment of purchase and delivered instantly as a CSV inside a ZIP archive.
4. Process it locally. These are large flat files, and standard command-line and analytical tooling handles them well.

A .com-scale file is far too large for a spreadsheet, so start on the command line:

unzip com_zone_enriched.zip
wc -l com_zone_enriched.csv
head -3 com_zone_enriched.csv

# domains delegated to Cloudflare name servers
grep -i 'ns\.cloudflare\.com' com_zone_enriched.csv > cloudflare.csv

# how many use Google Workspace for mail
grep -ic 'aspmx\.l\.google\.com' com_zone_enriched.csv

For anything analytical, load the CSV into DuckDB or ClickHouse rather than a general-purpose transactional database — both read CSV directly and handle hundreds of millions of rows on a single machine:

-- DuckDB
CREATE TABLE com AS SELECT * FROM read_csv_auto('com_zone_enriched.csv');

SELECT cms, count(*) AS sites
FROM com
WHERE cms IS NOT NULL
GROUP BY cms
ORDER BY sites DESC
LIMIT 20;

-- share of the zone that resolves at all
SELECT count(*) FILTER (WHERE ip IS NOT NULL) AS resolving,
       count(*)                                AS total
FROM com;

Because every purchase regenerates the export, comparing an older download against a newer one gives you a straightforward diff of appearing and disappearing names, or of platform migrations inside a zone.

The API: A Catalog of Packages

The API exposes the catalog — which packages exist, what they cover and how to retrieve them. It is not a domain search endpoint, because there is no per-domain lookup product behind it. All requests are authenticated with a bearer token.

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

curl -X GET "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress" \
  -H "Authorization: Bearer YOUR_API_KEY"

curl -X GET "https://webtrackly.com/api/v1/packages/{slug}/" \
  -H "Authorization: Bearer YOUR_API_KEY"

The same in Python — list the technology packages matching a keyword, then inspect one of them before purchase:

import requests

API = "https://webtrackly.com/api/v1"
headers = {"Authorization": "Bearer YOUR_API_KEY"}

# 1. find technology packages matching a keyword
resp = requests.get(f"{API}/packages/",
                    params={"type": "technology", "q": "wordpress"},
                    headers=headers)
packages = resp.json()

for pkg in packages["results"]:
    print(pkg["slug"], pkg["name"])

# 2. inspect a single package
slug = packages["results"][0]["slug"]
detail = requests.get(f"{API}/packages/{slug}/", headers=headers).json()
print(detail["slug"], detail.get("rows"), detail.get("price"))

Endpoint documentation lives at /api/. Call allowances follow the plan: 30,000 per month on Pro, 300,000 on Enterprise.

Common Mistakes When Working With Domain Data

1. Mistake: Expecting WHOIS to identify the owner

   • What goes wrong: A workflow is designed around pulling registrant names for a list of domains. It works on a handful of legacy records and then collapses.
   • Why it fails: Most .com registrant fields are redacted, many names are proxied, and bulk querying is rate limited.
   • The fix: Build on infrastructure signals instead — name servers, mail platform, hosting IP and detected CMS. They are observable, consistent and available in bulk.

2. Mistake: Treating a zone file as a list of live websites

   • What goes wrong: A count of delegated names is reported as a count of active sites.
   • Why it fails: A large share of delegated domains are parked, redirected, or registered defensively with no content at all.
   • The fix: Filter on the enrichment columns. Requiring a resolving IP, an MX record or a detected CMS narrows a zone to something much closer to operating sites.

3. Mistake: Assuming a snapshot stays accurate

   • What goes wrong: A file downloaded months ago is treated as current.
   • Why it fails: Domains are registered and dropped continuously, and platform or hosting migrations happen constantly.
   • The fix: Re-download when currency matters. Exports are generated at the moment of purchase, so a fresh download is a fresh snapshot — and two snapshots give you a diff.

4. Mistake: Loading hundreds of millions of rows into the wrong tool

   • What goes wrong: The CSV is opened in a spreadsheet, or imported row by row into a transactional database.
   • Why it fails: Spreadsheets cap out long before .com scale, and row-wise inserts take hours for aggregations that a columnar engine answers in seconds.
   • The fix: Use stream processing on the command line for filtering, and DuckDB or ClickHouse for aggregation. Both read CSV natively.

5. Mistake: Reading CMS detection as certainty

   • What goes wrong: A detected platform is treated as a verified fact about a business.
   • Why it fails: Detection is fingerprint-based. Headless setups, aggressive caching, CDNs and custom builds can hide or imitate a platform.
   • The fix: Treat the CMS column as a strong signal for segmentation and market sizing, and verify individually before acting on a single record.

6. Mistake: Overlooking Legal and Ethical Considerations

   • What Goes Wrong: Acquiring and using data without understanding privacy regulations (GDPR, CCPA) or acceptable use policies. This can lead to legal issues, reputational damage, and account suspensions.
   • Why It Fails: Ignorance is not a defense. Data privacy is a serious concern globally, and businesses are held accountable for how they collect and use personal data.
   • The Fix: Always adhere to legal guidelines. The datasets described here contain publicly observable infrastructure data and no personal contacts, which keeps the data itself outside the scope of most personal-data rules — but whatever you combine it with, and however you act on it, remains your responsibility.

Frequently Asked Questions (FAQ)

Q: Can I find out who owns a specific .com domain with this data?
A: No. Registrant identity for .com is redacted in WHOIS for the large majority of domains, and it is not part of zone or enrichment data. What the data tells you is that a domain exists, where it is delegated, where it resolves, what mail platform it uses and what CMS it appears to run.

Q: What exactly do I receive when I buy a package?
A: A CSV file inside a ZIP archive, available for immediate download. The export is generated at the moment of purchase, so it reflects the current state of the dataset rather than a pre-built file of unknown age.

Q: Do the files contain personal contact details?
A: No. There are no personal contacts of any kind in the data. The columns are domain, registration date where the registry publishes it, name servers, MX records, IP and detected CMS.

Q: How much of the .com namespace is covered?
A: The .com zone package covers 163,422,083 domains. Across all 716 zones the total is 279,944,703 domains, and the curated all-registered-domains dataset contains 272,614,863 rows.

Q: Is there an interface where I can filter domains by technology?
A: There is no interactive filtering UI. The catalog is organised into ready-made packages — per-zone files, enriched per-zone sets, technology site lists and curated datasets — and filtering happens on your side once the CSV is downloaded.

Q: What does the API do?
A: It serves the catalog: listing packages by type, searching them by keyword and returning the details of an individual package. The endpoints are GET /api/v1/packages/?type=zone, GET /api/v1/packages/?type=technology&q=wordpress and GET /api/v1/packages/{slug}/, authenticated with an Authorization: Bearer header.

Q: What do the plans cost?
A: Individual packages can be bought one-off from $3.50. Pro is $29/month and includes 50 packages, 10 datasets and 30,000 API calls. Enterprise is $99/month and includes 200 packages, 50 datasets and 300,000 API calls. Details are on the pricing page.

Q: Why do some rows have no registration date?
A: Because not every registry publishes registration dates in a form that can be compiled in bulk. Where the registry publishes it the field is filled; where it does not, the field is left empty rather than estimated.

Conclusion

The question "who owns .com" has a clean institutional answer — Verisign operates the registry, accredited registrars sell the names, registrants hold time-limited rights — and a largely closed individual answer, because registrant identity is redacted by default. Working with .com data productively means accepting that and moving the question one step sideways: not who is behind a domain, but what exists and what it runs.

That is what zone files and infrastructure enrichment provide, and it is what WebTrackly packages: 1,538 datasets, 279,944,703 domains, delivered as CSV inside a ZIP and processed on your own machine. Start with the package catalog or the zone file listing.

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