Was ist ein DNS-SOA-Record?

DNS
Veröffentlicht von

Wenn Sie schon einmal die DNS-Einträge einer Domain mit dig oder einem Online-Tool untersucht haben, ist Ihnen wahrscheinlich ein SOA-Record begegnet, ohne genau zu wissen, wofür er steht. Dabei ist er einer der wichtigsten Einträge jeder DNS-Zone: Er legt fest, wer die Autorität über diese Zone hat, wie sich sekundäre DNS-Server synchronisieren sollen und wie lange Daten bei einem Ausfall des Primärservers gültig bleiben.

Was ein SOA-Record enthält

SOA steht für Start of Authority. Jede DNS-Zone muss genau einen SOA-Record enthalten. Er steht immer an der Spitze der Zone und umfasst sieben verschiedene Felder. So sieht ein typischer SOA-Record aus:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Die einzelnen Felder im Detail:

  • MNAME (ns1.example.com.): der primäre autoritative DNS-Server der Zone. Das ist der Server, den sekundäre Server kontaktieren, um Updates zu holen
  • RNAME (admin.example.com.): die E-Mail-Adresse des Zonenadministrators, wobei ein Punkt das @ ersetzt. Hier entspricht es [email protected]. Enthält der lokale Teil einen Punkt, muss dieser mit einem Backslash escaped werden (vorname\.nachname.example.com.)
  • Serial (2025052901): eine Versionsnummer der Zone. Jede Änderung muss diese Nummer erhöhen, sonst erkennen die Sekundärserver die Änderung nicht. Das übliche Format ist YYYYMMDDNN (Datum plus Tageszähler)
  • Refresh (7200): das Intervall in Sekunden zwischen Prüfungen durch die Sekundärserver. Hier alle 2 Stunden
  • Retry (3600): die Wartezeit vor einem erneuten Versuch, wenn die Refresh-Prüfung fehlschlägt. Hier 1 Stunde
  • Expire (1209600): die Zeit, nach der ein Sekundärserver aufhört, für die Zone zu antworten, wenn er den Primärserver nicht mehr erreicht. Hier 14 Tage. Nach Ablauf dieser Frist betrachtet der Sekundärserver seine Daten als veraltet und stellt die Bedienung der Zone ein
  • Minimum TTL (86400): seit RFC 2308 legt dieses Feld fest, wie lange negative Antworten (NXDOMAIN) gecacht werden. Hier 24 Stunden. Fragt jemand eine nicht existierende Subdomain ab, wird die Antwort "existiert nicht" 24 Stunden lang im Cache gehalten

Warum die Seriennummer so wichtig ist

Die Serial ist vermutlich das Feld, das in der Praxis die meisten Probleme verursacht. Wenn ein Sekundärserver den Primärserver während eines Refresh-Zyklus kontaktiert, vergleicht er seine lokale Seriennummer mit der des Primärservers. Ist die des Primärservers höher, startet der Sekundärserver einen Zonentransfer (AXFR oder IXFR), um sich zu aktualisieren. Hat sich die Serial nicht geändert, passiert nichts.

Der klassische Fehler: einen DNS-Eintrag auf dem Primärserver ändern, ohne die Serial zu erhöhen. Ergebnis: Der Primärserver hat die korrekte Version, aber die Sekundärserver liefern stunden- oder tagelang die alte. Nutzer erhalten unterschiedliche Antworten je nachdem, welchen Server sie treffen, und das Problem ist schwer zu diagnostizieren, wenn niemand daran denkt, den SOA zu prüfen.

Das Format YYYYMMDDNN ist eine Konvention, keine Pflicht. Die Serial ist ein 32-Bit-Integer, jeder Wert von 0 bis 4.294.967.295 funktioniert. Das Datumsformat wird aber empfohlen, weil es Fehler sichtbar macht: Eine Serial von 2025052901 ist eindeutig die erste Änderung vom 29. Mai 2025.

Wie Refresh, Retry und Expire zusammenspielen

Diese drei Werte bilden ein Resilienzsystem für DNS-Zonen. Refresh gibt den normalen Sync-Rhythmus vor. Retry greift bei Fehlschlag. Expire ist das letzte Sicherheitsnetz: Ist dieser Zeitraum ohne Kontakt zum Primärserver verstrichen, antwortet der Sekundärserver lieber gar nicht mehr, als möglicherweise veraltete Daten auszuliefern.

Für eine Standarddomain empfiehlt RFC 1912:

  • Refresh: 3.600 bis 86.400 Sekunden (1 Stunde bis 24 Stunden)
  • Retry: 600 bis 3.600 Sekunden (10 Minuten bis 1 Stunde)
  • Expire: 1.209.600 bis 2.419.200 Sekunden (2 bis 4 Wochen)
  • Minimum TTL: 3.600 bis 86.400 Sekunden (1 Stunde bis 24 Stunden)

Wenn sich Ihre Zone häufig ändert (etwa bei einem CDN oder dynamischem Load Balancing), senken Sie den Refresh auf 300 oder 600 Sekunden. Ist sie stabil, passt 86.400 bestens und reduziert die Last auf dem Primärserver.

So prüfen Sie den SOA-Record einer Domain

Unter Linux und macOS ist der Befehl dig am praktischsten:

dig SOA example.com

Unter Windows verwenden Sie nslookup:

nslookup -type=SOA example.com

Die Antwort zeigt alle sieben SOA-Felder. Achten Sie besonders auf die Serial: Wirkt sie alt oder eingefroren, ist das oft der Grund, warum DNS-Änderungen nicht korrekt propagieren.

Häufige SOA-Fehler

Einige Probleme, die in der Praxis regelmäßig auftreten:

  • Das RNAME verwendet ein @ statt eines Punkts, was die Syntax bricht. [email protected] muss im SOA als admin.example.com. geschrieben werden
  • Die Serial wird nach einem Backup-Restore versehentlich verringert. Sekundärserver verweigern die Synchronisation, bis die Serial des Primärservers wieder über ihrem lokalen Wert liegt
  • Expire ist zu kurz gesetzt (wenige Stunden). Fällt der Primärserver übers Wochenende aus, stellen die Sekundärserver ihren Dienst ein, bevor jemand eingreifen konnte
  • Minimum TTL steht auf 0, sodass Resolver negative Antworten nicht cachen. Jede Abfrage einer nicht existierenden Subdomain erzeugt einen vollständigen Roundtrip, was Ihre DNS-Server bei einem Scan oder Angriff überlasten kann
Den SOA-Record ändert man beim Einrichten einer Domain selten zuerst, doch er ist oft der Grund, warum "die DNS-Änderungen nicht ankommen". Bevor Sie nach komplexen Ursachen suchen, prüfen Sie, ob die Serial korrekt erhöht wurde und ob die Refresh- und Expire-Werte zu Ihrem Anwendungsfall passen.