SOA Resource Record

Üblicherweise werden DNS-Nameserver in Clustern aufgebaut. Der Datenbestand innerhalb eines Clusters wird mittels Zonentransfers synchronisiert. Der SOA-Eintrag in der Zonendatei (also in der Datei zur vollständigen Konfiguration und Beschreibung der Zone) enthält Daten, mit denen der Zonentransfer gesteuert wird. Es handelt sich dabei um die Seriennummer und verschiedene Timer.

Außerdem sind die E-Mail-Adresse des Verantwortlichen für diese Zone sowie der Name des primary Master-Servers aufgeführt. Normalerweise steht ein SOA-Record am Anfang der Datei. Eine Zone ohne diesen Eintrag erfüllt nicht den DNS-Standard und kann nicht transferiert werden.

Beispiel eines SOA-Records in BIND9

mycompany.com. IN SOA ns1.mycompany.com. hosmaster@mycompany.com. (
                                   2026032701 ; Serial
                                           10800 ; refresh after 3 hours
                                             3600 ; retry after 1 hour
                                          604800 ; expire after 1 week
                                             1800 ; minimum TTL of 30 minutes)

In diesem Beispiel wird festgelegt, dass sich ein Slave alle 3 Stunden mit seinem Master per Zonentransfer synchronisiert. Ist sein Master nicht erreichbar, wird jede Stunde ein neuer Versuch gestartet. Kann der Master innerhalb von einer Woche nicht kontaktiert werden, so erklärt der Slave die Zone mycompany.com als inaktiv und beantwortet keine weiteren DNS-Requests zu dieser Domain. DNS cached auch fehlgeschlagene Request. Die TTL beträgt 30 Minuten.

Weiterhin wird definiert, dass der Primary dieser Zone master.mycompany.com ist und dass der Administrator über die E-Mail-Adresse hostmaster@mycompany.com erreichbar ist. Das „@“ wird durch einen „.“ ersetzt und ein „.“ vor dem „@“, z. B. vorname.nachname@mycompany.com, wird mit einem „\“ maskiert (z. B. vorname\.nachname.mycompany.com).

Die Seriennummer ist hier mit 2026032701 angegeben. Bei der nächsten Änderung muss sie (manuell) auf mindestens 2026032702 erhöht werden. Dabei sollte die Seriennummer eine maximal 10-stellige Zahl sein (Minium 1 und Maximum 9999999999). Entsprechend RFC 1912 2.2 setzt sich die Seriennummer aus dem aktuellem Datum und einem zweistelligen Zähler in der Art "JJJJMMDDzz" zusammen.

Das Ändern der Seriennummer geschieht durch das Hochzählen um 1 vor jedem Reload des BIND-Servers.

Zusammensetzung des SOA-Records

Name
Das ist der Zonenname
IN
Das ist die Zonenklasse (meist IN für Internet)
SOA
Das Kürzel für Start Of Authority
Primary
Die oder der Primary Master für diese Zone, hat in der Praxis nur geringe Bedeutung:
Definition, an wen dynamische Updates gesendet werden sollen (Dynamisches Update)
Definition, an wen keine Notifies gesendet werden (Zonentransfer)

Mail-Adresse
Die Mailadresse des Verantwortlichen für diese Zone.
Seriennummer
Besagte Serial number, die bei jeder Änderung inkrementiert werden muss.
Refresh
Bestimmt das Intervall, in dem sekundäre Nameserver prüfen, ob die Zone beim primären Nameserver aktualisiert wurde.
Retry
Gibt an, wie lange sekundäre Nameserver warten, bevor ein erneuter Versuch unternommen wird, falls der primäre Nameserver beim vorherigen Refresh nicht erreichbar war.
Expire
Legt fest, wie lange ein sekundärer Nameserver gültige Zonendaten zwischenspeichert, wenn keine Verbindung zum primären Nameserver hergestellt werden kann. Nach einer Woche ohne erfolgreiche Aktualisierung wird die Zone als abgelaufen betrachtet und nicht mehr serviert.
TTL
Definiert die Time-to-Live für nicht vorhandene Einträge (NXDOMAIN). Anfragen für nicht existierende Hostnamen werden für die angegebene Anzahl von Minuten zwischengespeichert, bevor erneut beim Nameserver nachgefragt wird. Auch als Negativ-Caching-TTL (DNS-Caching) genannt. 

Empfohlende Werte der DENIC

