Zum Inhalt springen

BIND/Slave: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
DanielZorin (Diskussion | Beiträge)
Bürokraten, Page Ownership admin
713 Bearbeitungen
Keine Bearbeitungszusammenfassung
 
(39 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
== BIND - Slave-Server ==
'''BIND/Slave''' - Konfiguration eines [[DNS]]-Servers
=== Einleitung ===
Ein Nameserver, auf dem BIND läuft, kann so konfiguriert werden, dass er jede Zone entweder als Master oder als Slave bedient:
* Ein Slave erhält seine Kopie der Zonendaten durch eine Zonenübertragung von einem anderen Nameserver.
* Ein Master bezieht die Zonendaten aus einer anderen Quelle, sodass er unabhängig von anderen Nameservern arbeiten kann.


Jede Zone sollte mindestens zwei Nameserver haben. In der Regel gibt es einen Master und einen oder zwei Slaves, die ihre Zonendaten von diesem Master beziehen.
== Einleitung ==
Ein Nameserver mit BIND kann so konfiguriert werden, dass jede Zone entweder als Master- oder als Slave-Zone bereitgestellt wird
* Ein Slave erhält seine Kopie der Zonendaten per Zonenübertragung von einem anderen Nameserver
* Ein Master bezieht die Zonendaten aus einer unabhängigen Quelle und ist daher nicht auf andere Nameserver angewiesen


==== Szenario ====
Für jede Zone wird der Betrieb von mindestens zwei Nameservern empfohlen
* Angenommen, die Zone <tt>example.com</tt> hat zwei Nameserver, <tt>ns0.example.com</tt> (198.51.100.1) und <tt>ns1.example.com</tt> (203.0.113.1).
* Typischerweise existiert ein Master sowie ein oder zwei Slaves, die ihre Zonendaten vom Master übernehmen
* Von diesen ist <tt>ns0</tt> bereits als Master konfiguriert. Sie möchten <tt>ns1</tt> als Slave konfigurieren, der seine Zonendaten von <tt>ns0</tt> bezieht.
* Auf beiden Nameservern läuft BIND Version 9.


==== Dateispeicherorte ====
=== Szenario ===
Auf Debian-basierten Systemen sollten Zonendeklarationen in der Datei <tt>/etc/bind/named.conf.local</tt> und Optionen in der Datei <tt>/etc/bind/named.conf.options</tt> abgelegt werden.
{| class="wikitable options big"
|-
! !! Name !! Beschreibung
|-
| Zone || example.com || mit zwei Nameservern
|-
| Master || master.example.com || 192.168.0.100
|-
| Slave || slave.example.com || 192.168.0.200
|}


Sie sollten die Datei <tt>/etc/bind/named.conf</tt> nicht ändern.
* Master für ''example.com'' konfiguriert
* Slave konfigurieren, Zonendaten von Master beziehen


Slave-Zonendateien sollten in <tt>/var/lib/bind</tt> (nicht <tt>/etc/bind</tt>) abgelegt werden, damit <tt>named</tt> Schreibrechte für diese Dateien hat. Protokollmeldungen werden in die Datei <tt>/var/log/daemon.log</tt> geschrieben.
=== Dateispeicherorte ===
Debian-basiert
{| class="wikitable options big"
! Zweck !! Pfad
|-
| Zonendeklarationen || '''''/etc/bind/named.conf.local'''''
|-
| Globale Optionen || '''''/etc/bind/named.conf.options'''''
|-
| Hauptdatei von BIND (nicht ändern) || '''''/etc/bind/named.conf'''''
|-
| Slave-Zonendateien (schreibbar für ''named'') || '''''/var/lib/bind'''''
|-
| Protokollmeldungen || '''''/var/log/daemon.log'''''
|}


=== Vorgehen ===
== Vorgehen ==
Es gibt drei Punkte zu beachten, wenn <tt>ns1</tt> als Slave für <tt>ns0</tt> fungieren soll:
Für den Betrieb von ''slave'' als Slave von ''master'' sind drei Aspekte relevant
# <tt>ns1</tt> muss so konfiguriert werden, dass es als Slave-Nameserver für die Zone fungiert.
# ''slave'' wird als Slave-Nameserver für die Zone konfiguriert
# <tt>ns1</tt> muss mitgeteilt werden, wann eine Zonenübertragung durchgeführt werden soll. Die bevorzugte Methode ist, dass <tt>ns0</tt> ihm eine Benachrichtigung sendet, wenn eine Übertragung erforderlich ist.
# ''slave'' muss erkennen können, wann eine Zonenübertragung erforderlich ist. Bevorzugt sendet ''master'' hierzu eine NOTIFY-Benachrichtigung
# <tt>ns0</tt> muss so konfiguriert werden, dass Zonenübertragungen an <tt>ns1</tt> zulässig sind.
# ''master'' wird so konfiguriert, dass Zonenübertragungen (AXFR/IXFR) nach ''slave'' zulässig sind


In den meisten Fällen erfüllt die Standardkonfiguration von BIND die Punkte 2 und 3. Es empfiehlt sich jedoch, dies explizit zu konfigurieren, wenn Sie sich auf dieses Verhalten verlassen möchten.
=== Zone-Deklaration ===
; Slave-Zone-Deklaration
In der ''named''-Konfiguration ist für jede bereitgestellte Zone eine Zonendeklaration erforderlich
* Für ''slave'' als Slave für die Zone ''example.com'' kann beispielsweise folgende Deklaration verwendet werden


==== Slave-Zone-Deklaration zu ns1 hinzufügen ====
<syntaxhighlight lang="bash" copy line>
Die <tt>named</tt>-Konfigurationsdatei muss für jede bereitzustellende Zone eine Zonendeklaration enthalten. Hier ist eine geeignete Deklaration für die Zone <tt>example.com</tt> auf <tt>ns1</tt>:
zone "example.com" {
  type slave;
  masters { 192.168.0.100; };
  file "/var/lib/bind/db.example.com";
};
</syntaxhighlight>


zone "example.com" {
{| class="wikitable options big"
  type slave;
! Parameter
  masters { 198.51.100.1; };
! Beschreibung
  file "/var/lib/bind/db.example.com";
|-
};
| type slave;
| Legt fest, dass die Zonendaten von einem anderen Nameserver per Zonenübertragung bezogen werden
|-
| masters { 192.168.0.100; };
| Definiert eine Liste von Nameservern, von denen Zonendaten bezogen werden können
* Ein Slave kann seine Daten auch von einem anderen Slave übernehmen.<br>Werden IP-Adressen und nicht Domainnamen angegeben
|-
| file "/var/lib/bind/db.example.com";
| Gibt den Speicherort der lokalen Kopie der Zonendaten auf ''slave'' an
* Die Zonendatei für den Slave-Nameserver ist nicht obligatorisch, aber ohne sie verliert der untergeordnete Server beim Neustart den Inhalt der Zone
|}


Die Angabe <tt>type</tt> mit dem Wert <tt>slave</tt> legt fest, dass die Zonendaten von einem anderen Nameserver bezogen werden.
; Hinweis
Es ist auch möglich, die Liste „masters“ im Voraus festzulegen.


Die Anweisung <tt>masters</tt> enthält eine Liste von Nameservern, von denen Zonendaten bezogen werden können.


Dabei müssen es sich nicht zwingend um Master im oben definierten Sinne handeln: Es ist möglich (und manchmal erforderlich), dass ein Slave die Zonendaten von einem anderen Slave bezieht.
<syntaxhighlight lang="bash" copy line>
masters masterslist {
    192.168.0.100;  # master1.example.com
    192.168.0.101;  # master2.example.net
};
</syntaxhighlight>


Masters müssen als IP-Adressen und nicht als Domainnamen angegeben werden; es ist jedoch möglich, eine „masters list“ mit den benötigten Adressen zu definieren, auf die anschließend symbolisch verwiesen werden kann (siehe unten).
Danach muss diese Liste in der Anweisung ''masters'' bekannt gegeben werden
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
  type slave;
  masters { masterslist; };
  file "/var/lib/bind/db.example.com";
};
</syntaxhighlight>


