DNS-Zonendateien erklärt: Aufbau, Zugang und Praxiseinsatz

Eine DNS-Zonendatei ist das, was einer Volkszählung der Domain-Branche am nächsten kommt: Für eine bestimmte Top-Level-Domain listet sie auf, was registriert ist und wie es delegiert wird. Damit ist sie der natürliche Ausgangspunkt für Domain-Recherche — doch von einer rohen Zonendatei bis zu einer verwertbaren Liste ist es ein weiter Weg. Dieser Artikel zeigt, was die Datei tatsächlich enthält, wie sich der Zugang zwischen gTLDs und ccTLDs unterscheidet und was mit den Daten geschehen muss, bevor sie für SEO, Investment oder Outreach nutzbar sind.

Der Aufbau einer DNS-Zonendatei

Eine DNS-Zonendatei ist eine reine Textdatei, die eine DNS-Zone beschreibt. Sie ordnet Domainnamen IP-Adressen und weiteren Ressourcen zu und legt damit fest, wie der Traffic einer Domain geroutet wird. Auf TLD-Ebene sind diese Dateien groß: Die .com-Zone umfasst 157,775,115 Domains, eine mittelgroße ccTLD kommt vielleicht auf einige Hunderttausend. Jeder Parsing-Ansatz muss auf die Größe der Zielzone ausgelegt sein — was bei einer kleinen ccTLD noch in der Tabellenkalkulation funktioniert, überlebt .com nicht.

SOA-Records: die Metadaten der Zone

Jede Zonendatei beginnt mit einem Start-of-Authority-Record (SOA). Er enthält die Metadaten der Zone: den primären Nameserver, die E-Mail-Adresse des Administrators in DNS-Notation, eine Seriennummer und Timing-Parameter. Der Refresh-Wert — wie oft ein sekundärer Server beim primären nach Aktualisierungen fragen soll — liegt üblicherweise zwischen einer Stunde und 24 Stunden. Praktisch relevant ist die Seriennummer: Sie wird bei jeder Änderung hochgezählt und ist damit ein günstiger Weg, um zu bestätigen, dass eine Zonenkopie neuer ist als die bereits vorhandene.

NS-Records: Delegation der Zuständigkeit

Nameserver-Records (NS) legen fest, welche DNS-Server für eine Domain autoritativ sind. In einer TLD-Zonendatei sind das die Delegations-Records, und meist sind sie die einzigen Daten, die pro Domain vorliegen — eine Registry-Zonendatei enthält in der Regel Delegationen statt sämtlicher Records jeder einzelnen Domain. Nützlich sind sie trotzdem: Nameserver-Muster verraten den Registrar oder die Hosting-Plattform hinter einer Domain, und bekannte Parking-Nameserver lassen sich vor jeder weiteren Verarbeitung herausfiltern.

A- und AAAA-Records: die Verbindung zur IP-Adresse

A-Records (IPv4) und AAAA-Records (IPv6) verknüpfen eine Domain oder Subdomain mit einer IP-Adresse. Sie liegen in der Zone der Domain selbst und werden von den Nameservern ausgeliefert, an die die TLD delegiert — sie zu erhalten bedeutet also, jede Domain aufzulösen, statt die TLD-Datei zu lesen. Aus diesem Auflösungsschritt stammt die Zuordnung zu Hosting-Anbieter und Geografie, und er ist deutlich teurer als das Parsen der Zonendatei selbst.

MX-Records: die Torwächter der Mailzustellung

Mail-Exchanger-Records (MX) legen fest, welche Server die E-Mails einer Domain annehmen und in welcher Prioritätsreihenfolge. In der Praxis sind sie zugleich die kurzlebigsten Records: Eine Domain kann den Mail-Anbieter wechseln, ohne dass sich sonst etwas sichtbar ändert. Wer Domaindaten für E-Mail-Kampagnen nutzt, sollte die Gültigkeit der MX-Records möglichst kurz vor dem Einsatz erneut prüfen, statt sich auf einen Wochen zuvor erfassten Record zu verlassen.

Woher die Zonendateien kommen: die Kluft zwischen gTLD und ccTLD

