SOA Resource Record

SOA bedeutet Start of Authority (dt. Beginn der Zuständigkeit) und ist wichtiger Bestandteil einer Zonendatei im Domain Name System (DNS). Ein SOA-Record enthält wichtige Angaben zur Verwaltung der Zone, insbesondere zum Zonentransfer. Die SOA ist üblicherweise der Registrar. Spezifiziert ist der SOA-Typ in RFC 1035.

Hintergrund

Ü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.

Aufbau

NAME

Name der Zone

TYPE

SOA, Kürzel für Start Of Authority

CLASS

Zonenklasse (meist IN für Internet)

TTL

gibt in Sekunden an, wie lange dieser Resource Record in einem Cache gültig sein darf

MNAME

Primary Master für diese Zone:

• er definiert, an wen dynamische Updates gesendet werden sollen (siehe: Dynamisches Update)
• er gibt an, an wen keine Notifies gesendet werden (siehe: Zonentransfer)

RNAME

Mail-Adresse des Verantwortlichen für diese Zone. (Das @ wird durch . ersetzt. Punkte vor dem @ werden durch \. ersetzt; beispielsweise max\.mustermann.wikipedia.org für die E-Mail-Adresse max.mustermann@wikipedia.org)

SERIAL

Seriennummer, die bei jeder Änderung inkrementiert wird (vorzugsweise JJJJMMTTVV; dient als Hinweis, wann die Zone zuletzt aktualisiert wurde)

REFRESH

Sekundenabstand, in dem sekundäre Nameserver die Seriennummer vom primären Master abfragen sollen, um Änderungen der Zone festzustellen. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 86400 ≙ 24 Stunden.

RETRY

Sekundenabstand, in dem, bei ausbleibender Antwort des Masters, sekundäre Nameserver nochmals seine Seriennummer abfragen sollen. Dieser Wert muss kleiner als jener zum Refresh sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 7200 ≙ 2 Stunden.

EXPIRE

Sekundenabstand, nach dem bei ausbleibender Antwort des Masters sekundäre Nameserver keine Antworten über die Zone mehr geben sollen. Dieser Wert muss größer als die Summe jener zum Refresh und Retry sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 3600000 ≙ 1000 Stunden.

MINIMUM

Time to Live für Negatives Caching (Empfehlung vom RIPE NCC für kleine und stabile Zonen: 3600 ≙ 1 Stunde). Ursprünglich hatte dieses Feld die Bedeutung eines Minimum-TTL-Werts für alle Resource Records der Zone und wurde in der Praxis als Standardwert verwendet, wenn bei einem Resource Record kein TTL-Wert angegeben war; diese Bedeutung wurde mit RFC 2308 abgeschafft.

Beispiel eines SOA-Records in BIND

Siehe auch: BIND

@   3600 IN SOA master.example.com. hostmaster.example.com. (
    2014031700 ; serial
    3600       ; refresh
    1800       ; retry
    604800     ; expire
    600 )      ; negatives caching, ehem. minimum

In diesem Beispiel wird festgelegt, dass sich ein Slave alle 3600 Sekunden mit seinem Master per Zonentransfer synchronisiert. Ist sein Master nicht erreichbar, wird alle 1800 Sekunden ein neuer Versuch gestartet. Kann der Master innerhalb von 604800 Sekunden (einer Woche) nicht kontaktiert werden, so erklärt der Slave die Zone example.com als inaktiv und beantwortet keine diesbezüglichen DNS-Requests mehr. DNS cached auch fehlgeschlagene Request. Die TTL dafür beträgt 600 Sekunden.

Weiterhin wird definiert, dass der Primary Master dieser Zone master.example.com ist und dass der Administrator über die E-Mail-Adresse hostmaster@example.com erreichbar ist. Das @ muss durch einen . ersetzt werden. Kommt ein . vor dem @, z. B. vorname.nachname@example.com, so wird dieser mit einem \ maskiert – also z. B. vorname\.nachname.example.com.

Die Seriennummer beträgt zur Zeit 2014031700. Bei der nächsten Änderung muss sie (manuell) auf mindestens 2014031701 erhöht werden. Dabei hat sich die Konvention eingebürgert, das Datum in der Form Jahr-Monat-Tag sowie einen nachfolgenden zweistelligen Versionszähler als Seriennummer zu verwenden.

Änderung der Seriennummer

Beim Ändern der Seriennummern haben sich drei Verfahren etabliert:

• Beginn bei 1 und Erhöhung bei jeder Änderung.
• Eintragung des aktuellen Datums mit einem zweistelligen Zähler (zum Beispiel 2004052101 = 21. Mai 2004, erste Änderung an diesem Tag), seltener auch der Uhrzeit ein. Dieses Vorgehen wird in RFC 1912 2.2 empfohlen.
• Eintragung des Änderungszeitpunkts als Unixzeit (Anzahl der Sekunden seit 1. Januar 1970 00:00:00 UTC). djbdns verwendet dieses Verfahren automatisch, wenn das Feld Seriennummer leer gelassen wird.