Zonendateien sind für Slave-Nameserver optional, werden aber dringend empfohlen, da der Slave andernfalls beim Neustart alle Informationen über den Inhalt der Zone verliert.
=== Benachrichtigungen ===
; Benachrichtigungen von master aktivieren
; Zone-Übertragungsintervall
Zeitpunkte für Zonenübertragungen lassen sich im Wesentlichen auf zwei Arten steuern
* regelmäßiges Abfragen (Polling) durch den Slave
* Benachrichtigung des Slave durch den Master, sobald sich die Zone geändert hat (NOTIFY)


Er kann die Zone dann erst wieder bereitstellen, nachdem eine Zonenübertragung durchgeführt wurde; ist der Master aus irgendeinem Grund nicht verfügbar, kann die Ausfallzeit erheblich sein.
Die Benachrichtigung durch den Master ist in der Praxis schneller und ressourcenschonender


==== Benachrichtigungen von ns0 aktivieren ====
; Einstellung NOTIFY
Es gibt zwei Möglichkeiten zu steuern, wann Zonenübertragungen stattfinden:
BIND sendet standardmäßig NOTIFY-Benachrichtigungen
* durch regelmäßiges Abfragen (Polling) oder
* Wenn NOTIFY ein wesentlicher Bestandteil der Konfiguration ist, wird eine explizite Aktivierung empfohlen
* indem der Master den Slave benachrichtigt, wenn sich die Zone geändert hat.
* Dies kann zonenweise erfolgen