Der Bezug von Zonendaten läuft nicht überall gleich ab. Der Zugang unterscheidet sich deutlich zwischen generischen Top-Level-Domains (gTLDs) und länderspezifischen Top-Level-Domains (ccTLDs).

gTLD-Zonendateien: vergleichsweise zugänglich

Bei gTLDs wie .com, .net, .org, .xyz und .app regelt der Centralized Zone Data Service (CZDS) der ICANN den Zugang. Registries mit ICANN-Vertrag sind verpflichtet, ihre Zonendateien zugelassenen Antragstellern bereitzustellen; diese beantragen den Zugang je TLD und akzeptieren die Nutzungsbedingungen. Die Freigabe erfolgt pro Registry und kann verweigert oder widerrufen werden, veröffentlicht wird im Tagesrhythmus. Der Prozess ist gangbar, aber verwaltungsintensiv: Jede TLD bedeutet einen eigenen Antrag, und der Zugang muss gepflegt werden.

ccTLD-Zonendateien: die Beschaffungshürde

ccTLD-Zonendateien sind deutlich schwerer zu bekommen als gTLD-Zonendateien. ccTLD-Registries stehen außerhalb der gTLD-Verträge der ICANN und legen ihre Regeln selbst fest. Manche geben Zonendaten unter Vereinbarung an Forschende heraus, manche veröffentlichen überhaupt nichts — und datenschutzsensible Jurisdiktionen gehören häufig zur zweiten Gruppe: DENIC für .de und AFNIC für .fr beschränken den Bulk-Zugang zu Zonendaten, statt sie offen zu publizieren. Wo eine Registry nichts veröffentlicht, muss die Abdeckung aus anderen Quellen zusammengesetzt werden: Passive DNS, Certificate-Transparency-Logs, Crawl-Daten und aggregierte kommerzielle Datensätze. Deshalb ist eine wirklich globale Domain-Datenbank nie eine einzige Pipeline.

Das Rauschproblem bei neu registrierten Domains

Listen neu registrierter Domains, gewonnen aus täglichen Diffs der Zonendateien, sind nützlich, aber verrauscht. Ein großer Teil der Neuregistrierungen eines Tages besteht aus geparkten Seiten, PPC-Platzhaltern, defensiven Registrierungen oder Massenregistrierungen, hinter denen nie eine echte Website stehen wird. Wer mit dem rohen Diff arbeitet, arbeitet überwiegend mit genau diesen.

Die Filterung, die daran etwas ändert, ist im Prinzip unkompliziert. Domains, die auf bekannte Parking-Nameserver delegiert sind, fliegen raus. Registrare, deren Neuregistrierungen von Massenaktivität dominiert werden, werden zurückgestuft. Der Rest wird aufgelöst und daraufhin geprüft, ob über HTTP überhaupt etwas antwortet. Jede Schicht entfernt einen Teil des Rauschens, und die Schichten sind billig zu bauen — verglichen mit dem Aufwand, Outreach oder Analysen gegen eine ungefilterte Liste zu fahren.

Eine Einschränkung gehört dazu: Aggressives Filtern nach Nameservern hat eine reale Falsch-Positiv-Rate. Kleine Unternehmen und private Projekte starten häufig beim günstigsten verfügbaren Hoster, dessen Nameserver sich nicht von denen wertloser Massenregistrierungen unterscheiden lassen. Wer allein nach Nameservern filtert, verwirft legitime Domains — besser nutzt man das Kriterium als eines von mehreren Signalen statt als hartes Ausschlusskriterium.

Frische Listen statt alter Marktplatz-Dumps

Für Outreach an neu registrierte Domains zählt Aktualität mehr als Menge. Der Grund ist mechanischer, nicht statistischer Natur: Der Wert einer Neuregistrierung als Lead liegt darin, dass der Inhaber die Domain gerade aufsetzt und aktiv über Hosting, Design und Marketing entscheidet. Eine 30 oder 60 Tage alte Liste hat dieses Zeitfenster verpasst — viele dieser Domains sind bereits fertig gebaut, bereits aufgegeben oder bereits markiert.

Billige Massenlisten von allgemeinen Marktplätzen werden meist einmal zusammengestellt und dann immer wieder weiterverkauft: Die Registrierungsdaten verteilen sich über Monate, und die Empfänger wurden oft schon kontaktiert. Eine kleinere Liste aus einem aktuellen Zonen-Diff, gefiltert auf die TLDs und Plattformen, die Sie tatsächlich adressieren, ist ein anderer Typ von Asset — auch wenn sie pro Zeile mehr kostet.

