.in-Registry-WHOIS-Daten und Indien-Domainlisten richtig nutzen

Indien betreibt einen der größten nationalen Domain-Räume der Welt, und die dahinterstehende Registry stellt einen WHOIS-Dienst bereit, den jeder abfragen kann. Was dieser Dienst preisgibt und was nicht, hat sich in den vergangenen Jahren erheblich verändert – die meisten Anleitungen beschreiben ihn allerdings noch so, wie er vor einem Jahrzehnt funktionierte. Dieser Artikel erklärt, wie .in-Registry-WHOIS heute tatsächlich arbeitet, welche Felder die Schwärzung überstehen, warum eine Massenerhebung über WHOIS nicht praktikabel ist und wie Sie stattdessen aus Zonendateien einen belastbaren Datensatz indischer Domains aufbauen.

TL;DR / DIE WICHTIGSTEN PUNKTE

• NIXI betreibt den .in-Namensraum: Der National Internet Exchange of India verantwortet .in und dessen Second-Level-Bereiche – .co.in, .net.in, .org.in, .firm.in, .gen.in, .ind.in – sowie eine Reihe internationalisierter TLDs für indische Schriftsysteme.
• WHOIS ist ein Protokoll für Einzelabfragen: Eine Abfrage liefert einen Eintrag. Sie ist ratenbegrenzt, teils durch CAPTCHA geschützt und gibt Freitext zurück, dessen Format je nach Registrar variiert.
• Registrant-Felder sind weitgehend geschwärzt: Name, E-Mail, Telefonnummer und Postanschrift werden für die meisten Domains zurückgehalten. Indiens Digital Personal Data Protection Act, 2023 verstärkt diesen Kurs, statt ihn umzukehren.
• Was zuverlässig zurückkommt: Erstellungs-, Aktualisierungs- und Ablaufdatum, Registrar, Domain-Statuscodes und Nameserver.
• Zonendateien beantworten, was WHOIS nicht kann: welche Domains existieren, welche Name- und Mailserver sie nutzen, wohin sie auflösen und welches CMS erkennbar ist.
• WebTrackly liefert genau diese Dateien: 1.538 Pakete – 716 TLD-Zonendateien, 716 angereicherte Zonenpakete (NS, MX, IP, CMS), 79 Technologie-Sitelisten, 27 kuratierte Datensätze – mit insgesamt 285.582.781 Domains.
• Keine Kontaktdaten: Die Pakete enthalten ausschließlich Domain- und Infrastrukturmerkmale. Keine E-Mail-Adressen, keine Telefonnummern, keine Registrant-Identitäten.

INHALTSVERZEICHNIS

• Wie .in-Registry-WHOIS funktioniert und was es heute zurückgibt
• Fünf Fragestellungen, die .in-Domaindaten beantworten
• Was in einer Zonendatei steckt
• Bulk-Dateien vs. WHOIS-Abfragen
• .in-Domaindaten in der Praxis auswerten
• Typische Fehler im Umgang mit .in-WHOIS-Daten
• FAQ: .in-Registry-WHOIS
• Fazit
• Weiterführende Ressourcen

Wie .in-Registry-WHOIS funktioniert und was es heute zurückgibt

Der .in-Namensraum wird vom National Internet Exchange of India (NIXI) über dessen Registry-Betrieb verwaltet. Er umfasst das offene Second Level (example.in) sowie eine Reihe strukturierter Second-Level-Bereiche mit definiertem Verwendungszweck: .co.in für kommerzielle Anbieter, .net.in für Netzbetreiber, .org.in für Organisationen sowie .firm.in, .gen.in und .ind.in für engere Kategorien. NIXI verwaltet außerdem internationalisierte ccTLDs für indische Schriftsysteme – ein vollständiges Bild des indischen Domain-Raums beschränkt sich also nicht auf die ASCII-Zeichenfolge „.in“.