Die zweite Methode ist vorzuziehen, da sie sowohl schneller als auch effizienter ist.
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
  type master;
  file "/var/lib/bind/db.example.com";
  notify yes;
  // …
};
</syntaxhighlight>


BIND sendet standardmäßig Benachrichtigungen. Es ist jedoch gute Praxis, sie ausdrücklich zu aktivieren, wenn sie ein wichtiger Bestandteil der Konfiguration sind. Dies kann für einzelne Zonen erfolgen:
: oder global für alle Zonen


zone "example.com" {
<syntaxhighlight lang="bash" copy line>
  type master;
options {
  file "/var/lib/bind/db.example.com";
  notify yes;
  notify yes;
  // …
  // …
};
};
</syntaxhighlight>


oder als Vorgabe für alle Zonen:
; Einstellungen innerhalb einer Zonendeklaration haben Vorrang vor globalen Vorgaben in der Sektion ''options''


options {
Damit NOTIFY sinnvoll arbeitet, muss der Master wissen, welche Nameserver benachrichtigt werden sollen
  notify yes;
* Standardmäßig benachrichtigt BIND diejenigen Nameserver, für die ''NS''-Resource-Records existieren
  // …
* Für zusätzliche Empfänger wird die Direktive ''also-notify'' verwendet
};
* Diese kann für eine einzelne Zone gesetzt werden


Die Einstellung in einer Zonendeklaration hat Vorrang; wenn Sie also die zweite Methode verwenden, sollten Sie prüfen, dass diese nicht auf Zonenebene überschrieben wurde.
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
  type master;
  notify yes;
  also-notify { 192.168.0.200; };
  file "/var/lib/bind/db.example.com";
};
</syntaxhighlight>


Der Master muss wissen, welche Nameserver er benachrichtigen soll. Standardmäßig benachrichtigt er diejenigen, für die <tt>NS</tt>-Resource-Records existieren, was für die meisten Zwecke ausreichend ist.
oder global


Nameserver, für die keine <tt>NS</tt>-Einträge existieren, können über die Anweisung <tt>also-notify</tt> benachrichtigt werden. Wie zuvor kann dies entweder für eine einzelne Zone erfolgen:
<syntaxhighlight lang="bash" copy line>
options {
  notify yes;
  also-notify { 192.168.0.200; };
  // …
};
</syntaxhighlight>


