Zonentransfer bezeichnet beim Domain Name System (DNS) die Übertragung von Zonen auf einen anderen Server. Dieses Verfahren wird AXFR (Asynchronous Full Transfer Zone oder Asynchronous Xfer Full Range) abgekürzt. 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 (siehe auch: Hidden Primary) 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 Top-Level-Domains (z. B. de.) ist es sogar Vorschrift, Zonendateien für die Second Level Domains 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 dynamisches Update aus einer Datenbank erfolgen. Eine Ausnahme bildet hier der DNS-Server von Microsoft. Bei diesem können in einer Active-Directory-integrierten Zone sowohl in der Primary als auch in der Secondary Zone Daten eingetragen werden.
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 sekundäre Server dient. Diese Schachtelung von sekundären Servern wird häufig verwendet, um die Belastung des primären Servers durch den Zonentransfer zu vermindern.
Dieses Verfahren wurde in der ursprünglichen DNS-Spezifikation eingeführt und erstmals mit dem DNS-Server BIND genutzt. Neben AXFR gibt es noch das neuere IXFR (RFC 1995[1]), das lediglich geänderte Records überträgt und nicht die gesamte Zone. Für die Synchronisation zwischen Master und Slave existieren zwei Methoden:
Notify-Verfahren
BearbeitenDer 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 Informationen, 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
BearbeitenDer 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
BearbeitenDurch einen geheimen Schlüssel (bei BIND rndc-key genannt) vergewissern sich die Server, dass sie wirklich mit ihrem Master/Slave verkehren.