EGILIA Germany - EGILIA Germany : IT und Management Kurse

Bsp.: ccna, pmp, prince2, lpic, php, itil, ccnp, java, togaf
>

Dossier

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




 

Entdecken Sie hier all unsere Artikel, die unser EGILIA Team für Sie vorbereitet hat. Sie können ebenfalls unsere EGILIA Artikel als RSS-Feed kostenlos empfangen.
Microsoft Certified Partner Citrix Alliance Partner Sun Parner Advantage Novell HP Business Partner Cisco Partner - Premier Certified
EGILIA Germany GmbH Goethestraße 13, 90409 Nürnberg, ist eine Tochtergesellschaft der EGILIA Group
© copyright 2013  Ver:3.0
ITIL® is a registered trade mark of the Cabinet Office.
PRINCE2® is a registered trade mark of the Cabinet Office.
The ITIL Approved Examination Organization logo is a trade mark of the Cabinet Office
The Swirl logo™ is a trade mark of the Cabinet Office and/or the ITIL Accredited Training Organization logo is a trade mark of the Cabinet Office
The Swirl logo™ is a trade mark of the Cabinet Office and/or the PRINCE2 Licensed Affiliate logo is a trade mark of the Cabinet Office
Die von EGILIA Germany GmbH angebotenen Dienstleistungen richten sich ausschließlich an Industrie, Handwerk, Handel und die freien Berufe sowie an Vereine und öffentliche Einrichtungen.
EGILIA ist in: Berlin Hamburg München Stuttgart Nürnberg