zone "example.com" {
Wichtige Punkte im Überblick
  type master;
* ''notify yes;'' aktiviert NOTIFY-Benachrichtigungen
  notify yes;
* ''also-notify { …; };'' ergänzt die Standardliste der Empfänger, die über ''NS''-Resource-Records definiert ist
  also-notify { 203.0.113.1; };
* ''also-notify'' eignet sich insbesondere für Nameserver, die nicht im öffentlichen ''NS''-Satz der Zone aufgeführt werden sollen (z. B. versteckte Master oder zusätzliche Slaves)
  file "/var/lib/bind/db.example.com";
};


oder als Vorgabe für alle Zonen:
=== Zonenübertragungen ===
; Zonenübertragungen auf master erlauben
Standardmäßig erlaubt BIND Zonenübertragungen von beliebigen Adressen
* Es wird empfohlen, strengere Richtlinien anzuwenden


options {
Die zugelassenen Empfänger werden mit der Direktive '''''allow-transfer''''' definiert
  notify yes;
  also-notify { 203.0.113.1; };
  // …
};


==== Zonenübertragungen auf ns0 erlauben  ====
; Einzelne Zone
Standardmäßig erlaubt BIND Zonenübertragungen von überall her. Ob dies eine sinnvolle Praxis ist, wird unterschiedlich bewertet, und es ist nicht ungewöhnlich, eine restriktivere Richtlinie vorzugeben.
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
  type master;
  notify yes;
  allow-transfer { 192.168.0.200; };
  file "/var/lib/bind/db.example.com";
};
</syntaxhighlight>


Die Server, denen Zonenübertragungen erlaubt sind, werden in einer <tt>allow-transfer</tt>-Anweisung angegeben. Wie bei den Benachrichtigungen kann dies entweder für eine einzelne Zone erfolgen:
; Global
Für alle Zonen
<syntaxhighlight lang="bash" highlight="" copy line>
options {
  notify yes;
  allow-transfer { 192.168.0.200; };
  // …
};
</syntaxhighlight>


zone "example.com" {
Die Angabe ''allow-transfer { 192.168.0.200; };'' beschränkt Zonenübertragungen auf den Nameserver mit der IP-Adresse 192.168.0.200
  type master;
  notify yes;
  allow-transfer { 203.0.113.1; };
  file "/var/lib/bind/db.example.com";
};


oder als Vorgabe für alle Zonen:
Wenn Zonenübertragungen nicht eingeschränkt werden sollen, kann dies explizit mit dem Schlüsselwort ''any'' ausgedrückt werden


options {
<syntaxhighlight lang="bash" highlight="" copy line>
  notify yes;
options {
  allow-transfer { 203.0.113.1; };
  notify yes;
  // …
  allow-transfer { any; };
};
  // …
};
</syntaxhighlight>


Wenn Sie damit einverstanden sind, dass Zonenübertragungen nicht eingeschränkt werden, können Sie dies durch die Angabe der Adresse <tt>any</tt> explizit machen:
In diesem Fall sind Zonenübertragungen für beliebige Clients zulässig
* Ob dies sinnvoll ist, hängt von den Sicherheitsanforderungen der jeweiligen Umgebung ab


options {
=== Neustart der Dienste ===
  notify yes;
Sie müssen den Bind-Dienst auf master und slave nacheinander mit dem folgenden Befehl neu starten
  allow-transfer { any; };
  // …
};


