DNS-Zonendateien: Records, Namen und TTLs erklärt

Eine DNS-Zonendatei ist eine Textdarstellung der DNS-Records einer Zone, etwa von example.com. Sie beschreibt Namen und die ihnen zugeordneten Daten, darunter Adressen, Aliasse, Mail-Exchanger, Nameserver und Text-Richtlinien. Viele verwaltete Anbieter verbergen die Rohdatei hinter einer Weboberfläche, doch Exporte und Importe arbeiten weiterhin mit Zonendatei-Konzepten. Das Format zu verstehen ist bei Anbieterwechseln, Audits und der Fehlersuche wertvoll, denn ein Record kann syntaktisch gültig sein und dennoch am falschen Namen hängen oder mit einem unerwarteten Standardwert interpretiert werden. Eine sorgfältige Prüfung sollte sowohl den Inhalt jedes Records als auch den Zonenkontext berücksichtigen, in dem er steht.

Die Bestandteile eines Resource Records

Ein Resource Record enthält im Allgemeinen einen Owner-Namen, eine optionale TTL, eine Klasse (meist IN für Internetdaten), einen Record-Typ und typspezifische Daten. Eine A-Record-Zeile enthält eine IPv4-Adresse, eine MX-Zeile eine Präferenz und den Hostnamen des Mail-Exchangers, eine CNAME-Zeile einen kanonischen Zielnamen. Zonendateien können relative Namen verwenden, bei denen ein Owner relativ zum Zonen-Origin interpretiert wird, sowie Sonderzeichen wie @ für den Zonen-Apex. Ein abschließender Punkt kann einen vollqualifizierten Namen kennzeichnen. Beim Import kann die Verwechslung relativer und absoluter Namen versehentlich zu einem doppelten Domain-Suffix führen.

Der Zonen-Apex ist der reine Zonenname, etwa example.com, und wird in einer Zonendatei häufig durch @ dargestellt. Hier gehören die SOA- und NS-Records der Zone hin. A- und AAAA-Records am Apex veröffentlichen Adressen, während Subdomain-Owner wie www oder mail eigenständige Namen darstellen. Manche Anbieter bieten ALIAS- oder Flattening-Funktionen, die am Apex wie eine Adresse aussehen, im Hintergrund aber einem Hostnamen folgen; das sind anbieterspezifische Verhaltensweisen und keine gewöhnlichen CNAME-Records an der Root. Prüfen Sie bei einer Migration, wie der Zielanbieter solche Funktionen abbildet, bevor Sie sie wörtlich übernehmen.

Eine Zone als vollständige Dienstlandkarte prüfen

Behandeln Sie einen DNS-Export nicht nur als Website-Konfiguration. Die E-Mail-Zustellung kann von MX sowie SPF-, DKIM- und DMARC-TXT-Records abhängen. Die Inhaberschaftsprüfung für Analyse- und Suchdienste, Zertifikatssysteme und SaaS-Plattformen kann auf TXT- oder CNAME-Records beruhen. Die Diensterkennung kann SRV nutzen, und delegierte Subdomains haben womöglich eigene NS-Records. Ein alter Record, der unbekannt aussieht, kann dennoch eine Produktionsabhängigkeit stützen. Klären Sie vor jedem Löschen, wem er gehört und wozu er dient. Ist die Herkunft unbekannt, vergleichen Sie den Record mit der Anwendungsdokumentation und fragen Sie das zuständige Team, statt anzunehmen, dass ein scheinbar ungenutzter Hostname bedenkenlos entfernt werden kann.

• Exportieren Sie die vollständige Zone vor einer Anbietermigration oder Bereinigung.
• Prüfen Sie Apex- und Subdomain-Namen sorgfältig, einschließlich der Regeln für relative Namen.
• Bewahren Sie E-Mail-, Verifizierungs- und Delegierungs-Records für Subdomains auf.
• Prüfen Sie TTLs sowie anbieterspezifische Flattening- oder Proxy-Funktionen.
• Fragen Sie nach dem Import die autoritativen Nameserver ab und vergleichen Sie kritische Records.

Sicher importieren und validieren

Ein Zonendatei-Import kann an nicht unterstützten Record-Typen, Formatunterschieden, doppelten Ownern oder anbieterspezifischen Erweiterungen scheitern. Validieren Sie die exportierte Datei vor dem Cutover und prüfen Sie den Importbericht des Anbieters auf übersprungene Records. Wechselt der DNS-Anbieter, stellen Sie sicher, dass die neue Zone befüllt ist, bevor Sie die Delegierung beim Registrar ändern. Sobald sich die Delegierung ändert, prüfen Sie die NS-Records und fragen Sie wichtige Records direkt ab. Vergleichen Sie die Live-Antworten mit dem Quell-Export und führen Sie dienstspezifische Prüfungen für Website und E-Mail durch. Ein syntaktisch erfolgreicher Import ist keine verifizierte Migration; er beweist nur, dass das Werkzeug die Datei akzeptiert hat.

Die gängigsten Record-Bedeutungen finden Sie unter DNS-Record-Typen erklärt. Für die Nameserver-Seite einer Migration lesen Sie was ein NS-Record bewirkt. Eine Zonendatei ist ein kompaktes Inventar der Konfiguration, und ihr Wert ist am größten, wenn Teams den Kontext neben den Rohzeilen festhalten. Notieren Sie, warum ungewöhnliche Records existieren, wem sie gehören und welche Dienste von ihnen abhängen. Dieser kleine Dokumentationsaufwand kann verhindern, dass eine spätere Bereinigung unbemerkt etwas Wichtiges entfernt.

Die Absicht bewahren, nicht nur die exportierten Zeilen

Ein roher Zonenexport ist ein nützliches Backup, erklärt aber selten, warum ein Record existiert oder welches Team von ihm abhängt. Legen Sie neben der Datei ein Inventar an, das den Anwendungsverantwortlichen, den Anbieter, das Verlängerungs- oder Prüfdatum und die Information enthält, ob ein Wert sicher geändert werden kann. Dieser Kontext ist besonders bei TXT-Records wichtig, die wie beliebige Tokens aussehen, aber die Inhaberschaft einer Domain belegen oder Mailsysteme autorisieren können. Unterscheiden Sie bei einem Audit aktive Records von veralteten, die nur für eine Übergangszeit behalten werden. Vergleichen Sie nach dem Import in einen neuen Anbieter sowohl Daten als auch Verhalten: Anbieterspezifische Proxy-Schalter, Flattening und Validierungseinstellungen sind möglicherweise nicht als gewöhnliche Zonendatei-Zeilen abgebildet. Eine Zone ist operative Konfiguration, und wer ihre Absicht bewahrt, macht spätere Änderungen sicherer.