Was ist ein DNS-SOA-Record und warum er für Ihre Domain wichtig ist

Was ist ein SOA-Record?

Der SOA-Record (Start of Authority) ist der erste Record jeder DNS-Zone und der einzige, der genau einmal vorhanden sein muss. Er benennt den primären Nameserver der Zone, die Kontaktadresse des Administrators sowie eine Reihe von Timern, die sekundären Nameservern vorgeben, wie sie ihre Kopie der Zone synchron halten.

Anders als ein A- oder MX-Record dient der SOA nicht dazu, Anfragen von Nutzern zu beantworten. Er ist Metadaten über die Zone selbst: wer für sie autoritativ ist, welche Version der Zone dies ist und wie lange andere Server dieser Version vertrauen oder sie zwischenspeichern dürfen. Ist der SOA falsch, löst die Zone heute vielleicht noch auf — aber sie wird nicht mehr aktualisiert, läuft nicht ab oder speichert Fehler viel zu lange im Cache.

Den SOA-Record jeder Domain können Sie mit dig anzeigen:

dig SOA example.com +short

Eine typische Antwort sieht so aus:

ns1.example.com. hostmaster.example.com. 2026082601 3600 900 1209600 300

Die sieben Werte sind der primäre Nameserver, das verantwortliche Postfach und fünf Zahlen — die Seriennummer und vier Timer —, die im Folgenden erklärt werden.

Die sieben SOA-Felder erklärt

Jeder SOA-Record enthält dieselben sieben Felder in dieser Reihenfolge:

MNAME — der primäre Nameserver der Zone. Sekundäre Server richten ihre Refresh-Anfragen an diesen Host und erwarten von ihm NOTIFY-Nachrichten. Es sollte ein auflösbarer Hostname sein, keine IP-Adresse.

RNAME — das Postfach der für die Zone verantwortlichen Person, mit einem Punkt statt des @ geschrieben: hostmaster.example.com bedeutet [email protected]. Enthält der lokale Teil selbst einen Punkt, wird dieser mit einem Backslash maskiert.

Serial — die Versionsnummer der Zone. Sekundäre Server vergleichen sie mit ihrer eigenen Kopie, um zu entscheiden, ob sich die Zone geändert hat. Es ist das mit Abstand wichtigste Feld, um sekundäre Nameserver aktuell zu halten.

Refresh — wie oft (in Sekunden) ein sekundärer Server den primären nach der aktuellen Seriennummer fragt. 3600 (eine Stunde) ist ein gängiger Wert. Mit konfiguriertem NOTIFY ist dieser Timer nur noch ein Sicherheitsnetz.

Retry — wie lange ein sekundärer Server nach einem fehlgeschlagenen Refresh-Versuch wartet, bevor er erneut fragt. Der Wert sollte kürzer als Refresh sein; 900 (15 Minuten) ist üblich.

Expire — wie lange ein sekundärer Server die Zone weiter ausliefert, nachdem er den primären Server zuletzt erreichen konnte. Läuft dieser Timer ab, stellt der sekundäre Server die Antworten für die Zone vollständig ein. 1209600 (zwei Wochen) ist der übliche Wert.

Minimum — historisch die Standard-TTL für Records; seit RFC 2308 definiert es die TTL für das Negativ-Caching: wie lange Resolver die Tatsache zwischenspeichern dürfen, dass ein Name nicht existiert (NXDOMAIN). Die wirksame negative TTL ist der kleinere Wert aus diesem Feld und der TTL des SOA-Records selbst. 300 bis 3600 ist ein sinnvoller Bereich.

Wie sekundäre Nameserver den SOA nutzen

Der SOA-Record ist der Vertrag zwischen Ihrem primären Nameserver und jedem sekundären Server, der Ihre Zone ausliefert. Ein sekundärer Server durchläuft diesen Zyklus:

1. Alle Refresh Sekunden fragt er den primären Server nach dem SOA-Record. 2. Er vergleicht die Seriennummer in der Antwort mit der Seriennummer seiner eigenen Kopie. 3. Ist die Seriennummer des primären Servers höher, fordert er einen Zonentransfer (AXFR oder IXFR) an und übernimmt die neue Kopie. 4. Schlägt die Anfrage fehl, versucht er es nach Retry Sekunden erneut. 5. Kann er den primären Server Expire Sekunden lang nicht erreichen, verwirft er die Zone und antwortet mit SERVFAIL, bis der primäre Server wieder da ist.