Praktische Erkenntnisse

1. MX-Records zeitnah zum Einsatz validieren. MX-Daten altern schneller als fast alles andere in Domaindaten. Vor einer Kampagne erneut prüfen, statt einem früher erfassten Record zu vertrauen. Schwierigkeit: mittel.
2. Neuregistrierungen über mehr als ein Signal filtern. Erkennung von Parking-Nameservern, Registrar-Muster und eine einfache HTTP-Prüfung kombinieren. Jedes Kriterium für sich erzeugt entweder zu viel Rauschen oder zu viele Falsch-Negative. Schwierigkeit: hoch.
3. Für Outreach Aktualität vor Menge stellen. Eine aktuelle, eng gefasste Liste im Wochen- oder Tagesrhythmus schlägt einen großen, veralteten Dump. Schwierigkeit: gering bis mittel.
4. Nicht von einem einheitlichen Dateiformat ausgehen. Zonendateien unterscheiden sich zwischen den Registries in Record-Typen, Kommentarkonventionen und Kodierung. Den Parser so bauen, dass er bei unerwarteten Eingaben laut scheitert, statt Records stillschweigend zu verwerfen. Schwierigkeit: mittel.
5. Aggregierte Daten kaufen, wo der direkte Zugang verschlossen ist. Wo eine Registry nichts veröffentlicht, lohnt das Verhandeln um Zugang selten die Zeit. Der Katalog von WebTrackly deckt 716 TLD-Zonen als sofort nutzbare CSV-Downloads ab. Schwierigkeit: gering.

FAQ

Wie häufig werden DNS-Zonendateien aktualisiert?

Die Aktualisierungsfrequenz hängt von der TLD ab. Große gTLDs wie .com und .net veröffentlichen täglich, meist in den frühen Morgenstunden UTC. Manche ccTLDs veröffentlichen wöchentlich, seltener oder gar nicht. Die Dateien von WebTrackly werden im Moment des Kaufs aus einer täglich aktualisierten Quelle erzeugt — ein Download bildet also den aktuellen Stand ab und nicht einen gespeicherten Export.

Bekomme ich aus einer Zonendatei eine vollständige Liste aller Domains?

Eine TLD-Zonendatei enthält die delegierten Domains, die unter dieser TLD registriert sind — für diese eine Endung also im Prinzip ja. Schwierig wird es über alle TLDs hinweg: Der gTLD-Zugang läuft über den CZDS der ICANN mit einem eigenen Antrag je Registry, und viele ccTLDs bieten überhaupt keinen öffentlichen Zugang. Der Zonenkatalog von WebTrackly deckt 716 Zonen ab, und der Datensatz aller registrierten Domains umfasst 272,614,863 Zeilen.

Was ist der Unterschied zwischen einer DNS-Zonendatei und einer WHOIS-Datenbank?

Eine DNS-Zonendatei listet Domainnamen und ihre Delegations-Records auf und beschreibt damit, wie der Traffic geroutet wird. Eine WHOIS-Datenbank enthält Registrierungs-Metadaten — Registrar, Registrierungs- und Ablaufdatum sowie, sofern nicht geschwärzt, Angaben zum Inhaber. Beide beantworten unterschiedliche Fragen. Die Pakete von WebTrackly decken die Zonen- und Technologieseite ab; sie enthalten Domains, keine persönlichen Kontaktdaten.

Wie nützlich sind Daten zu neu registrierten Domains für die Leadgenerierung?

Sie sagen zuverlässig, welche Domains wann registriert wurden — ein echtes zeitliches Signal. Sie sagen nicht, wer sie registriert hat oder ob hinter der Registrierung ein echtes Unternehmen steht: Ein großer Teil der Neuregistrierungen eines Tages ist geparkt oder defensiv. Erst das Filtern nach Nameserver, Registrar und einer einfachen HTTP-Prüfung macht aus dem rohen Diff etwas, das Handeln lohnt; die Ermittlung von Kontaktdaten bleibt ein separater Schritt mit eigenem Tooling.