Wem gehören .com-Domains? Registrierungsdaten verstehen

"Wem gehört .com" ist eine Frage mit zwei völlig unterschiedlichen Antworten. Auf Registry-Ebene ist die Antwort präzise und öffentlich: .com wird von Verisign im Auftrag der ICANN betrieben, und die Registry veröffentlicht eine Zonendatei mit allen existierenden Domains. Auf Ebene des einzelnen Registranten ist die Antwort dagegen meist nicht verfügbar: Seit der DSGVO sind die meisten WHOIS-Einträge für .com geschwärzt. Dieser Artikel erklärt, was .com-Registrierungsdaten tatsächlich enthalten, was sich daraus ableiten lässt und was nicht — und was WebTrackly liefert: herunterladbare Zonen- und Anreicherungsdatensätze, darunter 163,422,083 .com-Domains.

TL;DR / Die wichtigsten Punkte

• Registry vs. Registrar: Verisign betreibt die .com-Registry; Registrare wie GoDaddy oder Namecheap verkaufen und verwalten die Registrierungen. Die Registrantendaten liegen beim Registrar, nicht in der Zonendatei.
• Die Zonendatei beantwortet "was existiert": Sie listet delegierte Domains und deren Nameserver — keine Namen, keine Adressen, keine Kontaktdaten.
• WHOIS beantwortet das "wer" nicht mehr: Registrantendaten für .com sind aus Datenschutzgründen standardmäßig geschwärzt, eine Eigentümer-Abfrage pro Domain im großen Maßstab ist damit unrealistisch.
• Die Anreicherung beantwortet "was läuft darauf und wo wird es gehostet": NS, MX, IP und erkanntes CMS stammen aus DNS- und HTTP-Antworten und sind der praktische Ersatz für Eigentümerdaten.
• Was WebTrackly liefert: Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Allein die .com-Zone umfasst 163,422,083 Domains.
• Was nicht enthalten ist: keine persönlichen Kontaktdaten, keine Intent-Daten, keine Einzelabfrage pro Domain, keine interaktive Technologiesuche.

Inhaltsverzeichnis

• Wem .com wirklich gehört: Registry, Registrar, Registrant
• Was die .com-Zonendatei veröffentlicht — und was nicht
• Warum WHOIS die Eigentümerfrage nicht mehr beantwortet
• Von "was existiert" zu "was läuft darauf": DNS- und Technologieanreicherung
• Was WebTrackly tatsächlich bietet
  • Abdeckung und Pakettypen
  • Datenschema — und was die Dateien nicht enthalten
• Arbeiten mit den Daten: kaufen, herunterladen, lokal verarbeiten
• Die API: ein Katalog der Pakete
• Typische Fehler im Umgang mit Domaindaten
• Häufig gestellte Fragen (FAQ)
• Fazit
• Weiterführende Ressourcen

Wem .com wirklich gehört: Registry, Registrar, Registrant

An jeder .com-Domain sind drei verschiedene Parteien beteiligt — und sie zu verwechseln ist die Ursache der meisten Fehlannahmen über Domaindaten.

• Die Registry betreibt die TLD selbst. Bei .com ist das Verisign, auf Basis eines Registry-Vertrags mit der ICANN. Die Registry führt die maßgebliche Datenbank darüber, welche .com-Namen delegiert sind und auf welche Nameserver sie verweisen, und betreibt die autoritative DNS-Infrastruktur der Zone.
• Der Registrar ist das akkreditierte Unternehmen, das eine Registrierung an den Endkunden verkauft — GoDaddy, Namecheap, Tucows, Cloudflare und Hunderte weitere. Beim Registrar liegen die Kundenbeziehung, die Zahlungsdaten und der Kontakteintrag des Registranten.
• Der Registrant ist die Person oder Organisation, die das Nutzungsrecht an dem Namen für die Registrierungsperiode hält. Niemand "besitzt" eine Domain im eigentlichen Sinne; eine Registrierung ist ein verlängerbares Recht, kein Eigentum.

Diese Aufteilung hat praktische Folgen. Die Registry kann lückenlos sagen, welche Namen existieren. Sie kann nicht sagen, wer dahintersteht, weil sie diese Information nie in einer veröffentlichten Form vorhält. Der Registrar kennt die Identität des Registranten, gibt sie aber nur über WHOIS/RDAP heraus — und dort greift die Datenschutzschwärzung.