Die DENIC (Deutsches Network Information Center) gibt für die Konfiguration von .de-Zonen Empfehlungen, die sich auf die Werte der SOA-Zeitangaben beziehen. Hier sind die empfohlenen Werte sachlich aufgelistet:

1. Refresh (Empfohlen: 1 Stunde = 3600 Sekunden)
   • Sekundäre Nameserver prüfen jede Stunde, ob Änderungen beim primären Nameserver vorliegen.
   • Reduziert unnötige Anfragen an den Primärserver und verteilt die Last gleichmäßig über die Zeit.
   • Sorgt gleichzeitig dafür, dass Änderungen innerhalb eines überschaubaren Zeitrahmens übernommen werden.
2. Retry (Empfohlen: 15 Minuten = 900 Sekunden)
   • Nach einem fehlgeschlagenen Refresh wird nach 15 Minuten ein erneuter Versuch gestartet.
   • Falls der Primärserver vorübergehend nicht erreichbar ist, sorgt ein kurzes Retry-Intervall dafür, dass sekundäre Server schnell wieder eine Verbindung herstellen.
   • Verhindert, dass veraltete Daten zu lange verwendet werden.
3. Expire (Empfohlen: 1 Woche = 604800 Sekunden)
   • Sekundäre Nameserver verwenden die Zonendaten bis zu einer Woche weiter, falls keine Verbindung zum primären Nameserver möglich ist.
   • Sekundäre Nameserver verwenden die Zone nur für eine begrenzte Zeit ohne erfolgreiche Aktualisierung.
   • Garantiert, dass veraltete oder fehlerhafte Zonendaten nicht unbegrenzt verbreitet werden.
4. Minimum TTL / Negative Caching (Empfohlen: 1 Stunde = 3600 Sekunden)
   • Time-to-Live für nicht existierende Einträge wird auf 1 Stunde gesetzt.
   • Antworten auf nicht vorhandene Einträge (NXDOMAIN) werden für eine Stunde zwischengespeichert.
   • Reduziert unnötige Abfragen an den Nameserver, ohne dass neue Einträge zu lange unentdeckt bleiben.

Zusammengefasst: 

Die Werte von DENIC balancieren Lastverteilung, DNS-Konsistenz und aktuelle Datenbereitstellung, um eine stabile und zuverlässige .de-Zone zu gewährleisten.

Interpretation des SOA

Wollen wir einmal diese Dig-Query interpretieren

~# dig @localhost SOA mycompany.com

; <<>> DiG 9.16.37-Debian <<>> @localhost SOA mycompany.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38190
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cbaf6884b625d4fc0100000069c7adfca38ca2e8c985bb58 (good)
;; QUESTION SECTION:
;mycompany.com.             IN      SOA

;; ANSWER SECTION:
mycompany.com.      1800    IN      SOA     ns1.mycompany.com. hostmaster.mycompany.com.mycompany.com. 2026032707 600 7200 604800 300

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sat Mar 28 11:31:24 CET 2026
;; MSG SIZE  rcvd: 176

Denn wir wollen verstehen wir an entscheidenden Informationen geliefert bekommen. In der ANSWER SECTION sehen wir alles Andere als unwichtige Zahlen, die durchaus Erklärungen darüber liefern, warum die Zone nicht im Internet veröffentlicht wird. 
Die relevanten Zahlenfelder bedeuten:

• 1800 → TTL (Time To Live) des SOA-Records
• 600 → Refresh
• 7200 → Retry
• 604800 → Expire
• 300 → Negative Caching TTL (Minimum / NXDOMAIN TTL)

Der Ablauf logisch betrachtet

1. Secondary lädt Zone erfolgreich (Zeitpunkt X)
2. Danach:
   • alle 600 s (Refresh) ein Versuch, die Änderungen zu prüfen.
3. Falls der Primary nicht erreichbar ist:
   • Erfolgt bei Fehlschlag ein erneuter Versuch nach 7200 s (Retry).
4. Wenn 7 Tage (604800 Sekunden) lang kein erfolgreicher Kontakt:
   • Die Zone gilt als veraltet (expired).
   • Infolgedessen wird nicht mehr ausgeliefert.

Damit erfolgt eine Veröffentlichung sofort nach erfolgreichem Zonentransfer. Das Expire ist nur eine Abschaltgrenze, aber kein Verzögerungswert!

Schlussfolgerung

• TTL / Refresh niedrig heißt schnelle Updates.
• Expire hoch (7 Tage) bedeutet lange Überlebenszeit bei Ausfall des Primaries.