BIND/Slave

BIND - Slave-Server

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.

Szenario

• Angenommen, die Zone example.com hat zwei Nameserver, ns0.example.com (198.51.100.1) und ns1.example.com (203.0.113.1).
• Von diesen ist ns0 bereits als Master konfiguriert. Sie möchten ns1 als Slave konfigurieren, der seine Zonendaten von ns0 bezieht.
• Auf beiden Nameservern läuft BIND Version 9.

Dateispeicherorte

Auf Debian-basierten Systemen sollten Zonendeklarationen in der Datei /etc/bind/named.conf.local und Optionen in der Datei /etc/bind/named.conf.options abgelegt werden.

Sie sollten die Datei /etc/bind/named.conf nicht ändern.

Slave-Zonendateien sollten in /var/lib/bind (nicht /etc/bind) abgelegt werden, damit named Schreibrechte für diese Dateien hat. Protokollmeldungen werden in die Datei /var/log/daemon.log geschrieben.

Vorgehen

Es gibt drei Punkte zu beachten, wenn ns1 als Slave für ns0 fungieren soll:

1. ns1 muss so konfiguriert werden, dass es als Slave-Nameserver für die Zone fungiert.
2. ns1 muss mitgeteilt werden, wann eine Zonenübertragung durchgeführt werden soll. Die bevorzugte Methode ist, dass ns0 ihm eine Benachrichtigung sendet, wenn eine Übertragung erforderlich ist.
3. ns0 muss so konfiguriert werden, dass Zonenübertragungen an ns1 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.

Slave-Zone-Deklaration zu ns1 hinzufügen

Die named-Konfigurationsdatei muss für jede bereitzustellende Zone eine Zonendeklaration enthalten. Hier ist eine geeignete Deklaration für die Zone example.com auf ns1:

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

Die Angabe type mit dem Wert slave legt fest, dass die Zonendaten von einem anderen Nameserver bezogen werden.

Die Anweisung masters 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.

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

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.

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.

Benachrichtigungen von ns0 aktivieren

Es gibt zwei Möglichkeiten zu steuern, wann Zonenübertragungen stattfinden:

• durch regelmäßiges Abfragen (Polling) oder
• indem der Master den Slave benachrichtigt, wenn sich die Zone geändert hat.

Die zweite Methode ist vorzuziehen, da sie sowohl schneller als auch effizienter ist.

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:

 zone "example.com" {
   type master;
   file "/var/lib/bind/db.example.com";
   notify yes;
   // …
 };

oder als Vorgabe für alle Zonen:

 options {
   notify yes;
   // …
 };

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.

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

Nameserver, für die keine NS-Einträge existieren, können über die Anweisung also-notify benachrichtigt werden. Wie zuvor kann dies entweder für eine einzelne Zone erfolgen:

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

oder als Vorgabe für alle Zonen:

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

Zonenübertragungen auf ns0 erlauben

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.

Die Server, denen Zonenübertragungen erlaubt sind, werden in einer allow-transfer-Anweisung angegeben. Wie bei den Benachrichtigungen kann dies entweder 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 als Vorgabe für alle Zonen:

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

Wenn Sie damit einverstanden sind, dass Zonenübertragungen nicht eingeschränkt werden, können Sie dies durch die Angabe der Adresse any explizit machen:

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

ns0 neu laden

Wenn die Konfiguration von ns0 in irgendeiner Weise geändert wurde, sollte der Dienst neu geladen werden. * Einen Systemdienst dazu veranlassen, seine Konfiguration neu zu ladenhttps://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.

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). * Einen Systemdienst dazu veranlassen, seine Konfiguration neu zu ladenhttps://www.microhowto.info/howto/cause_a_system_service_to_reload_its_configuration.html.

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.