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
 
(29 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''{{BASEPAGENAME}}''' - Praktischer Kurs zur Konfiguration eines Slave-Servers für eine DNS-Zone.
'''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


== Erstellen eines BIND-Slave-Servers ==
Für jede Zone wird der Betrieb von mindestens zwei Nameservern empfohlen
=== Einleitung ===
* Typischerweise existiert ein Master sowie ein oder zwei Slaves, die ihre Zonendaten vom Master übernehmen
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 ===
{| 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
|}


==== Szenario ====
* Master für ''example.com'' konfiguriert
* Zone: '''''example.com''''' mit zwei Nameservern:
* Slave konfigurieren, Zonendaten von Master beziehen
:* '''''ns0.example.com''''' ('''198.51.100.1''')
:* '''''ns1.example.com''''' ('''203.0.113.1''')
* '''''ns0''''' ist bereits als Master für ''example.com'' konfiguriert.
* '''''ns1''''' soll als Slave konfiguriert werden und seine Zonendaten von ''ns0'' beziehen.
* Auf beiden Nameservern läuft '''BIND Version 9'''.


==== Dateispeicherorte (Debian-basiert) ====
=== Dateispeicherorte ===
Debian-basiert
{| class="wikitable options big"
{| class="wikitable options big"
! Zweck !! Pfad
! Zweck !! Pfad
Zeile 33: Zeile 40:
|}
|}


=== Vorgehen ===
== Vorgehen ==
Für den Betrieb von ''ns1'' als Slave von ''ns0'' sind drei Aspekte relevant:
Für den Betrieb von ''slave'' als Slave von ''master'' sind drei Aspekte relevant
# ''ns1'' wird als Slave-Nameserver für die Zone konfiguriert.
# ''slave'' wird als Slave-Nameserver für die Zone konfiguriert
# ''ns1'' muss erkennen können, wann eine Zonenübertragung erforderlich ist. Bevorzugt sendet ''ns0'' hierzu eine NOTIFY-Benachrichtigung.
# ''slave'' muss erkennen können, wann eine Zonenübertragung erforderlich ist. Bevorzugt sendet ''master'' hierzu eine NOTIFY-Benachrichtigung
# ''ns0'' wird so konfiguriert, dass Zonenübertragungen (AXFR/IXFR) nach ''ns1'' zulässig sind.
# ''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
 
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
  type slave;
  masters { 192.168.0.100; };
  file "/var/lib/bind/db.example.com";
};
</syntaxhighlight>
 
{| class="wikitable options big"
! 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.<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
|}


In der Standardkonfiguration von BIND sind die Punkte 2 und 3 häufig bereits abgedeckt. Bei produktivem Betrieb wird jedoch eine explizite Konfiguration empfohlen, um das gewünschte Verhalten sicherzustellen.
; Hinweis
Es ist auch möglich, die Liste „masters“ im Voraus festzulegen.




==== Slave-Zone-Deklaration ====
<syntaxhighlight lang="bash" copy line>
In der ''named''-Konfiguration ist für jede bereitgestellte Zone eine Zonendeklaration erforderlich. Für ''ns1'' als Slave für die Zone ''example.com'' kann beispielsweise folgende Deklaration verwendet werden:
masters masterslist {
    192.168.0.100;  # master1.example.com
    192.168.0.101;  # master2.example.net
};
</syntaxhighlight>


<syntaxhighlight lang="json" copy line>
Danach muss diese Liste in der Anweisung ''masters'' bekannt gegeben werden
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
zone "example.com" {
   type slave;
   type slave;
   masters { 198.51.100.1; };
   masters { masterslist; };
   file "/var/lib/bind/db.example.com";
   file "/var/lib/bind/db.example.com";
};
};
</syntaxhighlight>
</syntaxhighlight>


* Die Direktive ''type slave;'' legt fest, dass die Zonendaten von einem anderen Nameserver per Zonenübertragung bezogen werden.
=== Benachrichtigungen ===
* Die Direktive ''masters { 198.51.100.1; };'' definiert eine Liste von Nameservern, von denen Zonendaten bezogen werden können. Dabei muss es sich nicht zwingend um Master im engeren Sinne handeln. Ein Slave kann seine Daten auch von einem anderen Slave übernehmen.
; Benachrichtigungen von master aktivieren
* In der Direktive ''masters'' werden IP-Adressen und nicht Domainnamen angegeben. Alternativ kann eine „masters list“ mit den benötigten Adressen definiert werden, auf die anschließend symbolisch verwiesen wird.
* Die Direktive ''file "/var/lib/bind/db.example.com";'' gibt den Speicherort der lokalen Kopie der Zonendaten auf ''ns1'' an. Eine Zonendatei ist für Slave-Nameserver formal optional, wird aber dringend empfohlen. Ohne Zonendatei verliert der Slave bei einem Neustart den Inhalt der Zone und kann sie erst wieder bereitstellen, nachdem eine Zonenübertragung durchgeführt wurde. Wenn der Master in diesem Moment nicht verfügbar ist, verlängert sich die Ausfallzeit.
 