Was die .com-Zonendatei veröffentlicht — und was nicht

Eine Zonendatei ist die DNS-Delegationsliste einer Top-Level-Domain. Für .com führt sie jeden Second-Level-Namen auf, für den aktive Nameserver hinterlegt sind, zusammen mit den NS-Einträgen, die ihn delegieren, und den Glue-A/AAAA-Einträgen dort, wo diese Nameserver innerhalb der Zone selbst liegen. Der Zugang zu Registry-Zonendateien für gTLDs läuft über den Centralized Zone Data Service der ICANN und steht nur freigegebenen Parteien offen.

Was eine Zonendatei liefert:

• Die vollständige Menge der delegierten Namen unter der TLD — das, was einer Volkszählung des Webs auf Namensebene am nächsten kommt.
• Die Nameserver, an die jede Domain delegiert ist — ein starkes Signal für den DNS-Anbieter und häufig auch für die dahinterliegende Hosting-Plattform.
• Eine verlässliche Grundlage für Vergleiche: Namen, die zwischen zwei Snapshots hinzukommen oder verschwinden.

Was eine Zonendatei nicht liefert:

• Namen von Registranten, Organisationen, Postanschriften oder sonstige Kontaktdaten.
• Registrierungs- oder Ablaufdaten — diese stammen aus dem WHOIS/RDAP-Dienst der Registry, und nur ein Teil der Registries veröffentlicht sie in Massen.
• Registrierte Namen ohne konfigurierte Nameserver. Eine Domain kann registriert, aber nicht delegiert sein; dann fehlt sie schlicht in der Zone.
• Alles zu Inhalt, Geschäftsmodell oder Größe der jeweiligen Website.

Mit anderen Worten: Die Zonendatei ist eine Antwort auf "was existiert", und zwar eine ungewöhnlich vollständige. Sie ist keine Antwort auf "wem gehört es" — und war auch nie dafür gedacht.

Warum WHOIS die Eigentümerfrage nicht mehr beantwortet

Die klassische Antwort auf "wem gehört die .com-Domain X" war eine WHOIS-Abfrage: eine Anfrage an die Datenbank des Registrars oder der Registry, die Registrantenname, Organisation, Postanschrift und Registrierungsdaten zurückgab. Diese Antwort funktioniert weitgehend nicht mehr.

• Datenschutzschwärzung. Seit der DSGVO schwärzen Registrare und Registries die Kontaktfelder des Registranten bei den meisten Domains standardmäßig. Eine typische .com-WHOIS-Antwort zeigt heute Registrar, Statuscodes, Nameserver und Datumsangaben — und "REDACTED FOR PRIVACY" anstelle der Identität.
• Privacy- und Proxy-Dienste. Wo ein Eintrag nicht geschwärzt ist, wurde der Name häufig über einen Proxy-Dienst registriert, sodass als sichtbarer Registrant der Proxy-Anbieter erscheint.
• Rate Limits. WHOIS- und RDAP-Endpunkte sind für gelegentliche Einzelabfragen gebaut. Millionen Namen abzufragen ist weder erlaubt noch praktikabel.
• Veraltete Daten. Registrantendaten sind Selbstauskünfte und werden nach der Erstregistrierung oft nie wieder aktualisiert.

Die älteren Alternativen schneiden nicht besser ab. Manuelle Abfragen skalieren nicht und sind ratenbegrenzt; eigenes Scraping ist ressourcenintensiv, fragil und rechtlich unklar; und gekaufte statische Listen veralten schnell und haben keine nachprüfbare Herkunft.

Das ehrliche Fazit: Die Identifikation von Domaininhabern im großen Maßstab wird von öffentlichen Daten nicht mehr getragen. Was verfügbar bleibt — und was echten Nutzen hat — sind Infrastruktur- und Technologiedaten.

Von "was existiert" zu "was läuft darauf": DNS- und Technologieanreicherung

Wenn die Eigentümerebene geschlossen ist, bleibt die beobachtbare Ebene offen. Jede aktive Website beantwortet DNS-Anfragen und HTTP-Requests, und diese Antworten beschreiben den Stack:

• NS-Einträge zeigen den DNS-Betreiber — oft eine Hosting-Plattform, ein CDN oder einen Managed-WordPress-Anbieter.
• MX-Einträge zeigen die Mail-Plattform: Google Workspace, Microsoft 365, den Standard-Mailserver eines Hosters — oder gar keine. Eine Domain ohne MX-Eintrag ist häufig geparkt oder nicht in Betrieb.
• A/AAAA-Einträge lösen zu einer IP auf, die sich einer ASN und damit einem Hosting-Anbieter, einer Cloud-Region oder einem CDN-Edge zuordnen lässt.
• HTTP-Antworten verraten CMS- und Plattform-Fingerabdrücke — Generator-Meta-Tags, charakteristische Pfade, Cookie-Namen, Header-Muster.

Nichts davon sind personenbezogene Daten. Es beschreibt Infrastruktur statt Personen — genau deshalb lässt es sich in Massen zusammenstellen und verbreiten, während das bei WHOIS-Identitäten nicht möglich ist.

Was WebTrackly tatsächlich bietet

WebTrackly ist keine Suchoberfläche für Personen. Es ist ein Katalog herunterladbarer Datensätze, aufgebaut aus Zonendaten und Infrastrukturanreicherung.

Abdeckung und Pakettypen

Der Katalog umfasst derzeit 1,538 Pakete:

• 716 TLD-Zonendateien — die reinen Domainlisten, eine je Top-Level-Domain.
• 716 angereicherte Zonensätze — dieselben Zonen, ergänzt um NS, MX, IP und erkanntes CMS.
• 79 Website-Listen nach CMS oder Technologie — zum Beispiel alle erkannten WordPress- oder Joomla-Installationen.
• 27 kuratierte Datensätze — zonenübergreifende Zusammenstellungen wie die vollständige Liste registrierter Domains.

Die wichtigsten Abdeckungszahlen:

Datenschema — und was die Dateien nicht enthalten

Ein angereichertes Zonenpaket ist eine CSV-Datei mit folgenden Feldern je Zeile:

• domain — der registrierte Name.
• registration_date — sofern die Registry es veröffentlicht; leer bei Registries, die das nicht tun.
• ns — die delegierten Nameserver.
• mx — die Mail Exchanger, sofern vorhanden.
• ip — die aufgelöste Adresse des Apex-Eintrags.
• cms — erkanntes Content-Management-System oder erkannte Plattform, sofern eine identifiziert wurde.

Klar gesagt: Die Dateien enthalten keine persönlichen Kontaktdaten — keine namentlich genannten Personen, keine Firmenkontakte, keine Verhaltens- oder Intent-Signale. Es gibt kein Abfragewerkzeug für einzelne Domains und keine interaktive Technologiesuche. Sie erhalten die Massendatei, und alles Weitere passiert auf Ihrer eigenen Maschine.

Arbeiten mit den Daten: kaufen, herunterladen, lokal verarbeiten

Der Ablauf ist bewusst einfach gehalten und besteht aus vier Schritten.

1. Paket auswählen im Katalog — oder direkt zu den Zonendateien nach TLD, den Domaindaten oder den kuratierten Datensätzen.
2. Kaufen. Einmalkäufe beginnen bei $3.50. Es gibt auch Abonnements: Pro für $29/month enthält 50 Pakete plus 10 Datensätze und 30,000 API-Aufrufe; Enterprise für $99/month enthält 200 Pakete plus 50 Datensätze und 300,000 API-Aufrufe. Siehe Preise.
3. Herunterladen. Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben.
4. Lokal verarbeiten. Es handelt sich um große Flatfiles, mit denen gängige Kommandozeilen- und Analysewerkzeuge gut zurechtkommen.

Eine Datei in .com-Größenordnung ist für eine Tabellenkalkulation viel zu groß — beginnen Sie deshalb auf der Kommandozeile:

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

Für alles Analytische laden Sie die CSV-Datei in DuckDB oder ClickHouse statt in eine allgemeine transaktionale Datenbank — beide lesen CSV direkt und verarbeiten Hunderte Millionen Zeilen auf einer einzigen Maschine:

-- 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;

Da jeder Kauf den Export neu erzeugt, ergibt der Vergleich eines älteren Downloads mit einem neueren unmittelbar ein Diff der hinzugekommenen und verschwundenen Namen — oder der Plattformwechsel innerhalb einer Zone.

Die API: ein Katalog der Pakete

Die API stellt den Katalog bereit — welche Pakete existieren, was sie abdecken und wie man sie bezieht. Sie ist kein Endpunkt für die Domainsuche, denn dahinter steht kein Produkt für Einzelabfragen pro Domain. Alle Requests werden mit einem Bearer-Token authentifiziert.

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"

