BIND/Slave

BIND/Slave - Praktischer Kurs zur Konfiguration eines Slave-Servers für eine DNS-Zone.

Erstellen eines BIND-Slave-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

• 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

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.
• 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:

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.

Neustart der Dienste

Sie müssen den Bind-Dienst auf ns0 und ns1 nacheinander mit dem folgenden Befehl neu starten:

rndc reload

Tests

Überprüfung des ns1-Servers

Die Funktionsfähigkeit von »ns1« lässt sich über eine SOA-Abfrage mit »dig« prüfen:

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.

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 »ns1«. Ein gesetztes »aa« zeigt damit in der Regel an, dass der Slave die Zone geladen hat.

Benachrichtigungen überprüfen

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:

@   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 »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.

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

dig @203.0.113.1 -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.

---