Die Registry betreibt einen WHOIS-Dienst nach dem bei ccTLDs üblichen Thin-/Thick-Muster: Der Registry-Eintrag führt die maßgeblichen technischen Fakten, während der Registrar die erhobenen Kontaktdaten hält. Bei einer Abfrage können Sie sich darauf verlassen, dass ein kleiner Satz von Feldern vorhanden und korrekt ist: Erstellungsdatum, letztes Änderungsdatum, Ablaufdatum, zuständiger Registrar, Domain-Statuscodes (clientTransferProhibited, pendingDelete und so weiter) sowie die delegierten Nameserver.

Worauf Sie sich nicht mehr verlassen können, ist der Kontaktblock. Seit die DSGVO die Offenlegungspraxis der Registries weltweit verändert hat, werden Name, Organisation, E-Mail, Telefonnummer und Postanschrift des Registranten bei der großen Mehrheit der Domains aus öffentlichen Antworten geschwärzt und durch einen Platzhalter oder eine vom Registrar betriebene Relay-Adresse ersetzt. Indiens eigener Digital Personal Data Protection Act, 2023 weist in dieselbe Richtung: Personenbezogene Daten eines Registranten bleiben personenbezogene Daten, auch wenn sie in einem Domain-Eintrag stehen. Jeder Prozess, der davon ausgeht, dass öffentliches WHOIS eine kontaktierbare Person liefert, beruht auf einer Annahme, die nicht mehr trägt.

Die zweite Einschränkung ist technischer Natur. WHOIS beantwortet eine Domain pro Abfrage. Um 10.000 Domains zu erfassen, stellen Sie 10.000 Abfragen – und genau dieses Verhalten drosseln die Registries: Der Zugriff über Port 43 ist pro IP ratenbegrenzt, die Weboberfläche schaltet zusätzlich ein CAPTCHA vor. Die Formatierung der Antworten unterscheidet sich je nach Registrar, sodass ein Parser, der bei einem Eintrag funktioniert, beim nächsten scheitert. Nichts an diesem Protokoll war für Erhebungen auf Populationsebene gedacht, und daran ändert auch der beste Workaround nichts.

Daraus ergibt sich eine klare Arbeitsteilung. Nutzen Sie WHOIS, wenn Sie eine konkrete Domain haben und deren verbindlichen Registrierungsstatus brauchen – dafür ist es gemacht. Geht es dagegen um die Gesamtheit – wie viele Domains existieren, was sie betreiben, wohin sie auflösen, wie sich das im Zeitverlauf ändert –, liefern Zonendateien die Antwort: als Datei zum Download statt als Einzelabfrage.

Sie brauchen die Domainliste, nicht eine Einzelabfrage?
Werfen Sie einen Blick in den Zonendatei-Katalog – 716 TLDs mit Zeilenzahlen, die schon vor dem Kauf ausgewiesen sind.
Zonen ansehen → | Preise ansehen →

Fünf Fragestellungen, die .in-Domaindaten beantworten

Zonendaten sind Populationsdaten. Sie eignen sich zum Zählen, Gruppieren und Vergleichen über die Zeit. Sie identifizieren keine Personen, und keiner der folgenden Anwendungsfälle setzt das voraus.

1. CMS- und Plattformverbreitung in einem nationalen Namensraum messen

Veröffentlichte Zahlen dazu, welche Plattformen ein Land dominieren, sind meist aus einer Top-N-Stichprobe populärer Websites hochgerechnet – und damit stark zugunsten großer Organisationen verzerrt. Eine Zonendatei mit einer Spalte zur CMS-Erkennung erlaubt es stattdessen, direkt gegen eine bekannte Grundgesamtheit zu zählen. Über den gesamten WebTrackly-Katalog hinweg wird WordPress auf 21.639.326 Domains erkannt, Joomla auf 567.680; dieselbe Berechnung auf eine einzelne Zone eingegrenzt ergibt deren Verteilung.

Weisen Sie jedes Mal Grundgesamtheit und Erkennungsrate aus. „X von Y erfassten Domains, davon Z % der Zeilen mit CMS-Wert“ ist eine Aussage, die einer Prüfung standhält. Eine nackte Prozentzahl nicht.

