SOA-Record im DNS verständlich erklärt: Start of Authority
Der SOA-Record (kurz für Start of Authority) ist der wichtigste administrative Eintrag in einer DNS-Zonendatei. Er markiert den Beginn einer DNS-Zone und enthält grundlegende Informationen über die Zonenverwaltung. Dazu gehören der primäre Nameserver, die E-Mail-Adresse des Administrators, eine Seriennummer zur Versionskontrolle sowie verschiedene Zeitintervalle für Zonenübertragungen (Zone Transfers) zwischen primären und sekundären Nameservern.
Der SOA-Record steht ganz oben in der DNS-Hierarchie einer Zone und bestimmt indirekt, wie schnell Änderungen über die DNS-Propagation global sichtbar werden. Wer die Funktion der einzelnen Parameter versteht, kann Zonenübertragungen gezielt steuern und Ausfälle vermeiden.
Aufbau und Syntax eines SOA-Records
Ein SOA-Eintrag ist komplexer aufgebaut als herkömmliche DNS-Einträge und enthält mehrere nummerische Parameter in einer festen Reihenfolge:
example.com. 86400 IN SOA ns1.dns-provider.com. hostmaster.example.com. (
2026062001 ; Serial
86400 ; Refresh
7200 ; Retry
3600000 ; Expire
3600 ; Minimum TTL
)
Die Parameter im Überblick
| Parameter | Beispielwert | Funktion |
|---|---|---|
| MNAME | ns1.dns-provider.com. | Primärer (Master-)Nameserver |
| RNAME | hostmaster.example.com. | Admin-E-Mail (Punkt statt @) |
| Serial | 2026062001 | Versionsnummer der Zone |
| Refresh | 86400 | Prüfintervall der Slaves |
| Retry | 7200 | Wartezeit nach Fehlversuch |
| Expire | 3600000 | Maximale Gültigkeit ohne Master |
| Minimum TTL | 3600 | Cache-Dauer negativer Antworten |
Die Parameter im Detail:
- Primärer Nameserver (MNAME -
ns1.dns-provider.com.): Der autoritative Master-Nameserver, auf dem die originale Zonendatei gepflegt wird. - Verantwortliche Person (RNAME -
hostmaster.example.com.): Die E-Mail-Adresse des Administrators (der erste Punkt ersetzt das@). - Seriennummer (SERIAL -
2026062001): Die Versionsnummer der Zonendatei. Sekundäre Nameserver (Slaves) vergleichen diese Nummer in regelmässigen Abständen mit ihrer eigenen Version. Ist die Nummer auf dem Master grösser, starten sie eine Zonenübertragung.- Best Practice: Das Format
YYYYMMDDNN(Jahr, Monat, Tag, zweistellige Revisionsnummer) stellt sicher, dass die Seriennummer bei jeder Änderung im Laufe eines Tages logisch ansteigt.
- Best Practice: Das Format
- Refresh (
86400/ 24 Stunden): Gibt in Sekunden an, wie oft sekundäre Nameserver beim Master anfragen sollen, ob eine neue Seriennummer vorliegt. - Retry (
7200/ 2 Stunden): Das Wartezeit-Intervall, falls der Master-Nameserver während eines Refreshs nicht erreichbar war. - Expire (
3600000/ ca. 41 Tage): Bestimmt, wie lange ein sekundärer Nameserver die Zone noch als gültig ausliefern darf, wenn er den Master-Nameserver dauerhaft nicht erreichen kann. Nach dieser Zeit stellt er die Auflösung ein. - Minimum TTL (
3600/ 1 Stunde): Bestimmt die Cache-Dauer für negative DNS-Antworten (NXDOMAIN - „Diese Domain/Subdomain existiert nicht“). Dies verhindert, dass Resolver den Nameserver bei Tippfehlern sekündlich neu überlasten.
Typische Fehler und ihre Folgen
Da der SOA-Record die Zonenübertragung steuert, ziehen Fehler hier weitreichende Konsequenzen nach sich:
| Fehler | Folge | Korrektur |
|---|---|---|
| Seriennummer nicht erhöht | Slaves liefern alte Zone aus | Serial bei jeder Änderung hochzählen |
| Rückwärts laufende Serial | Zonenübertragung stoppt | Format YYYYMMDDNN einhalten |
| Expire zu kurz | Domain fällt bei Master-Ausfall aus | Realistisch (Tage–Wochen) setzen |
| Falsche RNAME-Syntax | Admin-Benachrichtigungen scheitern | Punkt statt @ verwenden |
Beispiel: SOA-Record mit dig prüfen
$ dig example.com SOA +short
ns1.dns-provider.com. hostmaster.example.com. 2026062001 86400 7200 3600000 3600
Steigt die Seriennummer nach einer Änderung nicht an, ist das fast immer die Ursache dafür, dass eine DNS-Anpassung nur teilweise propagiert.
Relevanz für den Betrieb
In modernen Anycast-DNS-Netzwerken, bei denen der DNS-Provider die Zonendaten automatisch global auf Hunderte Server spiegelt, läuft die Zonenübertragung meist über proprietäre Echtzeit-Mechanismen. Dennoch bleibt der SOA-Record eine zwingende Pflichtkomponente jeder DNS-Zone. Ein fehlerhafter SOA-Record (z. B. eine rückwärts laufende Seriennummer oder unrealistisch kurze Expire-Zeiten) führt dazu, dass sekundäre Nameserver die Auflösung verweigern und die Website offline geht. Bei sporadischen Auflösungsproblemen lohnt sich daher immer ein Blick in das DNS-Troubleshooting.
[!TIP] Die Seriennummer im SOA-Record ist die Versionskontrolle Ihrer DNS-Einstellungen. Prüfen Sie die administrativen Parameter Ihrer DNS-Zone ganz einfach mit dem DNS Check auf balou.tools.
Häufig gestellte Fragen (FAQ)
Warum darf es nur einen einzigen SOA-Record pro Zone geben?
Der SOA-Record deklariert die administrative Führung über eine DNS-Zone. Gäbe es mehrere SOA-Records, wüssten sekundäre Nameserver nicht, welche Zonenparameter (z. B. Seriennummern) die gültige Quelle der Wahrheit darstellen.
Wie funktioniert das E-Mail-Format im SOA-Eintrag?
Da das `@`-Zeichen im DNS eine spezielle Bedeutung hat (Platzhalter für die Root-Domain), wird es im SOA-Record durch einen Punkt ersetzt. Die Adresse `hostmaster.example.com` entspricht der E-Mail-Adresse `hostmaster@example.com`.
Was passiert, wenn ich vergesse, die Seriennummer zu erhöhen?
Sekundäre Nameserver erkennen die Änderung nicht und liefern weiterhin die alte Zonenversion aus. Ihre DNS-Änderung (z. B. ein neuer A-Record) wird dann nur auf dem primären Server sichtbar, während ein Teil der Welt die veraltete Antwort erhält. Viele DNS-Provider erhöhen die Seriennummer deshalb automatisch bei jeder Änderung.
Wie frage ich den SOA-Record einer Domain ab?
Mit dem Kommandozeilen-Werkzeug `dig` und dem Befehl `dig example.com SOA`. Die Ausgabe zeigt den primären Nameserver, die Administrator-Adresse, die aktuelle Seriennummer sowie alle Zeitintervalle und hilft so, Probleme bei der Zonenübertragung einzugrenzen.