SOA-Records: Grundstein jeder Zonendatei

Für jeden Internetnutzer ist es selbstverständlich, dass er die URL einer Website in den Browser eingibt und so zur gewünschten Homepage gelangt. Dass der Computer die Verbindung eigentlich zu einer IP-Adresse aufbaut, merkt man nicht. Zu verdanken haben wir dies dem Domain Name System (DNS) und seiner Funktion der Namensauflösung. Der Name einer Domain wird hierbei zur benötigten Zahlenfolge aufgelöst. Damit das System funktioniert, besitzen Nameserver Zonendateien. In diesen einfachen Textdateien befinden sich wiederum zahlreiche DNS-Records, die das DNS erst ermöglichen.

Am bekanntesten sind sicherlich die A-Records, denn mit diesen Einträgen findet die eigentliche Namensauflösung statt. Daneben gibt es z. B. PTR-Records, die Reverse DNS ermöglichen, oder MX-Records, die sich mit der E-Mail-Kommunikation befassen. Wofür sind aber SOA-Records gedacht?

Das DNS ist ein dezentrales, hierarchisches System: Nameserver liefern Informationen nicht zu jedem beliebigen Server im Internet, sondern nur zu denjenigen, die sich in der zugewiesenen Zone befinden. Dafür führen die DNS-Server Zonendateien: Dies sind einfache Textdateien, in denen alle DNS-Einträge der Zone aufgelistet sind. Um die Zuständigkeiten zu klären, enthält jede Zonendatei zwingend einen SOA-Record. SOA steht dabei für Start of Authority. Der Eintrag gibt also u. a. Auskunft darüber, ob der angesprochene Server für die Anfrage überhaupt zuständig ist.

Besonderes Gewicht enthält der SOA-Record im Kontext eines Server-Clusters. Statt die komplette Last aller Anfragen selbst zu schultern, werden die Anfragen auf verschiedene Geräte verteilt. Damit die Zonendateien auf allen Servern aktuell sind, muss regelmäßig ein Zonentransfer durchgeführt werden. Die sogenannten Slaves (also hierarchisch tiefer liegende Server) gleichen dafür ihre Dateien mit der des Masters ab. Wie der Zonentransfer stattfinden soll, wird über den SOA-Record geregelt. Dafür enthält ein solcher DNS-Eintrag verschiedene Informationen.

DNS-Records bestehen grundsätzlich aus mehreren Feldern. In diesen befinden sich alle relevanten Informationen. Der SOA-Record hat im Vergleich zu anderen sehr viele Felder:

• <name>: Name der Zone
• <class>: Netzwerkklasse
• <type>: Typ des Eintrags
• <mname>: Name des Masters
• <rname>: E-Mail-Adresse des zuständigen Administrators
• <serial>: inkrementelle Seriennummer, die die Version der Zonendatei angibt
• <refresh>: Zeitangabe, wann ein Slave die aktuelle Version des Masters anfordern muss
• <retry>: Zeitangabe, wann ein Slave einen gescheiterten Anfrageversuch nochmals durchführen soll
• <expire>: Zeitangabe, ab wann ein Slave bei ausbleibender Rückmeldung des Masters keine DNS-Informationen mehr herausgibt
• <minimum>: Zeitangabe, wie lange die Information in einem Cache gehalten werden darf

Die ersten drei Felder sind typisch für DNS-Records. Der Name der Zone ist ein Domain-Name in der Form eines Fully Qualified Domain Names (FQDN). Dies bedeutet, dass man die Angabe – anders als man es von einer URL kennt – mit einem Punkt beendet. Grund dafür: Ein FQDN stellt die komplette hierarchische Struktur der Domain dar, an deren Ende das Root-Verzeichnis steht. Dieses ist allerdings leer, weshalb nur der trennende Punkt übrig bleibt. Diese Notation findet man in allen Domain-Namen im DNS, also auch bei den Feldern MNAME und RNAME.

Das Feld bezüglich der Klasse hat nur noch historische Relevanz und wird daher in vielen Fällen einfach weggelassen. Bei der Entwicklung des DNS gab es neben dem Internet noch die beiden Projekte Hesiod (HS) und Chaos (CH). Beide sind inzwischen obsolet, weshalb nur noch das Internet mit dem Kürzel IN an dieser Stelle eingesetzt werden kann. Der Typ bezieht sich auf die Art des verwendeten DNS-Eintrags, in diesem Fall also SOA.

MNAME ist auch als Primary Master bekannt und gibt an, welcher Server über dem Slave steht. Damit ist definiert, bei welchem Nameserver sich der tiefergestellte Server um einen Zonentransfer bemühen muss. Bei der Formatierung der E-Mail-Adresse im RNAME-Feld gibt es Besonderheiten zu beachten. Ein @-Zeichen ist in der Notation nicht zugelassen. Stattdessen trennt ein Punkt den Lokalteil (z. B. der Benutzername) von der Domain. Sollte in der originalen E-Mail-Adresse vor dem @-Zeichen ein Punkt stehen, muss man diesen durch einen Backslash (\) kennzeichnen.

Die Seriennummer muss sich mit jeder Änderung der Zonendatei auch inkrementell erhöhen. Es haben sich zwei Varianten etabliert. Auf der einen Seite kann ein einfaches Verfahren bei 1 beginnen und mit jeder Änderung die Seriennummer um wiederum eins steigen lassen. Bei dieser Option lässt sich an der Seriennummer also auch ablesen, wie viele Änderungen es schon gegeben hat.