2. DNS- und Hosting-Anbieter kartieren

Nameserver-Einträge sind das verlässlichste Anbietersignal im Datensatz. Gruppiert man die NS-Spalte nach Suffix, zeigt sich, welche DNS-Betreiber – globale Plattformen, regionale Hoster, einzelne Registrare – die Zone tragen; die Verteilung ist dabei meist deutlich konzentrierter als erwartet. Aufgelöste IPs liefern eine zweite Perspektive, die allerdings vorsichtig zu interpretieren ist: Eine Website hinter einem CDN veröffentlicht die Adresse des CDN, IP-basierte Anteile messen also die Edge, nicht den Origin.

3. Mail-Infrastruktur analysieren

Die MX-Records in den angereicherten Paketen zeigen, wohin eine Domain ihre Mail routet. Klassifizieren Sie MX-Hostnamen nach Anbietermustern, und Sie erhalten für die gesamte Zone die Aufteilung zwischen gehosteten Mail-Plattformen, regionalen Anbietern und selbst verwalteten Servern. Vergleicht man zwei Momentaufnahmen im Abstand mehrerer Monate, wird die Migration zwischen ihnen sichtbar – und das ist die eigentliche Frage hinter den meisten Debatten darüber, wer im E-Mail-Markt vorn liegt. Ein MX-Record ist ein Routing-Ziel, kein Postfach – Adressen enthalten diese Dateien nicht.

4. Wachstum und Abwanderung verfolgen

Das Registrierungsvolumen gilt weithin als Näherungswert für digitale Aktivität, und es gehört zu den wenigen Kennzahlen, die Sie selbst messen können, statt sie einer Pressemitteilung zu entnehmen. Kaufen Sie dasselbe Zonenpaket zu zwei Zeitpunkten, bilden Sie die Differenz der Domain-Spalten, und Sie haben Neuregistrierungen und Abgänge für den Zeitraum – ohne von den Angaben Dritter abhängig zu sein. Bewahren Sie jede heruntergeladene Datei mit Datum auf; eine verworfene Momentaufnahme ist ein Vergleich, den Sie nie wieder anstellen können.

5. Security- und Angriffsflächen-Recherche

Aufklärung, die bei WHOIS-Abfragen beginnt, endet fast sofort an den Ratenlimits. Der Start bei einer Zonendatei hebt diese Grenze auf: Filtern Sie lokal auf die relevante Teilmenge – ein CMS, ein Nameserver, ein IP-Bereich – und geben Sie diese Liste an Ihr eigenes Prüf-Tooling weiter. Die Datei liefert die Grundgesamtheit; die Analyse bleibt Ihre Aufgabe. Aktive Tests müssen sich auf den Bereich beschränken, für den Sie autorisiert sind – eine herunterladbare Domainliste ist keine Autorisierung.

Was in einer Zonendatei steckt

Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Zonendatei-Pakete enthalten die Domainliste. Angereicherte Zonenpakete ergänzen Nameserver, MX-Records, aufgelöste IPs und erkanntes CMS – befüllt, wo sie ermittelt werden konnten, andernfalls leer.

Das ist das gesamte Schema. Es gibt keine Spalte für Registranten, keine für Organisationen und keine für Kontaktdaten, weil diese Angaben bereits bei der Registry geschwärzt werden und hier nicht rekonstruiert werden. Registrierungsdaten erscheinen nur dort, wo die Quellzone sie veröffentlicht; bei vielen ccTLDs ist das nicht der Fall – dann fehlt die Spalte, statt geschätzt zu werden.

Bulk-Dateien vs. WHOIS-Abfragen

Beide ergänzen einander. WHOIS bleibt die maßgebliche Quelle für den Status einer Domain, die Sie bereits identifiziert haben. Bulk-Dateien sind der Weg, diese Grundgesamtheit überhaupt erst zu bestimmen.