Die meisten primären Server senden zudem in dem Moment, in dem sich die Zone ändert, eine NOTIFY-Nachricht, sodass der sekundäre Server die Seriennummer sofort prüft, statt auf den Refresh-Timer zu warten. Die Timer bleiben dennoch wichtig: NOTIFY kann verloren gehen, von einer Firewall blockiert oder schlicht nicht konfiguriert sein — dann sind Refresh und Retry das Einzige, was die Kopien synchron hält.

Deshalb kann ein gehosteter Secondary-DNS-Dienst Ihre Domain online halten, während der primäre Server ausgefallen ist: Er besitzt bereits eine vollständige, aktuelle Kopie der Zone und beantwortet Anfragen dafür weiter, bis Expire abläuft. Siehe DNS-Redundanz für das Gesamtbild und AXFR-Zonentransfers verstehen für die Funktionsweise des Transfers selbst.

Die Seriennummer: Formate und klassische Fehler

Die Seriennummer ist eine vorzeichenlose 32-Bit-Ganzzahl, und die einzige Regel, die das Protokoll durchsetzt, lautet: Eine neuere Zone muss eine größere Seriennummer tragen als die vorherige. Sekundäre Server schauen weder auf Datumsangaben noch auf Dateizeitstempel — nur auf diese Zahl.

Datumsbasierte Seriennummern sind die verbreitetste Konvention: YYYYMMDDnn, zum Beispiel 2026082601 für die erste Änderung am 26. August 2026. Die letzten zwei Ziffern erlauben bis zu 100 Änderungen pro Tag, und die Zahl bleibt in der dig-Ausgabe für Menschen lesbar.

Unix-Zeitstempel als Seriennummer verwenden viele Managed-DNS-Anbieter sowie BIND, wenn serial-format unixtime konfiguriert ist. Sie steigen automatisch und kollidieren nie.

Einfache Zähler (1, 2, 3, …) sind ebenfalls völlig zulässig. Das Format ist eine Konvention, keine Vorgabe.

Die Fehler, die Zonen tatsächlich kaputtmachen:

- Das Erhöhen der Seriennummer vergessen. Sie bearbeiten die Zonendatei, laden den primären Server neu, und er antwortet mit den neuen Daten — aber jeder sekundäre Server sieht weiterhin die alte Seriennummer, schließt daraus, dass sich nichts geändert hat, und liefert auf unbestimmte Zeit veraltete Records aus. Das ist die mit Abstand häufigste Ursache für „die Änderung funktioniert auf ns1, aber nicht auf ns2“.

- Rückwärts gehen. Der Wechsel von einer großen Zeitstempel-Seriennummer zu einer kleinen datumsbasierten oder das Zurückspielen einer alten Zonendatei hinterlässt beim sekundären Server eine höhere Seriennummer als beim primären. Er wird nie wieder transferieren, bis die Seriennummer des primären Servers seine überholt. Die Serial-Arithmetik (RFC 1982) bietet einen Ausweg: Addieren Sie 2^31 − 1 (2147483647) zur Seriennummer, lassen Sie jeden sekundären Server diese übernehmen und setzen Sie dann den eigentlich gewünschten Wert — der zweite Schritt wird wieder als Erhöhung gewertet.

- Die Seriennummer auf einem sekundären Server bearbeiten. Sekundäre Server dürfen niemals von Hand bearbeitet werden; der nächste Transfer überschreibt die Kopie, und die manuelle Änderung verschwindet.

Werte für Refresh, Retry, Expire und Minimum wählen

RFC 1912 gibt die klassische Empfehlung, und sie gilt nach wie vor. Vernünftige Standardwerte für eine Zone mit konfiguriertem NOTIFY:

Refresh — 1 Stunde (3600) Retry — 15 Minuten (900) Expire — 2 Wochen (1209600) Minimum — 5 Minuten bis 1 Stunde (300 – 3600)

Die zwei Regeln, die wichtiger sind als die genauen Zahlen:

Retry muss kürzer als Refresh sein, idealerweise nur ein kleiner Bruchteil davon — andernfalls wartet ein fehlgeschlagener Refresh einfach auf den nächsten planmäßigen, und der Retry-Timer bewirkt nichts.

