SOA-Records: Grund­stein jeder Zo­nen­da­tei

Für jeden In­ter­net­nut­zer ist es selbst­ver­ständ­lich, dass er die URL einer Website in den Browser eingibt und so zur ge­wünsch­ten Homepage gelangt. Dass der Computer die Ver­bin­dung ei­gent­lich zu einer IP-Adresse aufbaut, merkt man nicht. Zu verdanken haben wir dies dem Domain Name System (DNS) und seiner Funktion der Na­mens­auf­lö­sung. Der Name einer Domain wird hierbei zur be­nö­tig­ten Zah­len­fol­ge aufgelöst. Damit das System funk­tio­niert, besitzen Name­ser­ver Zo­nen­da­tei­en. In diesen einfachen Text­da­tei­en befinden sich wiederum zahl­rei­che DNS-Records, die das DNS erst er­mög­li­chen.

Am be­kann­tes­ten sind si­cher­lich die A-Records, denn mit diesen Einträgen findet die ei­gent­li­che Na­mens­auf­lö­sung statt. Daneben gibt es z. B. PTR-Records, die Reverse DNS er­mög­li­chen, oder MX-Records, die sich mit der E-Mail-Kom­mu­ni­ka­ti­on befassen. Wofür sind aber SOA-Records gedacht?

Das DNS ist ein de­zen­tra­les, hier­ar­chi­sches System: Name­ser­ver liefern In­for­ma­tio­nen nicht zu jedem be­lie­bi­gen Server im Internet, sondern nur zu den­je­ni­gen, die sich in der zu­ge­wie­se­nen Zone befinden. Dafür führen die DNS-Server Zo­nen­da­tei­en: Dies sind einfache Text­da­tei­en, in denen alle DNS-Einträge der Zone auf­ge­lis­tet sind. Um die Zu­stän­dig­kei­ten zu klären, enthält jede Zo­nen­da­tei zwingend einen SOA-Record. SOA steht dabei für Start of Authority. Der Eintrag gibt also u. a. Auskunft darüber, ob der an­ge­spro­che­ne Server für die Anfrage überhaupt zuständig ist.

Be­son­de­res Gewicht enthält der SOA-Record im Kontext eines Server-Clusters. Statt die komplette Last aller Anfragen selbst zu schultern, werden die Anfragen auf ver­schie­de­ne Geräte verteilt. Damit die Zo­nen­da­tei­en auf allen Servern aktuell sind, muss re­gel­mä­ßig ein Zo­nen­trans­fer durch­ge­führt werden. Die so­ge­nann­ten Slaves (also hier­ar­chisch tiefer liegende Server) gleichen dafür ihre Dateien mit der des Masters ab. Wie der Zo­nen­trans­fer statt­fin­den soll, wird über den SOA-Record geregelt. Dafür enthält ein solcher DNS-Eintrag ver­schie­de­ne In­for­ma­tio­nen.

DNS-Records bestehen grund­sätz­lich aus mehreren Feldern. In diesen befinden sich alle re­le­van­ten In­for­ma­tio­nen. Der SOA-Record hat im Vergleich zu anderen sehr viele Felder:

• <name>: Name der Zone
• <class>: Netz­werk­klas­se
• <type>: Typ des Eintrags
• <mname>: Name des Masters
• <rname>: E-Mail-Adresse des zu­stän­di­gen Ad­mi­nis­tra­tors
• <serial>: in­kre­men­tel­le Se­ri­en­num­mer, die die Version der Zo­nen­da­tei angibt
• <refresh>: Zeit­an­ga­be, wann ein Slave die aktuelle Version des Masters anfordern muss
• <retry>: Zeit­an­ga­be, wann ein Slave einen ge­schei­ter­ten An­fra­ge­ver­such nochmals durch­füh­ren soll
• <expire>: Zeit­an­ga­be, ab wann ein Slave bei aus­blei­ben­der Rück­mel­dung des Masters keine DNS-In­for­ma­tio­nen mehr her­aus­gibt
• <minimum>: Zeit­an­ga­be, wie lange die In­for­ma­ti­on 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 hier­ar­chi­sche Struktur der Domain dar, an deren Ende das Root-Ver­zeich­nis steht. Dieses ist al­ler­dings 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 his­to­ri­sche Relevanz und wird daher in vielen Fällen einfach weg­ge­las­sen. Bei der Ent­wick­lung des DNS gab es neben dem Internet noch die beiden Projekte Hesiod (HS) und Chaos (CH). Beide sind in­zwi­schen obsolet, weshalb nur noch das Internet mit dem Kürzel IN an dieser Stelle ein­ge­setzt werden kann. Der Typ bezieht sich auf die Art des ver­wen­de­ten 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 Name­ser­ver sich der tie­fer­ge­stell­te Server um einen Zo­nen­trans­fer bemühen muss. Bei der For­ma­tie­rung der E-Mail-Adresse im RNAME-Feld gibt es Be­son­der­hei­ten zu beachten. Ein @-Zeichen ist in der Notation nicht zu­ge­las­sen. Statt­des­sen trennt ein Punkt den Lokalteil (z. B. der Be­nut­zer­na­me) von der Domain. Sollte in der ori­gi­na­len E-Mail-Adresse vor dem @-Zeichen ein Punkt stehen, muss man diesen durch einen Backslash (\) kenn­zeich­nen.

Die Se­ri­en­num­mer muss sich mit jeder Änderung der Zo­nen­da­tei auch in­kre­men­tell erhöhen. Es haben sich zwei Varianten etabliert. Auf der einen Seite kann ein einfaches Verfahren bei 1 beginnen und mit jeder Änderung die Se­ri­en­num­mer um wiederum eins steigen lassen. Bei dieser Option lässt sich an der Se­ri­en­num­mer also auch ablesen, wie viele Än­de­run­gen es schon gegeben hat.

Die andere Mög­lich­keit ist, ein Da­tums­for­mat zu wählen: JJ­JJMMTTVV. Man beginnt mit einer vier­stel­li­gen Jah­res­an­ga­be, lässt dann Monat und Tag folgen (je zwei Stellen) und beendet die Angabe mit einer wiederum zwei­stel­li­gen Ver­si­ons­num­mer. In diesem Format erkennt man also, an welchem Datum die Version erstellt wurde. Mit jeder Änderung am gleichen Tag steigt die Ver­si­ons­num­mer um eins. An einem neuen Tag passt sich die Se­ri­en­num­mer an der ent­spre­chen­den Stelle an und die Ver­si­ons­num­mer wird wieder auf 00 gesetzt.

Der SOA-Record endet mit drei bis vier Zeit­an­ga­ben – jeweils in Sekunden. Das erste Feld („Refresh“) gibt den zeit­li­chen Abstand an, bis der Slave wieder beim Master nach einer aktuellen Version der Zo­nen­da­tei nachfragt. Sollte diese Anfrage nicht be­ant­wor­tet werden, regelt das Feld „Retry“, wann ein erneuter Versuch durch­ge­führt wird. Wichtig ist, dass diese Angabe kleiner als die vorherige ist.

Bekommt der hier­ar­chisch tiefere Server überhaupt keine Antwort mehr, legt die dritte Zeit­an­ga­be („Expire“) fest, wie lange die Zo­nen­da­tei noch benutzt werden darf, bevor der Server die Her­aus­ga­be von DNS-In­for­ma­tio­nen ver­wei­gert. Würde der Server weiter die Daten der alten Zo­nen­da­tei an an­fra­gen­de Clients senden, könnten jene schon nicht mehr gültig sein. Dies führt zu Ver­bin­dungs­pro­ble­men und Si­cher­heits­ri­si­ken.

Den Abschluss macht das Feld „Minimum“. Dieses ent­spricht der Time to live, wie man sie von anderen DNS-Record-Typen kennt. Sie gibt an, wie lang ein Client die an­ge­for­der­ten In­for­ma­tio­nen im Cache behalten darf, bevor eine erneute Anfrage gesendet werden muss. Meistens wird die TTL al­ler­dings 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 fest­ge­legt werden, dann mit der Anweisung $ORIGIN.

