BIND/Slave

BIND - Slave-Server

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

• Zone: example.com mit zwei Nameservern:

• 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)

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 ns1 als Slave von ns0 sind drei Aspekte relevant:

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

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.

Slave-Zone-Deklaration zu ns1 hinzufügen

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:

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

• Die Direktive type slave; legt fest, dass die Zonendaten von einem anderen Nameserver per Zonenübertragung bezogen werden.
• 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.
• 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

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 { 203.0.113.1; };
  file "/var/lib/bind/db.example.com";
};

oder global:

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

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 auf ns0 erlauben

Standardmäßig erlaubt BIND Zonenübertragungen von beliebigen Adressen. In vielen Umgebungen wird stattdessen eine restriktivere Richtlinie verwendet, bei der nur bestimmte Server Zonendaten abrufen dürfen.

Die zugelassenen Empfänger werden mit der Direktive allow-transfer definiert. Dies kann für eine einzelne Zone erfolgen:

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

oder global für alle Zonen:

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

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

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.

ns0 neu laden

Wenn die Konfiguration von ns0 in irgendeiner Weise geändert wurde, sollte der Dienst neu geladen werden.

ns1 neu laden

Die Konfiguration von ns1 wurde geändert, daher muss dieser Dienst auf jeden Fall neu geladen werden. Dies sollte der letzte Schritt sein (nach dem Neuladen von ns0, falls erforderlich).

Tests

Bedient ns1 die Zone?

Sie können testen, ob ns1 funktionsfähig ist, indem Sie mit dem Befehl dig den SOA-Resource-Record (Start of Authority) für die betreffende Zone abfragen:

dig @203.0.113.1 -t SOA example.com +norecurs

Der Parameter +norecurs am Ende des Befehls weist dig an, eine nicht-rekursive Abfrage durchzuführen. Die Antwort sollte in etwa wie folgt aussehen:

;; ANSWER SECTION:
example.com.            86400   IN      SOA     example.com. hostmaster.example.com. 41 28800 7200 604800 86400

Eine korrekte Antwort zeigt an, dass ns1 als Nameserver funktioniert, jedoch nicht zwingend, dass er ein Slave für example.com ist: Die Antwort könnte aus dem Cache einer früheren rekursiven Abfrage stammen.

Um den Unterschied zu erkennen, sollten Sie die Flags betrachten, die am Anfang der Antwort ausgegeben werden:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42311</nowiki>
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

Das relevante Flag ist aa. Wenn ns1 als Slave arbeitet, ist das Flag aa gesetzt; dies bedeutet, dass die Antwort autoritativ ist.

Benachrichtigungen überprüfen

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 ns0 ändern und prüfen, ob die Änderung auf ns1 repliziert wird. Die am wenigsten eingreifende Änderung besteht darin, die Seriennummer zu erhöhen.

Bearbeiten Sie die Zonendatei auf ns0 und suchen Sie den SOA-Eintrag. Er sollte in etwa wie folgt aussehen:

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

Die Seriennummer in diesem Eintrag ist 41; erhöhen Sie sie daher auf 42:

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

Laden Sie nun die Konfiguration von named auf ns0 neu (siehe Einen Systemdienst dazu veranlassen, seine Konfiguration neu zu laden). ns0 sollte ns1 darüber benachrichtigen, dass es eine Kopie der Zone mit der Seriennummer 42 besitzt.

Die auf ns1 vorhandene Kopie der Zone hat noch die ältere Seriennummer 41; wenn der Server die Benachrichtigung erhält, sollte er deshalb eine Zonenübertragung anfordern.

Ob dies geschehen ist, können Sie feststellen, indem Sie den SOA-Eintrag erneut abfragen:

dig @203.0.113.1 -t SOA example.com +norecurs

Hat sich die Seriennummer auf 42 geändert, hat eine Zonenübertragung stattgefunden, was sehr wahrscheinlich bedeutet, dass die Benachrichtigungen funktionieren:

ANSWER SECTION:
example.com.            86400   IN      SOA     example.com. hostmaster.example.com. 42 28800 7200 604800 86400

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.