.in-Domaindaten in der Praxis auswerten

Es gibt keine Suchoberfläche und keine serverseitige Filterung. Sie wählen ein Paket, kaufen es, laden das ZIP-Archiv herunter und führen die Analyse auf Ihrem eigenen Rechner durch.

Schritt 1 – Das passende Paket finden. Unter /zones/ stehen die 716 TLD-Zonendateien und ihre angereicherten Gegenstücke, jeweils mit der Zeilenzahl vor dem Kauf, sodass Sie den Umfang kennen. /datasets/ enthält die 27 kuratierten zonenübergreifenden Sammlungen – die größte umfasst alle registrierten Domains mit 272.614.863 Zeilen. /packages/ ist der vollständige Katalog inklusive der 79 Technologie-Sitelisten.

Schritt 2 – Kaufen und herunterladen. Pakete beginnen bei $3.50 und stehen sofort zum Download bereit; die Datei wird beim Kauf frisch exportiert und nicht aus einem alten Build ausgeliefert. Für den laufenden Einsatz kostet Pro $29/Monat (50 Pakete, 10 Datensätze, 30.000 API-Aufrufe) und Enterprise $99/Monat (200 Pakete, 50 Datensätze, 300.000 API-Aufrufe). Siehe /pricing/.

Schritt 3 – Entpacken und prüfen.

unzip in-enriched.zip
head -3 in-enriched.csv
wc -l in-enriched.csv

Schritt 4 – Schnelle Auswertungen mit Kommandozeilen-Tools.

# second-level space breakdown
grep -oE '\.(co|net|org|firm|gen|ind)\.in$' in-enriched.csv | sort | uniq -c | sort -rn

# rows where the detected CMS is WordPress
awk -F',' '$5 == "WordPress"' in-enriched.csv > in-wordpress.csv

# top name servers
cut -d',' -f2 in-enriched.csv | sort | uniq -c | sort -rn | head -20

Schritt 5 – Analysen in einer spaltenorientierten Engine. DuckDB liest die CSV-Datei direkt, ganz ohne Importschritt:

-- mail provider distribution
SELECT
  CASE
    WHEN mx ILIKE '%google%'    THEN 'Google'
    WHEN mx ILIKE '%outlook%'   THEN 'Microsoft'
    WHEN mx ILIKE '%zoho%'      THEN 'Zoho'
    WHEN mx IS NULL OR mx = ''  THEN 'none'
    ELSE 'other'
  END AS provider,
  count(*) AS domains
FROM read_csv_auto('in-enriched.csv')
GROUP BY provider ORDER BY domains DESC;

-- new domains between two snapshots
SELECT n.domain
FROM read_csv_auto('in-2026-07.csv') n
LEFT JOIN read_csv_auto('in-2026-04.csv') o USING (domain)
WHERE o.domain IS NULL;

Schritt 6 – Katalogzugriff per API skripten. Die API stellt den Paketkatalog bereit, keine Domain-Abfrage. Die Authentifizierung erfolgt per Bearer-Token.

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

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

# details for a single package
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/in-zone/"

Die Endpunkt-Referenz finden Sie unter /api/. Eine typische Automatisierung listet die von Ihnen beobachteten Pakete auf, prüft auf einen neueren Build, lädt ihn herunter und stellt ihn im Data Warehouse neben die vorherige Momentaufnahme.

Typische Fehler im Umgang mit .in-WHOIS-Daten

1. WHOIS als Massenquelle behandeln.

   • Was schiefgeht: Ratenlimits und CAPTCHAs stoppen den Job nach ein paar tausend Abfragen, und übrig bleibt eine lückenhafte Abdeckung, die keine Prozentaussage trägt.
   • Die Lösung: Nehmen Sie die Grundgesamtheit aus einer Zonendatei und heben Sie sich Abfragen für die kleine Teilmenge auf, bei der ein verbindlicher Status je Domain wirklich zählt.