Expire muss länger sein als der längste Ausfall, den Sie sich beim primären Server vorstellen können. Fällt der primäre Server am Freitagabend aus und bemerkt es niemand bis Montag, bedeutet ein Expire von 86400 (ein Tag), dass jeder sekundäre Server bereits am Samstag aufgehört hat zu antworten — und der ganze Sinn sekundärer Server ist dahin. Zwei Wochen sind die übliche Wahl und zugleich die Untergrenze für eine Produktivzone; RFC 1912 empfiehlt zwei bis vier Wochen.

Beim Minimum (Negativ-Caching) sorgen kürzere Werte dafür, dass ein neu angelegter Record schneller sichtbar wird, wenn er abgefragt wurde, während er noch nicht existierte; längere Werte verringern die Last durch wiederholte Abfragen von Namen, die nie existieren werden. Setzen Sie ihn nicht höher als wenige Stunden — ein Tippfehler in einem Hostnamen würde sonst einen ganzen Tag lang als nicht existent zwischengespeichert.

Einen veralteten sekundären Server mit dig diagnostizieren

Wenn eine DNS-Änderung auf einem Nameserver sichtbar ist, auf einem anderen aber nicht, verrät Ihnen die SOA-Seriennummer, wo das Problem liegt. Fragen Sie jeden autoritativen Server direkt:

dig @ns1.example.com example.com SOA +short
dig @ns2.example.com example.com SOA +short

Drei mögliche Ergebnisse:

Dieselbe Seriennummer auf beiden — die Zone ist synchron. Sieht ein Record trotzdem falsch aus, liegt das Problem beim Caching im Resolver, nicht bei der Replikation; warten Sie die TTL des Records ab oder fragen Sie den autoritativen Server direkt.

Niedrigere Seriennummer auf dem sekundären Server — der sekundäre Server kennt die Zone, hat aber die neueste Version nicht übernommen. Prüfen Sie, ob die Seriennummer auf dem primären Server tatsächlich erhöht wurde, ob der primäre Server Transfers von der IP des sekundären Servers erlaubt (allow-transfer / allow-axfr-ips), ob TCP-Port 53 zwischen beiden offen ist und ob der primäre Server überhaupt NOTIFY sendet.

SERVFAIL oder REFUSED vom sekundären Server — die Zone wurde entweder nie transferiert oder ist abgelaufen. Sehen Sie im Log des sekundären Servers nach dem letzten erfolgreichen Transfer; liegt er länger zurück als der Expire-Wert, hat der sekundäre Server die Zone korrekt verworfen und braucht den primären Server zurück, bevor er sie neu laden kann.

Ein sekundärer Server, der synchron sein sollte, es aber nicht ist, ist ein stiller Ausfall: Er antwortet weiter, nur mit alten Daten. Die Seriennummer auf jedem Nameserver zu überwachen — nicht nur die Erreichbarkeit — ist der einzige Weg, das zu bemerken, bevor es die Nutzer tun.

SOA-Record-Beispiel für eine typische Zone

Ein vollständiger SOA-Record in Zonendatei-Syntax mit den Timern aus der obigen Tabelle:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
        2026082601  ; serial  (YYYYMMDDnn)
        3600        ; refresh (1 hour)
        900         ; retry   (15 minutes)
        1209600     ; expire  (2 weeks)
        300 )       ; minimum (negative caching TTL, 5 minutes)

Die 3600 vor IN ist die TTL des SOA-Records selbst — wie lange Resolver ihn zwischenspeichern dürfen. Sie begrenzt zugleich die TTL für das Negativ-Caching nach oben: bei 3600 hier und einem Minimum von 300 speichern Resolver NXDOMAIN-Antworten 300 Sekunden lang, den kleineren der beiden Werte.

Wenn Sie ein Hosting-Panel oder die Weboberfläche eines DNS-Anbieters verwenden, wird der SOA in der Regel für Sie erzeugt, und die Seriennummer wird bei jedem Speichern automatisch erhöht. Die Timer-Werte sollten Sie dennoch einmal prüfen: Manche Panels liefern ein Expire von einem Tag aus, was jeden später hinzugefügten sekundären Server stillschweigend wirkungslos macht.