==== ns0 neu laden ====
<syntaxhighlight lang="bash" highlight="1" copy line>
Wenn die Konfiguration von <tt>ns0</tt> in irgendeiner Weise geändert wurde, sollte der Dienst neu geladen werden. * [https://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html Einen Systemdienst dazu veranlassen, seine Konfiguration neu zu laden]https://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.
rndc reload
</syntaxhighlight>


==== ns1 neu laden ====
== Test ==
Die Konfiguration von <tt>ns1</tt> wurde geändert, daher muss dieser Dienst auf jeden Fall neu geladen werden. Dies sollte der letzte Schritt sein (nach dem Neuladen von <tt>ns0</tt>, falls erforderlich). * [https://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html Einen Systemdienst dazu veranlassen, seine Konfiguration neu zu laden]https://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.
=== Slave-Server ===
Die Funktionsfähigkeit von ''slave'' lässt sich über eine SOA-Abfrage mit ''dig'' prüfen


=== Tests ===
<syntaxhighlight lang="bash" highlight="1" copy line>
==== Bedient ns1 die Zone? ====
dig @192.168.0.200 -t SOA example.com +norecurs
Sie können testen, ob <tt>ns1</tt> funktionsfähig ist, indem Sie mit dem Befehl <tt>dig</tt> den SOA-Resource-Record (Start of Authority) für die betreffende Zone abfragen:
</syntaxhighlight>


dig @203.0.113.1 -t SOA example.com +norecurs
Der Parameter ''+norecurs'' erzwingt eine nicht-rekursive Abfrage
* Eine korrekte SOA-Antwort zeigt, dass der Server als autoritativer Nameserver antwortet
* Das allein bestätigt jedoch nicht den Slave-Status, da die Daten aus einem Cache stammen können


Der Parameter <tt>+norecurs</tt> am Ende des Befehls weist <tt>dig</tt> an, eine nicht-rekursive Abfrage durchzuführen. Die Antwort sollte in etwa wie folgt aussehen:
Zur Unterscheidung müssen die Flags im Header analysiert werden


<nowiki>;; ANSWER SECTION:</nowiki>
<syntaxhighlight lang="console" line>
example.com.            86400  IN      SOA    example.com. hostmaster.example.com. 41 28800 7200 604800 86400
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
</syntaxhighlight>


Eine korrekte Antwort zeigt an, dass <tt>ns1</tt> als Nameserver funktioniert, jedoch nicht zwingend, dass er ein Slave für <tt>example.com</tt> ist: Die Antwort könnte aus dem Cache einer früheren rekursiven Abfrage stammen.
Das relevante Flag ist ''aa''
* Ist es gesetzt, stammt die Antwort aus der autoritativen Zone von ''slave''
* Ein gesetztes ''aa'' zeigt damit in der Regel an, dass der Slave die Zone geladen hat


Um den Unterschied zu erkennen, sollten Sie die Flags betrachten, die am Anfang der Antwort ausgegeben werden:
=== Benachrichtigungen ===
Die erste Zonenübertragung erfolgt unabhängig von Benachrichtigungen, spätere Übertragungen benötigen jedoch funktionierendes NOTIFY (sofern kein Polling verwendet wird)


<nowiki>;; Got answer:</nowiki>
Für einen Test wird auf ''master'' die Seriennummer im SOA-Eintrag erhöht
<nowiki>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42311</nowiki>
<nowiki>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2</nowiki>


Das relevante Flag ist <tt>aa</tt>. Wenn <tt>ns1</tt> als Slave arbeitet, ist das Flag <tt>aa</tt> gesetzt; dies bedeutet, dass die Antwort autoritativ ist.
<syntaxhighlight lang="ini" line>
@  IN  SOA example.com. hostmaster.example.com. (
        41
        8H
        2H
        1W
        1D )
</syntaxhighlight>


==== Benachrichtigungen überprüfen  ====
Die Seriennummer wird beispielsweise auf 42 gesetzt
Die initiale Zonenübertragung ist nicht von Benachrichtigungen abhängig, spätere Übertragungen hingegen schon (es sei denn, Sie verlassen sich bewusst auf Polling). Um zu testen, ob Benachrichtigungen funktionieren, müssen Sie die Zone auf <tt>ns0</tt> ändern und prüfen, ob die Änderung auf <tt>ns1</tt> repliziert wird. Die am wenigsten eingreifende Änderung besteht darin, die Seriennummer zu erhöhen.


Bearbeiten Sie die Zonendatei auf <tt>ns0</tt> und suchen Sie den SOA-Eintrag. Er sollte in etwa wie folgt aussehen:
<syntaxhighlight lang="ini" line>
@  IN  SOA example.com. hostmaster.example.com. (
        42
        8H
        2H
        1W
        1D )
</syntaxhighlight>


@      IN      SOA    example.com. hostmaster.example.com. (
Anschließend wird die Konfiguration von ''named'' auf ''master'' neu geladen
                        41
* Nach dem Reload sendet ''master'' eine Benachrichtigung an ''slave''
                        8H
* Da die lokale Kopie auf ''slave'' noch die ältere Seriennummer besitzt, sollte eine erneute Zonenübertragung ausgelöst werden
                        2H
                        1W
                        1D)


Die Seriennummer in diesem Eintrag ist 41; erhöhen Sie sie daher auf 42:
Die erfolgreiche Replikation lässt sich erneut durch eine SOA-Abfrage prüfen


@       IN      SOA    example.com. hostmaster.example.com. (
<syntaxhighlight lang="bash" highlight="1" copy line>
                        42
dig @192.168.0.200 -t SOA example.com +norecurs
                        8H
</syntaxhighlight>
                        2H
                        1W
                        1D)


Laden Sie nun die Konfiguration von <tt>named</tt> auf <tt>ns0</tt> neu (siehe [https://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html Einen Systemdienst dazu veranlassen, seine Konfiguration neu zu laden]). <tt>ns0</tt> sollte <tt>ns1</tt> darüber benachrichtigen, dass es eine Kopie der Zone mit der Seriennummer 42 besitzt.
Erscheint die Seriennummer 42, wurde die Zone übertragen


Die auf <tt>ns1</tt> vorhandene Kopie der Zone hat noch die ältere Seriennummer 41; wenn der Server die Benachrichtigung erhält, sollte er deshalb eine Zonenübertragung anfordern.
<syntaxhighlight lang="console" line>
ANSWER SECTION
example.com. 86400 IN SOA example.com. hostmaster.example.com. 42 28800 7200 604800 86400
</syntaxhighlight>


Ob dies geschehen ist, können Sie feststellen, indem Sie den SOA-Eintrag erneut abfragen:
* Für zusätzliche Sicherheit kann der Test mehrfach wiederholt werden
* Alternativ lässt sich der Ablauf über die Serverprotokolle nachvollziehen


dig @203.0.113.1 -t SOA example.com +norecurs
<noinclude>


Hat sich die Seriennummer auf 42 geändert, hat eine Zonenübertragung stattgefunden, was sehr wahrscheinlich bedeutet, dass die Benachrichtigungen funktionieren:
= Anhang =
== Siehe auch ==
<div style="column-count:2">
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
</div>
----
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}


<nowiki>;; ANSWER SECTION:</nowiki>
== Dokumentation ==
example.com.           86400  IN      SOA    example.com. hostmaster.example.com. 42 28800 7200 604800 86400
<!--
; Man-Page
# [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)]
 
; Info-Pages
-->
 
== Links ==
=== Projekt ===
=== Weblinks ===


Um zusätzliche Sicherheit zu gewinnen, dass die Übertragung tatsächlich durch eine Benachrichtigung ausgelöst wurde, können Sie den Test wiederholen oder die Protokolle auswerten.


[[Kategorie:BIND]]
[[Kategorie:BIND]]
</noinclude>

Aktuelle Version vom 21. November 2025, 10:59 Uhr

BIND/Slave - Konfiguration eines DNS-Servers

Einleitung

Ein Nameserver mit BIND kann so konfiguriert werden, dass jede Zone entweder als Master- oder als Slave-Zone bereitgestellt wird

  • Ein Slave erhält seine Kopie der Zonendaten per Zonenübertragung von einem anderen Nameserver
  • Ein Master bezieht die Zonendaten aus einer unabhängigen Quelle und ist daher nicht auf andere Nameserver angewiesen

Für jede Zone wird der Betrieb von mindestens zwei Nameservern empfohlen

  • Typischerweise existiert ein Master sowie ein oder zwei Slaves, die ihre Zonendaten vom Master übernehmen

Szenario

Name Beschreibung
Zone example.com mit zwei Nameservern
Master master.example.com 192.168.0.100
Slave slave.example.com 192.168.0.200
  • Master für example.com konfiguriert
  • Slave konfigurieren, Zonendaten von Master beziehen

Dateispeicherorte

Debian-basiert

Zweck Pfad
Zonendeklarationen /etc/bind/named.conf.local
Globale Optionen /etc/bind/named.conf.options
Hauptdatei von BIND (nicht ändern) /etc/bind/named.conf
Slave-Zonendateien (schreibbar für named) /var/lib/bind
Protokollmeldungen /var/log/daemon.log

Vorgehen

Für den Betrieb von slave als Slave von master sind drei Aspekte relevant

  1. slave wird als Slave-Nameserver für die Zone konfiguriert
  2. slave muss erkennen können, wann eine Zonenübertragung erforderlich ist. Bevorzugt sendet master hierzu eine NOTIFY-Benachrichtigung
  3. master wird so konfiguriert, dass Zonenübertragungen (AXFR/IXFR) nach slave zulässig sind

Zone-Deklaration

Slave-Zone-Deklaration

In der named-Konfiguration ist für jede bereitgestellte Zone eine Zonendeklaration erforderlich

  • Für slave als Slave für die Zone example.com kann beispielsweise folgende Deklaration verwendet werden
zone "example.com" {
  type slave;
  masters { 192.168.0.100; };
  file "/var/lib/bind/db.example.com";
};
Parameter Beschreibung
type slave; Legt fest, dass die Zonendaten von einem anderen Nameserver per Zonenübertragung bezogen werden
masters { 192.168.0.100; }; Definiert eine Liste von Nameservern, von denen Zonendaten bezogen werden können
  • Ein Slave kann seine Daten auch von einem anderen Slave übernehmen.
    Werden IP-Adressen und nicht Domainnamen angegeben
file "/var/lib/bind/db.example.com"; Gibt den Speicherort der lokalen Kopie der Zonendaten auf slave an
  • Die Zonendatei für den Slave-Nameserver ist nicht obligatorisch, aber ohne sie verliert der untergeordnete Server beim Neustart den Inhalt der Zone
Hinweis

Es ist auch möglich, die Liste „masters“ im Voraus festzulegen. 


masters masterslist {
    192.168.0.100;  # master1.example.com
    192.168.0.101;  # master2.example.net
};

Danach muss diese Liste in der Anweisung masters bekannt gegeben werden 

zone "example.com" {
  type slave;
  masters { masterslist; };
  file "/var/lib/bind/db.example.com";
};

Benachrichtigungen

Benachrichtigungen von master aktivieren
Zone-Übertragungsintervall

Zeitpunkte für Zonenübertragungen lassen sich im Wesentlichen auf zwei Arten steuern

  • regelmäßiges Abfragen (Polling) durch den Slave
  • Benachrichtigung des Slave durch den Master, sobald sich die Zone geändert hat (NOTIFY)

Die Benachrichtigung durch den Master ist in der Praxis schneller und ressourcenschonender

Einstellung NOTIFY

BIND sendet standardmäßig NOTIFY-Benachrichtigungen

  • Wenn NOTIFY ein wesentlicher Bestandteil der Konfiguration ist, wird eine explizite Aktivierung empfohlen
  • Dies kann zonenweise erfolgen
zone "example.com" {
  type master;
  file "/var/lib/bind/db.example.com";
  notify yes;
  // …
};
oder global für alle Zonen
options {
  notify yes;
  // …
};
Einstellungen innerhalb einer Zonendeklaration haben Vorrang vor globalen Vorgaben in der Sektion options

Damit NOTIFY sinnvoll arbeitet, muss der Master wissen, welche Nameserver benachrichtigt werden sollen

  • Standardmäßig benachrichtigt BIND diejenigen Nameserver, für die NS-Resource-Records existieren
  • Für zusätzliche Empfänger wird die Direktive also-notify verwendet
  • Diese kann für eine einzelne Zone gesetzt werden
zone "example.com" {
  type master;
  notify yes;
  also-notify { 192.168.0.200; };
  file "/var/lib/bind/db.example.com";
};

oder global 

options {
  notify yes;
  also-notify { 192.168.0.200; };
  // …
};

Wichtige Punkte im Überblick

  • notify yes; aktiviert NOTIFY-Benachrichtigungen
  • also-notify { …; }; ergänzt die Standardliste der Empfänger, die über NS-Resource-Records definiert ist
  • also-notify eignet sich insbesondere für Nameserver, die nicht im öffentlichen NS-Satz der Zone aufgeführt werden sollen (z. B. versteckte Master oder zusätzliche Slaves)

Zonenübertragungen

Zonenübertragungen auf master erlauben

Standardmäßig erlaubt BIND Zonenübertragungen von beliebigen Adressen

  • Es wird empfohlen, strengere Richtlinien anzuwenden

Die zugelassenen Empfänger werden mit der Direktive allow-transfer definiert

Einzelne Zone
zone "example.com" {
  type master;
  notify yes;
  allow-transfer { 192.168.0.200; };
  file "/var/lib/bind/db.example.com";
};
Global

Für alle Zonen 

options {
  notify yes;
  allow-transfer { 192.168.0.200; };
  // …
};

Die Angabe allow-transfer { 192.168.0.200; }; beschränkt Zonenübertragungen auf den Nameserver mit der IP-Adresse 192.168.0.200

Wenn Zonenübertragungen nicht eingeschränkt werden sollen, kann dies explizit mit dem Schlüsselwort any ausgedrückt werden 

options {
  notify yes;
  allow-transfer { any; };
  // …
};

In diesem Fall sind Zonenübertragungen für beliebige Clients zulässig

  • Ob dies sinnvoll ist, hängt von den Sicherheitsanforderungen der jeweiligen Umgebung ab

Neustart der Dienste

Sie müssen den Bind-Dienst auf master und slave nacheinander mit dem folgenden Befehl neu starten 

rndc reload

Test

Slave-Server

Die Funktionsfähigkeit von slave lässt sich über eine SOA-Abfrage mit dig prüfen 

dig @192.168.0.200 -t SOA example.com +norecurs

Der Parameter +norecurs erzwingt eine nicht-rekursive Abfrage

  • Eine korrekte SOA-Antwort zeigt, dass der Server als autoritativer Nameserver antwortet
  • Das allein bestätigt jedoch nicht den Slave-Status, da die Daten aus einem Cache stammen können

Zur Unterscheidung müssen die Flags im Header analysiert werden 

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

Das relevante Flag ist aa

  • Ist es gesetzt, stammt die Antwort aus der autoritativen Zone von slave
  • Ein gesetztes aa zeigt damit in der Regel an, dass der Slave die Zone geladen hat

Benachrichtigungen

Die erste Zonenübertragung erfolgt unabhängig von Benachrichtigungen, spätere Übertragungen benötigen jedoch funktionierendes NOTIFY (sofern kein Polling verwendet wird)

Für einen Test wird auf master die Seriennummer im SOA-Eintrag erhöht 

@   IN  SOA example.com. hostmaster.example.com. (
        41
        8H
        2H
        1W
        1D )

Die Seriennummer wird beispielsweise auf 42 gesetzt 

@   IN  SOA example.com. hostmaster.example.com. (
        42
        8H
        2H
        1W
        1D )

Anschließend wird die Konfiguration von named auf master neu geladen

  • Nach dem Reload sendet master eine Benachrichtigung an slave
  • Da die lokale Kopie auf slave noch die ältere Seriennummer besitzt, sollte eine erneute Zonenübertragung ausgelöst werden

Die erfolgreiche Replikation lässt sich erneut durch eine SOA-Abfrage prüfen 

dig @192.168.0.200 -t SOA example.com +norecurs

Erscheint die Seriennummer 42, wurde die Zone übertragen 

ANSWER SECTION
example.com. 86400 IN SOA example.com. hostmaster.example.com. 42 28800 7200 604800 86400
  • Für zusätzliche Sicherheit kann der Test mehrfach wiederholt werden
  • Alternativ lässt sich der Ablauf über die Serverprotokolle nachvollziehen


Anhang

Siehe auch


Dokumentation

Links

Projekt

Weblinks


Abgerufen von „https://wiki.foxtom.de/index.php?title=BIND/Slave&oldid=158439“