Dasselbe in Python — die zu einem Stichwort passenden Technologiepakete auflisten und eines davon vor dem Kauf genauer ansehen:

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"))

Die Endpunkt-Dokumentation finden Sie unter /api/. Die Aufrufkontingente richten sich nach dem Tarif: 30,000 pro Monat bei Pro, 300,000 bei Enterprise.

Typische Fehler im Umgang mit Domaindaten

1. Fehler: Von WHOIS die Identifikation des Inhabers erwarten

   • Was schiefgeht: Ein Workflow wird darauf ausgelegt, für eine Domainliste die Registrantennamen abzurufen. Bei einer Handvoll Altdatensätze funktioniert das — danach bricht es zusammen.
   • Warum es scheitert: Die meisten .com-Registrantenfelder sind geschwärzt, viele Namen laufen über Proxys, und Massenabfragen sind ratenbegrenzt.
   • Die Lösung: Bauen Sie stattdessen auf Infrastruktursignale — Nameserver, Mail-Plattform, Hosting-IP und erkanntes CMS. Sie sind beobachtbar, konsistent und in Massen verfügbar.

2. Fehler: Eine Zonendatei als Liste aktiver Websites verstehen

   • Was schiefgeht: Die Zahl der delegierten Namen wird als Zahl aktiver Websites berichtet.
   • Warum es scheitert: Ein großer Teil der delegierten Domains ist geparkt, weitergeleitet oder rein defensiv registriert und hat überhaupt keine Inhalte.
   • Die Lösung: Filtern Sie über die Anreicherungsspalten. Wer eine auflösende IP, einen MX-Eintrag oder ein erkanntes CMS voraussetzt, engt eine Zone auf etwas ein, das den tatsächlich betriebenen Websites deutlich näherkommt.

3. Fehler: Annehmen, ein Snapshot bleibe aktuell

   • Was schiefgeht: Eine vor Monaten heruntergeladene Datei wird als aktuell behandelt.
   • Warum es scheitert: Domains werden laufend registriert und wieder freigegeben, und Plattform- oder Hosting-Wechsel passieren ständig.
   • Die Lösung: Laden Sie neu herunter, wenn Aktualität zählt. Exporte werden im Moment des Kaufs erzeugt, ein frischer Download ist also ein frischer Snapshot — und zwei Snapshots ergeben ein Diff.

4. Fehler: Hunderte Millionen Zeilen ins falsche Werkzeug laden

   • Was schiefgeht: Die CSV-Datei wird in einer Tabellenkalkulation geöffnet oder zeilenweise in eine transaktionale Datenbank importiert.
   • Warum es scheitert: Tabellenkalkulationen stoßen lange vor der .com-Größenordnung an ihre Grenzen, und zeilenweise Inserts brauchen Stunden für Aggregationen, die eine spaltenorientierte Engine in Sekunden liefert.
   • Die Lösung: Filtern Sie per Stream-Verarbeitung auf der Kommandozeile und aggregieren Sie mit DuckDB oder ClickHouse. Beide lesen CSV nativ.

5. Fehler: CMS-Erkennung als Gewissheit lesen

   • Was schiefgeht: Eine erkannte Plattform wird als gesicherte Tatsache über ein Unternehmen behandelt.
   • Warum es scheitert: Die Erkennung beruht auf Fingerabdrücken. Headless-Setups, aggressives Caching, CDNs und Eigenentwicklungen können eine Plattform verbergen oder imitieren.
   • Die Lösung: Behandeln Sie die CMS-Spalte als starkes Signal für Segmentierung und Marktabschätzung — und prüfen Sie den Einzelfall, bevor Sie auf einen einzelnen Eintrag hin handeln.

6. Fehler: Rechtliche und ethische Aspekte übersehen

   • Was schiefgeht: Daten werden beschafft und genutzt, ohne die Datenschutzvorgaben (DSGVO, CCPA) oder die Nutzungsbedingungen zu kennen. Das kann rechtliche Probleme, Reputationsschäden und Kontosperrungen nach sich ziehen.
   • Warum es scheitert: Unwissenheit schützt nicht. Datenschutz ist weltweit ein ernstes Thema, und Unternehmen haften dafür, wie sie personenbezogene Daten erheben und verwenden.
   • Die Lösung: Halten Sie sich stets an die rechtlichen Vorgaben. Die hier beschriebenen Datensätze enthalten öffentlich beobachtbare Infrastrukturdaten und keine persönlichen Kontaktdaten — die Daten selbst fallen damit nicht unter die meisten Regeln für personenbezogene Daten. Womit Sie sie kombinieren und wie Sie darauf hin handeln, bleibt jedoch Ihre Verantwortung.