2. Kontaktdaten des Registranten erwarten.

   • Was schiefgeht: Eine Pipeline wird um eine Kontaktspalte herum gebaut, die schon an der Quelle geschwärzt wird und nie ankommt.
   • Die Lösung: Planen Sie mit dem, was der Eintrag tatsächlich enthält – Daten, Registrar, Status, Nameserver – und behandeln Sie die Beschaffung von Kontaktdaten als eigenes Problem mit eigener Rechtsgrundlage nach DPDP Act und DSGVO.

3. Die Second-Level-Struktur von .in ignorieren.

   • Was schiefgeht: Wer nur *.in zählt und .co.in, .net.in, .org.in und die übrigen auslässt, unterschätzt den Namensraum – zum Teil erheblich.
   • Die Lösung: Führen Sie die Second-Level-Bereiche explizit auf und weisen Sie sie getrennt aus; sie ziehen unterschiedliche Registrantentypen an und entwickeln sich unterschiedlich.

4. Die internationalisierten TLDs vergessen.

   • Was schiefgeht: Eine Analyse, die den „indischen Domain-Raum“ abzudecken beansprucht, lässt die von NIXI verwalteten schriftbasierten ccTLDs stillschweigend außen vor.
   • Die Lösung: Benennen Sie Ihren Betrachtungsbereich präzise. Wenn Sie nur den ASCII-.in-Baum gemessen haben, schreiben Sie das – statt auf das ganze Land zu verallgemeinern.

5. Ein Erstellungsdatum als Gründungsdatum eines Unternehmens lesen.

   • Was schiefgeht: Eine 2019 registrierte Domain wird als 2019 gegründetes Unternehmen dargestellt, obwohl es sich um ein Rebranding, eine defensive Registrierung oder einen Transfer handeln kann, bei dem das Datum zurückgesetzt wurde.
   • Die Lösung: Behandeln Sie das Erstellungsdatum als Alter des Registrierungseintrags und verifizieren Sie es, bevor Sie Aussagen über die Organisation treffen.

6. Mit nur einer Momentaufnahme arbeiten.

   • Was schiefgeht: Sie können den aktuellen Zustand beschreiben, aber nicht den Trend – und danach wird in der Regel gefragt.
   • Die Lösung: Archivieren und datieren Sie jeden Download. Wachstum, Abwanderung und Anbieterwechsel erfordern allesamt zwei Messpunkte.

7. Die CMS-Erkennung überstrapazieren.

   • Was schiefgeht: Eine präzise klingende Marktanteilszahl bricht in sich zusammen, sobald jemand mit einer anderen Erkennungsmethode widerspricht.
   • Die Lösung: Ein leeres CMS-Feld bedeutet „nicht erkannt“, nicht „kein CMS“. Weisen Sie zu jedem Anteil die Erkennungsrate aus und sprechen Sie von erkannten Installationen.

FAQ: .in-Registry-WHOIS

F: Was ist .in-Registry-WHOIS?
A: Die öffentliche Registrierungsdatenbank für den .in-Namensraum, betrieben von NIXI. Eine Abfrage liefert den Eintrag zu einer einzelnen Domain: Erstellungs-, Aktualisierungs- und Ablaufdatum, den zuständigen Registrar, Domain-Statuscodes und die delegierten Nameserver. Die Kontaktfelder sind bei den meisten Domains geschwärzt.

F: Warum sind die Registranten-Informationen verborgen?
A: Die Offenlegungspraxis der Registries hat sich nach der DSGVO weltweit geändert; personenbezogene Daten in Registrierungseinträgen werden heute standardmäßig aus öffentlichen Antworten zurückgehalten. Indiens Digital Personal Data Protection Act, 2023 weist in dieselbe Richtung. Eine Offenlegung setzt in der Regel eine dokumentierte Rechtsgrundlage voraus, die beim Registrar eingereicht wird.

