DNS-Zonentransfer

Zonentransfer bezeichnet den Vorgang der Übertragung von Domain Name System (DNS)-Zonen auf einen anderen Server.

Da ein DNS-Ausfall für ein Unternehmen meist gravierende Folgen hat, werden die DNS-Daten - also die Zonendateien - fast ausnahmslos identisch auf mehreren Nameservern gehalten. Bei Änderungen muss sichergestellt sein, dass alle Server den gleichen Datenbestand besitzen. Die Synchronisation zwischen den beteiligten Servern wird durch den Zonentransfer realisiert. Der Zonentransfer beinhaltet nicht nur das bloße Übertragen von Dateien oder Sätzen, sondern auch das Erkennen von Abweichungen in den Datenbeständen der beteiligten Server.

Die originären Daten einer Zone liegen auf einem DNS-Server, der als Primary Nameserver (kurz: Primary) für diese Zone bezeichnet wird. Zur Erhöhung der Ausfallsicherheit, Realisierung einer einfachen Lastverteilung oder um den Primary vor Angriffen zu schützen, werden in der Praxis in fast allen Fällen ein oder mehrere zusätzliche Server installiert, die als Secondary Nameserver (kurz: Secondary) für diese Zone bezeichnet werden. Bei einigen Topleveldomains (z. B. .de) ist es sogar Vorschrift, Zonendateien für die Secondleveldomains auf mindestens zwei Servern zugänglich zu machen.

Ein DNS-Server kann nicht pauschal als Primary oder Secondary bezeichnet werden. Diese Funktion ist stets in Bezug auf eine Zone zu betrachten. So kann ein DNS-Server Primary für eine Zone und Secondary für eine andere Zone sein.

Die DNS-Informationen eines Primary und eines Secondary werden als qualitativ gleichwertig angesehen. Sowohl Primary als auch Secondary sind autoritativ für eine Zone, d. h. ihren Daten kann unbedingt vertraut werden (im Gegensatz dazu werden beispielsweise Daten aus DNS-Caches als nicht-autoritativ angesehen, da sie veraltet sein können).

DNS-Einträge werden grundsätzlich nur auf dem Primary erzeugt, geändert oder gelöscht. Das kann durch manuelles Editieren der betreffenden Zonendatei oder automatisch durch ein dynamisches Update aus einer Datenbank erfolgen.

Ein DNS-Server, der als direkte Quelle für die Synchronisation einer Zonendatei dient, wird als Master bezeichnet. Einen DNS-Server, der die Zonendaten von einem Master bezieht, nennt man Slave. Ein Primary ist stets Master, während ein Secondary sowohl Slave als auch Master sein kann. Er ist Slave, falls er die Zonendaten von einem Master bezieht; er ist Master, falls er selbst als Quelle für weitere Secondaries dient. Diese Schachtelung von Secondaries wird häufig verwendet, um die Belastung des Primarys durch den Zonentransfer zu vermindern.

Für die Synchronisation zwischen Master und Slave existieren zwei Methoden:

Notify-Verfahren

Der Master benachrichtigt alle Slaves einer Zone, sobald sich in der Zone etwas geändert hat. Der Slave fordert dann entweder die komplette Zone an oder – besser – per inkrementellen Zonentransfer nur die geänderten Resource Records. Die Information, wer Slave ist, wird indirekt aus den NS Resource Records einer Zone abgeleitet. Der Master ist im SOA Resource Record aufgeführt. Alle anderen in NS-RRs aufgeführten Server gelten automatisch als Slave.

Slave-Hol-Verfahren

Der Slave holt in bestimmten Abständen (der so genannten Refresh Time, die typischerweise eine Stunde beträgt) den SOA Resource Record der betreffenden Zone vom Master und vergleicht die Seriennummern. Ist die Seriennummer des SOA-RRs des Masters größer als die des Slaves, stimmen die Datenbestände nicht mehr überein. Der Slave fordert dann entweder die komplette Zone an oder – besser – per inkrementellen Zonentransfer nur die geänderten Resource Records. Die maßgeblichen Parameter (z. B. Seriennummer und Refresh-Timer) befinden sich im SOA-RR. Der Master legt diese Werte fest und zwingt sie den Slaves auf.

Das Notify-Verfahren ist dem Slave-Hol-Verfahren deutlich überlegen, da Änderungen schneller zu den Slaves übermittelt werden. Es ist heute Standard. Zum Zonentransfer wird grundsätzlich TCP verwendet und nicht, wie bei DNS-Requests, UDP.

Sicherheit

Durch einen geheimen Schlüssel (bei Bind 'rndc-key' genannt) vergewissern sich die Server, dass sie wirklich mit ihrem Master/Slave verkehren.

Verzeichnisse und Dateien zur Einrichtung eines BIND

Die Datei /etc/named.conf (Bei Debian-Distributionen existieren 3 weitere Dateien, die in der named.conf eingetragen sind) ist die Konfigurationsdatei des Servers. Hier definieren Sie die Art des Servers, die Zonen Dateien und Protokollierungsoptionen.



Beispiel:

options {

    directory "/var/lib/named";

    forwarders { 8.8.8.8; 192.168.0.1; };

    listen-on port 53 { 127.0.0.1; 192.168.0.103; };

    allow-query { 127.0.0.1; 192.168.0.0/24; };

    allow-transfer { 192.168.0.104; };

    notify yes;

};

zone "." in {

    type hint;

    file "root.hint";

};

zone "localhost" in {

    type master;

    file "localhost.zone";

};

zone "site" in {

    type master;

    file "site.zone";

    allow-transfer { 192.168.0.104; };

};

zone "0.0.127.in-addr.arpa" in {

    type master;

    file "127.0.0.zone";

};

include "/etc/named.conf.include";

Eine Zonendatei enthält immer einen SOA und einen NS Eintrag. Sie sollten auch definieren, welche Zeiten für die Records gelten und welche Zeiten und Seriennummer für die SOA gelten.



Beispiel:

$TTL 2D    #Globale TTL der RRs

site.    IN SOA     susi1.site post.susi1.site (    1235 ; serial

        1D ; refresh

        2H ; retry

        1W ; expiry

        2H ) ; negative TTL

    IN NS    susi1.site



susi1    IN A    192.168.0.103

test1    IN A    192.168.0.250