Häufig gestellte Fragen (FAQ)

F: Kann ich mit diesen Daten herausfinden, wem eine bestimmte .com-Domain gehört?
A: Nein. Die Registrantenidentität für .com ist im WHOIS bei der großen Mehrheit der Domains geschwärzt und ist nicht Teil der Zonen- oder Anreicherungsdaten. Die Daten sagen Ihnen, dass eine Domain existiert, wohin sie delegiert ist, wohin sie auflöst, welche Mail-Plattform sie nutzt und welches CMS sie augenscheinlich einsetzt.

F: Was genau erhalte ich beim Kauf eines Pakets?
A: Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Der Export wird im Moment des Kaufs erzeugt und bildet damit den aktuellen Stand des Datensatzes ab — keine vorgefertigte Datei unbekannten Alters.

F: Enthalten die Dateien persönliche Kontaktdaten?
A: Nein. In den Daten befinden sich keinerlei persönliche Kontaktdaten. Die Spalten sind: Domain, Registrierungsdatum (sofern die Registry es veröffentlicht), Nameserver, MX-Einträge, IP und erkanntes CMS.

F: Wie viel des .com-Namensraums ist abgedeckt?
A: Das .com-Zonenpaket umfasst 163,422,083 Domains. Über alle 716 Zonen hinweg sind es 285,582,781 Domains, und der kuratierte Datensatz aller registrierten Domains enthält 272,614,863 Zeilen.

F: Gibt es eine Oberfläche, in der ich Domains nach Technologie filtern kann?
A: Eine interaktive Filter-UI gibt es nicht. Der Katalog ist in fertige Pakete gegliedert — Zonendateien, angereicherte Zonensätze, Technologie-Website-Listen und kuratierte Datensätze — und gefiltert wird auf Ihrer Seite, sobald die CSV-Datei heruntergeladen ist.

F: Was macht die API?
A: Sie liefert den Katalog: Pakete nach Typ auflisten, per Stichwort durchsuchen und die Details eines einzelnen Pakets zurückgeben. Die Endpunkte sind GET /api/v1/packages/?type=zone, GET /api/v1/packages/?type=technology&q=wordpress und GET /api/v1/packages/{slug}/, authentifiziert über einen Authorization: Bearer-Header.

F: Was kosten die Tarife?
A: Einzelne Pakete lassen sich einmalig ab $3.50 kaufen. Pro kostet $29/month und enthält 50 Pakete, 10 Datensätze und 30,000 API-Aufrufe. Enterprise kostet $99/month und enthält 200 Pakete, 50 Datensätze und 300,000 API-Aufrufe. Details finden Sie auf der Preisseite.

F: Warum haben manche Zeilen kein Registrierungsdatum?
A: Weil nicht jede Registry Registrierungsdaten in einer Form veröffentlicht, die sich in Massen zusammenstellen lässt. Wo die Registry sie veröffentlicht, ist das Feld gefüllt; wo nicht, bleibt es leer statt geschätzt zu werden.

Fazit

Die Frage "wem gehört .com" hat eine klare institutionelle Antwort — Verisign betreibt die Registry, akkreditierte Registrare verkaufen die Namen, Registranten halten zeitlich begrenzte Rechte — und eine weitgehend geschlossene individuelle Antwort, weil die Registrantenidentität standardmäßig geschwärzt ist. Produktiv mit .com-Daten zu arbeiten heißt, das zu akzeptieren und die Frage um einen Schritt zu verschieben: nicht wer hinter einer Domain steht, sondern was existiert und was darauf läuft.

Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Starten Sie mit dem Paketkatalog oder der Zonendatei-Übersicht.

Weiterführende Ressourcen

• Paketkatalog — über 1,500 herunterladbare Domain-Datenbanken
• Zonendateien nach TLD — .com, .net, .de und über 700 weitere
• Kuratierte Datensätze — alle registrierten Domains, MX-Server, E-Commerce
• Preise — Einmalkäufe ab $3.50