F: Kann ich .in-WHOIS in großem Umfang abfragen?
A: Praktisch nicht. Der Zugriff über Port 43 ist pro IP ratenbegrenzt, die Weboberfläche ist durch CAPTCHA geschützt. Das Protokoll ist für gelegentliche Einzelabfragen gebaut.

F: Führt WebTrackly WHOIS-Abfragen für mich durch?
A: Nein. WebTrackly liefert vorbereitete Bulk-Dateien. Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Es gibt keinen Abfragedienst und keinen Endpunkt für Einzelabfragen.

F: Was steckt in einem Paket?
A: Zonendatei-Pakete enthalten die Domainliste einer TLD. Angereicherte Zonenpakete ergänzen Nameserver, MX-Records, aufgelöste IPs und erkanntes CMS, soweit ermittelbar. Technologie-Pakete listen Websites, auf denen ein bestimmtes CMS oder eine bestimmte Technologie erkannt wurde. Kuratierte Datensätze sind zonenübergreifende Zusammenstellungen.

F: Sind E-Mail-Adressen oder Telefonnummern enthalten?
A: Nein. Die Dateien enthalten ausschließlich Domain- und Infrastrukturmerkmale, keine persönlichen oder betrieblichen Kontaktdaten.

F: Wie groß ist der Katalog?
A: 1.538 Pakete: 716 Zonendateien, 716 angereicherte Zonenpakete, 79 Technologie-Sitelisten und 27 kuratierte Datensätze, die über die Zonenpakete hinweg 285.582.781 Domains abdecken. Der Datensatz aller registrierten Domains umfasst 272.614.863 Zeilen.

F: Wie aktuell sind die Daten?
A: Jedes Paket wird im Moment des Kaufs exportiert, Sie erhalten also den aktuellen Build. Um Veränderungen zu verfolgen, kaufen Sie dasselbe Paket später erneut und bilden die Differenz beider Dateien.

F: Was leistet die API?
A: Sie stellt den Katalog bereit. GET /api/v1/packages/?type=zone listet Zonenpakete, ?type=technology&q=wordpress filtert Technologie-Pakete, und /api/v1/packages/{slug}/ liefert Details zu einem Paket. Authentifizierung per Bearer-Token. Sie nimmt keinen Domainnamen entgegen und gibt keine Fakten dazu zurück.

F: Was kostet das?
A: Einzelne Pakete ab $3.50 als Einmalkauf. Pro kostet $29/Monat (50 Pakete, 10 Datensätze, 30.000 API-Aufrufe), Enterprise $99/Monat (200 Pakete, 50 Datensätze, 300.000 API-Aufrufe). Siehe /pricing/.

Fazit

.in-Registry-WHOIS ist eine verlässliche Quelle für die Registrierungsfakten einer Domain, die Sie bereits kennen: wann sie angelegt wurde, wer sie betreut, welchen Status sie trägt, wohin sie DNS delegiert. Es ist kein Werkzeug zur Entdeckung neuer Domains und keine Kontaktdatenbank – und kein noch so ausgefeiltes Skript macht es dazu.

Fragen auf Populationsebene zum indischen Domain-Raum – wie viele Domains, auf welchen Plattformen, hinter welchen DNS- und Mail-Anbietern, wachsend oder schrumpfend – beantworten Sie mit Zonendateien, die Sie herunterladen und lokal auswerten. Das Schema ist bewusst schmal gehalten: Domain, Nameserver, MX, aufgelöste IP, erkanntes CMS – und Registrierungsdaten nur dort, wo die Quelle sie veröffentlicht. Diese Grenze vorab zu kennen, bewahrt ein Projekt davor, im letzten Schritt zu scheitern.

Zum Zonendatei-Katalog →

Weiterführende Ressourcen

• Paketkatalog – 1.538 herunterladbare Domain-Datenbanken
• Zonendateien nach TLD – .com, .net, .de und über 700 weitere
• Kuratierte Datensätze – alle registrierten Domains, MX-Server, E-Commerce
• API-Dokumentation – Katalogzugriff per Bearer-Token
• Preise – Einmalkäufe ab $3.50