Der Eintrag erscheint immer zu Beginn der Zo­nen­da­tei.

Die Felder können einfach innerhalb einer Zeile nach­ein­an­der auf­ge­führt werden. Während dies bei anderen Ein­trags­ty­pen wenig komplex ist, ist der SOA-Record ver­gleichs­wei­se um­fang­reich. Um mehr Über­sicht­lich­keit zu schaffen, ordnet man die Felder meist ver­schach­telt und un­ter­ein­an­der an.

In dieser Schreib­wei­se werden TTL und Domain-Name im Vorfeld fest­ge­legt. Das @-Zeichen zu Beginn des Eintrags verweist auf die Origin-Anweisung. Um die Zeit­an­ga­ben zu ver­schach­teln und über mehrere Zeilen zu verteilen, setzt man runde Klammern ein.

Keine Zo­nen­da­tei ist gültig ohne einen SOA-Eintrag zu Anfang. In der Praxis sehen SOA-Records so aus:

In diesem bei­spiel­haf­ten Aus­schnitt einer Zo­nen­da­tei haben wir noch mehr In­for­ma­tio­nen als nur den SOA-Record ein­ge­tra­gen, um die Plat­zie­rung 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 fest­ge­legt haben, reicht hier das @-Zeichen als Verweis.

Der (fiktive) Master für die Zone folgt direkt auf die Angaben zu Netz­werk­klas­se und Ein­trags­typ. Danach steht die E-Mail-Adresse des Admins. Der Punkt wird durch den Backslash, in diesem Fall ein Mas­kie­rungs­zei­chen, er­mög­licht. Der nächste Punkt ersetzt dann das @-Zeichen der ei­gent­li­chen Adresse, der dar­auf­fol­gen­de grenzt wie üblich die Top-Level-Domain (TLD) ab. Mit einer Klammer eröffnet man den ver­schach­tel­ten Bereich, der dann auch auf mehrere Zeilen auf­ge­teilt werden kann. Es ist aber ebenso möglich, alle Werte hin­ter­ein­an­der zu schreiben und nur durch Leer­zei­chen von­ein­an­der zu trennen.

In diesem Beispiel haben wir hinter die einzelnen Werte ihre Be­stim­mung ge­schrie­ben. Dabei handelt es sich nur um Kom­men­ta­re, die selbst gewählt oder einfach weg­ge­las­sen werden können. Bei DNS-Einträgen markiert man solche Be­mer­kun­gen, die aus­schließ­lich für mensch­li­che Nutzer gedacht sind, durch ein Semikolon.

Am Ende des SOA-Records muss die Klammer ge­schlos­sen werden.

An­schlie­ßend haben wir noch einen NS- und einen A-Record in die bei­spiel­haf­te Zo­nen­da­tei eingefügt. Daran kann man erkennen, dass der SOA-Record vor allen anderen Einträgen stehen muss – aber eben nicht vor den An­wei­sun­gen zur Domain und zur TTL.

Die Anfrage ist unter „Question“ auf­ge­führt, das Ergebnis der Anfrage findet sich unter „Answer“. Im Data-Feld der Antwort erkennt man den Master-Server, die E-Mail-Adresse des Ver­ant­wort­li­chen und die zeit­li­chen Angaben. Auffällig hier: Der letzte Wert (Minimum) ent­spricht bis auf eine Sekunde der Angabe unter TTL. Diese Sekunde ist ver­mut­lich seit der Anfrage bereits vergangen, weshalb es zu der minimalen Dis­kre­panz kommt.

Eine Be­son­der­heit stellt die Angabe unter dem Punkt „type“ dar: Statt der Be­zeich­nung 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 in­di­vi­du­el­len Wert zu­ge­ord­net. Selbst Ein­trags­ar­ten, die nicht oder nicht mehr verwendet werden, besitzen eine Nummer. Dadurch ergibt sich eine nahezu lü­cken­lo­se Liste der ver­schie­de­nen Typen. In diesem System haben SOA-Records die Nummer 6.