Die andere Möglichkeit ist, ein Datumsformat zu wählen: JJJJMMTTVV. Man beginnt mit einer vierstelligen Jahresangabe, lässt dann Monat und Tag folgen (je zwei Stellen) und beendet die Angabe mit einer wiederum zweistelligen Versionsnummer. In diesem Format erkennt man also, an welchem Datum die Version erstellt wurde. Mit jeder Änderung am gleichen Tag steigt die Versionsnummer um eins. An einem neuen Tag passt sich die Seriennummer an der entsprechenden Stelle an und die Versionsnummer wird wieder auf 00 gesetzt.

Der SOA-Record endet mit drei bis vier Zeitangaben – jeweils in Sekunden. Das erste Feld („Refresh“) gibt den zeitlichen Abstand an, bis der Slave wieder beim Master nach einer aktuellen Version der Zonendatei nachfragt. Sollte diese Anfrage nicht beantwortet werden, regelt das Feld „Retry“, wann ein erneuter Versuch durchgeführt wird. Wichtig ist, dass diese Angabe kleiner als die vorherige ist.

Bekommt der hierarchisch tiefere Server überhaupt keine Antwort mehr, legt die dritte Zeitangabe („Expire“) fest, wie lange die Zonendatei noch benutzt werden darf, bevor der Server die Herausgabe von DNS-Informationen verweigert. Würde der Server weiter die Daten der alten Zonendatei an anfragende Clients senden, könnten jene schon nicht mehr gültig sein. Dies führt zu Verbindungsproblemen und Sicherheitsrisiken.

Den Abschluss macht das Feld „Minimum“. Dieses entspricht der Time to live, wie man sie von anderen DNS-Record-Typen kennt. Sie gibt an, wie lang ein Client die angeforderten Informationen im Cache behalten darf, bevor eine erneute Anfrage gesendet werden muss. Meistens wird die TTL allerdings für die komplette Zone mit der Anweisung $TTL gesetzt. In den einzelnen Einträgen muss diese dann nicht mehr vorkommen. Der Zonenname kann ebenfalls bereits am Anfang der Datei festgelegt werden, dann mit der Anweisung $ORIGIN.

Der Eintrag erscheint immer zu Beginn der Zonendatei.

Die Felder können einfach innerhalb einer Zeile nacheinander aufgeführt werden. Während dies bei anderen Eintragstypen wenig komplex ist, ist der SOA-Record vergleichsweise umfangreich. Um mehr Übersichtlichkeit zu schaffen, ordnet man die Felder meist verschachtelt und untereinander an.

In dieser Schreibweise werden TTL und Domain-Name im Vorfeld festgelegt. Das @-Zeichen zu Beginn des Eintrags verweist auf die Origin-Anweisung. Um die Zeitangaben zu verschachteln und über mehrere Zeilen zu verteilen, setzt man runde Klammern ein.

Keine Zonendatei ist gültig ohne einen SOA-Eintrag zu Anfang. In der Praxis sehen SOA-Records so aus:

In diesem beispielhaften Ausschnitt einer Zonendatei haben wir noch mehr Informationen als nur den SOA-Record eingetragen, um die Platzierung etwas klarer zu machen. Die Datei beginnt mit den Angaben zum Domain-Namen (in diesem Fall example.org) und der TTL. Dann folgt der SOA-Record. Da wir die Zone bereits in der $ORIGIN-Anweisung festgelegt haben, reicht hier das @-Zeichen als Verweis.

Der (fiktive) Master für die Zone folgt direkt auf die Angaben zu Netzwerkklasse und Eintragstyp. Danach steht die E-Mail-Adresse des Admins. Der Punkt wird durch den Backslash, in diesem Fall ein Maskierungszeichen, ermöglicht. Der nächste Punkt ersetzt dann das @-Zeichen der eigentlichen Adresse, der darauffolgende grenzt wie üblich die Top-Level-Domain (TLD) ab. Mit einer Klammer eröffnet man den verschachtelten Bereich, der dann auch auf mehrere Zeilen aufgeteilt werden kann. Es ist aber ebenso möglich, alle Werte hintereinander zu schreiben und nur durch Leerzeichen voneinander zu trennen.

In diesem Beispiel haben wir hinter die einzelnen Werte ihre Bestimmung geschrieben. Dabei handelt es sich nur um Kommentare, die selbst gewählt oder einfach weggelassen werden können. Bei DNS-Einträgen markiert man solche Bemerkungen, die ausschließlich für menschliche Nutzer gedacht sind, durch ein Semikolon.

Am Ende des SOA-Records muss die Klammer geschlossen werden.

Anschließend haben wir noch einen NS- und einen A-Record in die beispielhafte Zonendatei eingefügt. Daran kann man erkennen, dass der SOA-Record vor allen anderen Einträgen stehen muss – aber eben nicht vor den Anweisungen zur Domain und zur TTL.

Die Anfrage ist unter „Question“ aufgeführt, das Ergebnis der Anfrage findet sich unter „Answer“. Im Data-Feld der Antwort erkennt man den Master-Server, die E-Mail-Adresse des Verantwortlichen und die zeitlichen Angaben. Auffällig hier: Der letzte Wert (Minimum) entspricht bis auf eine Sekunde der Angabe unter TTL. Diese Sekunde ist vermutlich seit der Anfrage bereits vergangen, weshalb es zu der minimalen Diskrepanz kommt.

Eine Besonderheit stellt die Angabe unter dem Punkt „type“ dar: Statt der Bezeichnung SOA findet man sowohl in der Anfrage als auch in der Antwort die Zahl 6. Die Internet Assigned Numbers Authority (IANA) hat jedem DNS-Record-Typen einen individuellen Wert zugeordnet. Selbst Eintragsarten, die nicht oder nicht mehr verwendet werden, besitzen eine Nummer. Dadurch ergibt sich eine nahezu lückenlose Liste der verschiedenen Typen. In diesem System haben SOA-Records die Nummer 6.