==== Benachrichtigungen von ns0 aktivieren ====
; Zone-Übertragungsintervall
; Zone-Übertragungsintervall
Zeitpunkte für Zonenübertragungen lassen sich im Wesentlichen auf zwei Arten steuern:
Zeitpunkte für Zonenübertragungen lassen sich im Wesentlichen auf zwei Arten steuern
* regelmäßiges Abfragen (Polling) durch den Slave
* regelmäßiges Abfragen (Polling) durch den Slave
* Benachrichtigung des Slave durch den Master, sobald sich die Zone geändert hat (NOTIFY)
* 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.
Die Benachrichtigung durch den Master ist in der Praxis schneller und ressourcenschonender


; Einstellung NOTIFY
; 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:
BIND sendet standardmäßig NOTIFY-Benachrichtigungen
* Wenn NOTIFY ein wesentlicher Bestandteil der Konfiguration ist, wird eine explizite Aktivierung empfohlen
* Dies kann zonenweise erfolgen


<syntaxhighlight lang="json" copy line>
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
zone "example.com" {
   type master;
   type master;
Zeile 78: Zeile 118:
</syntaxhighlight>
</syntaxhighlight>


: oder global für alle Zonen:
: oder global für alle Zonen


<syntaxhighlight lang="json" copy line>
<syntaxhighlight lang="bash" copy line>
options {
options {
   notify yes;
   notify yes;
Zeile 87: Zeile 127:
</syntaxhighlight>
</syntaxhighlight>


Einstellungen innerhalb einer Zonendeklaration haben Vorrang vor globalen Vorgaben in der Sektion ''options''.
; 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:
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


<syntaxhighlight lang="json" copy line>
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
zone "example.com" {
   type master;
   type master;
   notify yes;
   notify yes;
   also-notify { 203.0.113.1; };
   also-notify { 192.168.0.200; };
   file "/var/lib/bind/db.example.com";
   file "/var/lib/bind/db.example.com";
};
};
</syntaxhighlight>
</syntaxhighlight>


oder global:
oder global


<syntaxhighlight lang="json" copy line>
<syntaxhighlight lang="bash" copy line>
options {
options {
   notify yes;
   notify yes;
   also-notify { 203.0.113.1; };
   also-notify { 192.168.0.200; };
   // …
   // …
};
};
</syntaxhighlight>
</syntaxhighlight>


Wichtige Punkte im Überblick:
Wichtige Punkte im Überblick
* ''notify yes;'' aktiviert NOTIFY-Benachrichtigungen.
* ''notify yes;'' aktiviert NOTIFY-Benachrichtigungen
* ''also-notify { …; };'' ergänzt die Standardliste der Empfänger, die über ''NS''-Resource-Records definiert ist.
* ''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).
* ''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 auf ns0 erlauben ====
=== Zonenübertragungen ===
* Standardmäßig erlaubt BIND Zonenübertragungen von beliebigen Adressen.
; Zonenübertragungen auf master erlauben
* Es wird empfohlen, strengere Richtlinien anzuwenden.
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. Dies kann für eine einzelne Zone erfolgen:
Die zugelassenen Empfänger werden mit der Direktive '''''allow-transfer''''' definiert


<syntaxhighlight lang="json" copy line>
; Einzelne Zone
<syntaxhighlight lang="bash" copy line>
zone "example.com" {
zone "example.com" {
   type master;
   type master;
   notify yes;
   notify yes;
   allow-transfer { 203.0.113.1; };
   allow-transfer { 192.168.0.200; };
   file "/var/lib/bind/db.example.com";
   file "/var/lib/bind/db.example.com";
};
};
</syntaxhighlight>
</syntaxhighlight>


oder global für alle Zonen:
; Global
 
Für alle Zonen
<syntaxhighlight lang="json" highlight="" copy line>
<syntaxhighlight lang="bash" highlight="" copy line>
options {
options {
   notify yes;
   notify yes;
   allow-transfer { 203.0.113.1; };
   allow-transfer { 192.168.0.200; };
   // …
   // …
};
};
</syntaxhighlight>
</syntaxhighlight>


Die Angabe ''allow-transfer { 203.0.113.1; };'' beschränkt Zonenübertragungen auf den Nameserver mit der IP-Adresse 203.0.113.1.
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:
Wenn Zonenübertragungen nicht eingeschränkt werden sollen, kann dies explizit mit dem Schlüsselwort ''any'' ausgedrückt werden


<syntaxhighlight lang="json" highlight="" copy line>
<syntaxhighlight lang="bash" highlight="" copy line>
options {
options {
   notify yes;
   notify yes;
Zeile 152: Zeile 197:
</syntaxhighlight>
</syntaxhighlight>


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.
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 ====
=== Neustart der Dienste ===
 
Sie müssen den Bind-Dienst auf master und slave nacheinander mit dem folgenden Befehl neu starten
Sie müssen den Bind-Dienst auf ns0 und ns1 nacheinander mit dem folgenden Befehl neu starten:


<syntaxhighlight lang="bash" highlight="1" copy line>
<syntaxhighlight lang="bash" highlight="1" copy line>
Zeile 163: Zeile 207:
</syntaxhighlight>
</syntaxhighlight>


=== Tests ===
== Test ==
==== Überprüfung des ns1-Servers ====
=== Slave-Server ===
Die Funktionsfähigkeit von »ns1« lässt sich über eine SOA-Abfrage mit »dig« prüfen:
Die Funktionsfähigkeit von ''slave'' lässt sich über eine SOA-Abfrage mit ''dig'' prüfen


<syntaxhighlight lang="bash" highlight="1" copy line>
<syntaxhighlight lang="bash" highlight="1" copy line>
dig @203.0.113.1 -t SOA example.com +norecurs
dig @192.168.0.200 -t SOA example.com +norecurs
</syntaxhighlight>
</syntaxhighlight>


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 ''+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:
Zur Unterscheidung müssen die Flags im Header analysiert werden


<syntaxhighlight lang="console" line>
<syntaxhighlight lang="console" line>
Zeile 179: Zeile 225:
</syntaxhighlight>
</syntaxhighlight>


Das relevante Flag ist »aa«. Ist es gesetzt, stammt die Antwort aus der autoritativen Zone von »ns1«. Ein gesetztes »aa« zeigt damit in der Regel an, dass der Slave die Zone geladen hat.
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 überprüfen ====
=== Benachrichtigungen ===
Die erste Zonenübertragung erfolgt unabhängig von Benachrichtigungen, spätere Übertragungen benötigen jedoch funktionierendes NOTIFY (sofern kein Polling verwendet wird).
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 »ns0« die Seriennummer im SOA-Eintrag erhöht:
Für einen Test wird auf ''master'' die Seriennummer im SOA-Eintrag erhöht


<syntaxhighlight lang="ini" line>
<syntaxhighlight lang="ini" line>
Zeile 195: Zeile 243:
</syntaxhighlight>
</syntaxhighlight>


Die Seriennummer wird beispielsweise auf 42 gesetzt:
Die Seriennummer wird beispielsweise auf 42 gesetzt


<syntaxhighlight lang="ini" line>
<syntaxhighlight lang="ini" line>
Zeile 206: Zeile 254:
</syntaxhighlight>
</syntaxhighlight>


Anschließend wird die Konfiguration von »named« auf »ns0« neu geladen. Nach dem Reload sendet »ns0« eine Benachrichtigung an »ns1«. Da die lokale Kopie auf »ns1« noch die ältere Seriennummer besitzt, sollte eine erneute Zonenübertragung ausgelöst werden.
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:
Die erfolgreiche Replikation lässt sich erneut durch eine SOA-Abfrage prüfen


<syntaxhighlight lang="bash" highlight="1" copy line>
<syntaxhighlight lang="bash" highlight="1" copy line>
dig @203.0.113.1 -t SOA example.com +norecurs
dig @192.168.0.200 -t SOA example.com +norecurs
</syntaxhighlight>
</syntaxhighlight>


Erscheint die Seriennummer 42, wurde die Zone übertragen:
Erscheint die Seriennummer 42, wurde die Zone übertragen


<syntaxhighlight lang="console" line>
<syntaxhighlight lang="console" line>
ANSWER SECTION:
ANSWER SECTION
example.com. 86400 IN SOA example.com. hostmaster.example.com. 42 28800 7200 604800 86400
example.com. 86400 IN SOA example.com. hostmaster.example.com. 42 28800 7200 604800 86400
</syntaxhighlight>
</syntaxhighlight>


* Für zusätzliche Sicherheit kann der Test mehrfach wiederholt werden.
* Für zusätzliche Sicherheit kann der Test mehrfach wiederholt werden
* Alternativ lässt sich der Ablauf über die Serverprotokolle nachvollziehen.
* Alternativ lässt sich der Ablauf über die Serverprotokolle nachvollziehen


<noinclude>
<noinclude>


== Anhang ==
= Anhang =
=== Siehe auch ===
== Siehe auch ==
<div style="column-count:2">
<div style="column-count:2">
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
Zeile 234: Zeile 284:
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}


=== Dokumentation ===
== Dokumentation ==
<!--
<!--
; Man-Page  
; Man-Page
# [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)]
# [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)]


; Info-Pages  
; Info-Pages
-->
-->


=== Links ===
== Links ==
==== Projekt ====
=== Projekt ===
==== Weblinks ====
=== Weblinks ===


<!--
{{DEFAULTSORT:new}}
{{DISPLAYTITLE:new}}
-->


[[Kategorie:BIND]]
[[Kategorie:BIND]]
[[Kategorie:Domain_Name_System]]
 
</noinclude>
</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“