Ein SOA-Eintrag beschreibt die Autorität einer DNS-Zone. Er gibt den primären autoritativen Server und die Kontaktadresse an. Er liefert eine Seriennummer sowie Zeitwerte für die Synchronisation der sekundären Server.
Ein SOA-Eintrag enthält einen Namen, einen Typ, einen primären Server, einen Kontakt, eine Seriennummer und fünf Zeitangaben. Die TTL gibt an, wie lange die Antwort im lokalen Resolver zwischengespeichert bleibt.
| Name | Typ | Primärer Server MNAME | Kontakt RNAME | Serial | Refresh | Retry | Expire | Minimum TTL | TTL in Sekunden |
|---|
| @ | SOA | ns1.beispiel.net. | hostmaster.beispiel.com. | 2025090301 | 7200 | 900 | 1209600 | 3600 | 3600 |
In diesem Beispiel zielt der Name @ auf den Zonen-Apex. Der primäre Server muss in A oder AAAA auflösbar sein. Der Kontakt wird wie eine E-Mail-Adresse geschrieben, mit einem Punkt anstelle des @-Zeichens. Zum Beispiel entspricht hostmaster.beispiel.com der Adresse hostmaster@beispiel.com. Die Seriennummer steigt mit jeder Änderung der Zone. Die Werte für Refresh, Retry, Expire und Minimum TTL sind in Sekunden angegeben.
Der primäre Server MNAME bezeichnet den Referenz-Host für die Zone.
Der Kontakt RNAME empfängt Nachrichten bezüglich der Zone.
Die Seriennummer ermöglicht es den Sekundären zu erkennen, ob eine neuere Version existiert.
Refresh gibt an, wann ein Sekundärer den Primären überprüft.
Retry gibt die Wartezeit zwischen zwei Versuchen nach einem Fehler an.
Expire gibt an, nach wie langer Zeit ein Sekundärer eine Zone aufgibt, die nicht mehr aktualisiert werden kann.
Minimum TTL dient dem negativen Caching. Es legt die Dauer fest, während der eine fehlende Antwort zwischengespeichert bleibt. Die Standard-TTL der Einträge wird anderswo in der Zone festgelegt.
Wissenswertes
Es gibt nur einen SOA pro Zone. Er wird am Apex neben den NS-Einträgen veröffentlicht. Das Minimum TTL-Feld definiert nicht die Standard-TTL anderer Einträge. Es dient dem negativen Caching.
Die TTL des SOA kontrolliert die Cache-Dauer der SOA-Antwort auf Resolver-Seite. Eine zu lange TTL kann die Berücksichtigung einer Seriennummer-Änderung verzögern. Eine angemessene TTL verbessert die Reaktionsfähigkeit, ohne die autoritativen Server zu überlasten.
Am Zonen-Apex. Immer. Delegierte Subdomains besitzen ihren eigenen SOA in ihrer dedizierten Zone. Ein CNAME darf nicht am Apex erscheinen, da die Zone bereits SOA und NS veröffentlichen muss.
Zu vermeiden
Vergessen, die Seriennummer nach einer Zonenänderung zu erhöhen.
Einen primären Server setzen, der nicht in A oder AAAA auflöst.
Refresh und Retry vertauschen.
Ein zu kurzes Expire verwenden, das die Zone bei den Sekundären zum Verschwinden bringt.
Eine Online-DNS-Lookup ermöglicht es, einen Domainnamen einzugeben. Das Ergebnis zeigt den SOA, wie er vom Internet aus gesehen wird. Man kann den primären Server, den Kontakt, die Seriennummer und die Zeitwerte ablesen. Anschließend einen lokalen Test vom eigenen Rechner durchführen.
Windows stellt nslookup zur Verfügung. Man kann es im interaktiven Modus verwenden.
nslookup
set q=soa
beispiel.com
nslookup
set q=soa
server 1.1.1.1
beispiel.com
Der erste Teil fragt gemäß der Netzwerkkonfiguration des Rechners ab. Der zweite erzwingt die Verwendung eines Drittanbieter-Resolvers, hier den von Cloudflare.
Auf diesen Systemen ist der dig-Befehl praktisch und einfach zu verwenden.
dig SOA beispiel.com
dig SOA beispiel.com @1.1.1.1
Eine ältere Seriennummer auf einem sekundären Server deutet auf eine Übertragungsverzögerung hin.
Ein sehr langes Refresh verzögert die Verbreitung von Änderungen.
Ein zu kurzes Expire kann dazu führen, dass ein Sekundärer die Zone aufgibt.
Ein falsch formatierter Kontakt verhindert den Empfang nützlicher Nachrichten.
- Die Zonenaktualisierung vorbereiten.
- Die Seriennummer erhöhen.
- Die Zone auf dem primären Server neu laden.
- Die Sekundären sich aktualisieren lassen oder eine Übertragung auslösen, wenn das Tool es erlaubt.
- Die neue Seriennummer von mehreren Netzwerken aus überprüfen, dann validieren.
Praktischer Tipp
Ein vorhersagbares Seriennummern-Format verwenden. Ein Datumsformat gefolgt von einem Zähler erleichtert die Verfolgung. Zum Beispiel 2025090301 für die erste Änderung des Tages.
Die Zone beim neuen Service einrichten. SOA und NS überprüfen. Die Delegation umstellen, wenn alles bereit ist.
Zonentransfer auf dem Primären erlauben. Überprüfen, dass der Sekundäre die Zone ordnungsgemäß abruft und die richtige Seriennummer anzeigt.
RNAME aktualisieren. Testen, dass die Nachrichten beim richtigen Empfänger ankommen.
- Wenn sich der SOA je nach autoritativen Servern unterscheidet, einen Refresh-Zyklus abwarten, dann erneut überprüfen.
- Wenn ein Sekundärer bei einer alten Seriennummer hängen bleibt, Netzwerkzugang und Zonentransfer-Rechte überprüfen.
- Wenn die Zone bei einem Sekundären verschwindet, Expire erhöhen und die Gesundheit des Primären überprüfen.
- Wenn die Antwort trotz Aktualisierung alt bleibt, auf TTL-Ablauf warten und den Cache des lokalen Resolvers wenn möglich leeren.
Zusammenfassend definiert ein SOA-Eintrag die Autorität einer Zone. Er gibt den primären Server, den Kontakt, die Seriennummer und die Zeitwerte an, die die Synchronisation regeln. Nur ein SOA am Apex. Konsistente Werte gewährleisten eine zuverlässige Verbreitung. Die Überprüfung erfolgt über ein Online-Tool, dann über nslookup und dig.
Mit diesen Anhaltspunkten bleibt die Verwaltung klar. Änderungen verlaufen stressfrei. DNS-Dienste antworten wie erwartet.