Bind9 DNS Server einrichten unter Debian

Dieses Tutorial beschreibt die Installation und Konfiguration von Bind9 sowie der Einrichtung einer lokalen Zone. Hierbei wird folgende Umgebung angenommen.

  • Web und Mail-Server (192.168.1.1)
  • Primärer DNS Server (192.168.1.2)
  • Sekundärer DNS Server (192.168.1.3)

Es sollte sichergestellt sein, dass beide Server eine korrekte Serverzeit besitzen. Bestenfalls wird die Systemzeit beider DNS Server kontinuierlich per NTP synchronisiert.

Teil 1: Einrichtung des primären DNS Servers

Zunächst wird Bind auf dem primären DNS Server installiert.

apt-get install bind9

Schritt 1: Lokale Zone erstellen

Hierzu kopiert man sich zuerst das Template einer Zonendatei und öffnet dieses im Editor.

cp /etc/bind/db.local /etc/bind/db.domain.local && nano /etc/bind/db.domain.local

Die Datei wird folgendermaßen angepasst.

;
; BIND data file for domain domain.local
;
$TTL 604800
@ IN SOA ns1.domain.local. root.ns.domain.local. (
                     15060901 ; Serial
                       604800 ; Refresh
                        86400 ; Retry
                      2419200 ; Expire
                     604800 ) ; Negative Cache TTL
;
@           IN      NS      ns1.domain.local.
@           IN      NS      ns2.domain.local.
@           IN      MX 10   mail.domain.local.
@           IN      TXT     Text
ns1         IN      A       192.168.1.2
ns2         IN      A       192.168.1.3
nameserver1 IN      CNAME   ns1.domain.local.
nameserver2 IN      CNAME   ns2.domain.local.
mail        IN      A       192.168.1.1
www         IN      A       192.168.1.1

Schritt 2: Zone einbinden

nano /etc/bind/named.conf.local

Hier wird die Zone eingebunden.

zone "domain.local" {
type master;
file "/etc/bind/db.domain.local";
};

Es folgt ein Neustart von Bind.

/etc/init.d/bind9 restart

Schritt 3: Konfiguration testen

Ob die Konfiguration korrekt übernommen wurde, lässt sich am besten mit dem Tool „dig“ prüfen.

dig ANY @192.168.1.2 domain.local

Dieser Befehl gibt alle (ANY) Eintragstypen/Ressource Records für den Domainamen aus (in der Konfiguration mit einem @ gekennzeichnet). Die Ausgabe sollte in etwa so aussehen.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ANY @192.168.1.2 domain.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43150
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;domain.local. IN ANY

;; ANSWER SECTION:
domain.local. 604800 IN SOA ns1.domain.local. root.ns.domain.local. 15060907 604800 86400 2419200 604800
domain.local. 604800 IN NS ns2.domain.local.
domain.local. 604800 IN NS ns1.domain.local.
domain.local. 604800 IN MX 10 mail.domain.local.
domain.local. 604800 IN TXT "Text"

;; ADDITIONAL SECTION:
ns1.domain.local. 604800 IN A 192.168.1.2
ns2.domain.local. 604800 IN A 192.168.1.3
mail.domain.local. 604800 IN A 192.168.1.1

;; Query time: 8 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Feb 18 16:27:07 2015
;; MSG SIZE rcvd: 226

Die „QUESTION SECTION“ informiert über die angefragten Daten, die „ANSWER SECTION“ liefert die Antwort des DNS Servers. Fehlt sie, wurde kein Eintrag für die angefragte Domain gefunden. In der „ADDITIONAL SECTION“ werden zusätzliche Informationen angezeigt, wie die IP-Adressen der Nameserver und des Mailservers.

Mit folgendem Befehl lassen sich alle (ANY) Eintragstypen/Ressource Records zu einer bestimmten Subdomain abfragen.

dig ANY @192.168.1.2 www.domain.local

Die Ausgabe sollte in etwa so aussehen.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ANY @192.168.1.2 www.domain.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58831
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.domain.local. IN ANY

;; ANSWER SECTION:
www.domain.local. 604800 IN A 192.168.1.1

;; AUTHORITY SECTION:
domain.local. 604800 IN NS ns1.domain.local.
domain.local. 604800 IN NS ns2.domain.local.

;; ADDITIONAL SECTION:
ns1.domain.local. 604800 IN A 192.168.1.2
ns2.domain.local. 604800 IN A 192.168.1.3

;; Query time: 4 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Feb 18 16:32:43 2015
;; MSG SIZE rcvd: 122

Hier wird zusätzlich die „AUTHORITY SECTION“ angezeigt. Diese liefert Informationen über die autoritativen Nameserver für die Domain.

Sollte „dig“ keine Antwort in der „ANSWER SECTION“ liefern, empfiehlt sich ein Blick in syslog, da Bind standardmäßig hier seine Fehler und Warnungen schreibt.

tail -n50 /var/log/syslog

Schritt 4: Reverse Lookup Zone einrichten

Um auch eine Rückwärtssuche zu ermöglichen, also die Suche nach einem Hostnamen anhand der IP Adresse, muss nun eine Reverse Lookup Zone angelegt werden. Hierzu kopiert man wieder das Template und öffnet dieses im Editor.

cp /etc/bind/db.127 /etc/bind/db.192.168.1 && nano /etc/bind/db.192.168.1

Die Datei muss folgendermaßen angepasst werden.

;
; BIND reverse data file for 1.168.192.in-addr.arpa
;
$TTL 604800
@ IN SOA ns.domain.local. root.ns.domain.local. (
                    15060902 ; Serial
                      604800 ; Refresh
                       86400 ; Retry
                     2419200 ; Expire
                    604800 ) ; Negative Cache TTL
;
@           IN     NS      ns1.domain.local.
@           IN     NS      ns2.domain.local.
1           IN     PTR     www.domain.local.
2           IN     PTR     ns1.domain.local.
3           IN     PTR     ns2.domain.local.

Hier werden wieder die Nameserver der Zone angegeben sowie die jeweils letzten Oktetts der IP-Adressen und die zuzuordnenden Hostnamen.

Schritt 5: Zone einbinden

Nun wird die Zone, wie bereits weiter oben durchgeführt, eingebunden.

nano /etc/bind/named.conf.local
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.1";
};

Es folgt ein Neustart von Bind.

/etc/init.d/bind9 restart

Schritt 6: Konfiguration testen

Die Rückwärtssuche ist mit dig über den Parameter -x möglich.

dig @192.168.1.2 -x 192.168.1.1

In der „ANSWER SECTION“ sollte nun der Hostname zur IP-Adresse ausgegeben werden.

;; ANSWER SECTION:
1.1.168.192.in-addr.arpa. 604800 IN PTR www.domain.local.

Teil 2: Einrichtung des sekundären DNS Servers

Aufgabe des Sekundären DNS Server ist es, die Einträge des primären DNS Servers zu beziehen (TRANSFER) und aktuell (UPDATE) zu halten. Dies sorgt bei einem Ausfall des primären DNS Servers dafür, dass Anfragen weiterhin beantwortet werden können. Hierfür muss Bind zuerst auf dem sekundären Server installiert werden.

apt-get install bind9

Schritt 1: Schreibrechte auf Konfigurationsverzeichnis erteilen

Damit Bind die Konfiguration des primären DNS Servers auch in sein Konfigurationsverzeichnis schreiben kann, muss die Gruppe „bind“ Schreibrechte bekommen.

chmod g+w /etc/bind

Schritt 2: Zone einbinden

Um dem sekundären DNS Server zu sagen welche Zonen er vom primären DNS Server beziehen soll muss die Konfiguration folgendermaßen angepasst werden.

nano /etc/bind/named.conf.local
zone "domain.local" {
type slave;
file "/etc/bind/slave.domain.local";
masters {192.168.1.2;};
};

zone "1.168.192.in-addr.arpa" {
type slave;
file "/etc/bind/slave.192.168.1";
masters {192.168.1.2;};
};

Es folgt ein Neustart von Bind.

/etc/init.d/bind9 restart

Damit ist der sekundäre DNS Server bereits fertig eingerichtet. Bind sollte mit dem Neustart auch bereits die Zonendatei vom primären DNS Server bezogen und unter /etc/bind/slave.domain.local sowie /etc/bind/slave.192.168.1 abgelegt haben. Ist dies nicht der Fall, hilft ein Blick ins Logfile.

tail -n50 /var/log/syslog

Teil 3: DNS Sicherheit

Befinden sich beide DNS Server sicher hinter einer Firewall sind die Sicherheitsaspekte nicht ganz so relevant. Sind die DNS Server jedoch über das Internet erreichbar, sollten folgende Sicherheitsmaßnahmen unbedingt vorgenommen werden, um Angriffe zu verhindern oder zumindest zu erschweren.

Hinweis: DNS Sicherheit ist ein komplexes Thema. Die beschriebenen Maßnahmen dienen nur als Basis-Schutz. Ausgefeiltere Techniken, wie die Signierung einer eigenen Zone mittels DNSSEC ,werden nicht behandelt. In Bind9 unter Debian Wheezy ist DNSSEC Validierung standardmäßig aktiviert.

Schritt 1: Schlüssel für Zonentransfer erstellen

cd /etc/bind && dnssec-keygen -a hmac-md5 -b 128 -n HOST master-slave

Damit werden in /etc/bind zwei Schlüssel erstellt. Die Zeichen hinter Kmaster-slave sind Informationen über Algorithmus sowie der Identifier des Schlüssels. Der Identifier lautet je nach Schlüssel anders, weshalb die unten genannten Daten als Beispiel anzusehen sind. In /etc/bind liegen nach Ausführen des oben genannten Befehls nun zwei Schlüssel.

  • Kmaster-slave.+157+09737.key (Public Key)
  • Kmaster-slave.+157+09737.private (Private Key)

Schritt 2: Schlüssel in Konfiguration einbinden

Zunächst lässt man sich den privaten Schlüssel über folgenden Befehl ausgeben.

cat Kmaster-slave.+157+09737.private | grep -i key

Damit wird der eben generierte Schlüssel angezeigt.

Private-key-format: v1.3
Key: 8IyIiqMV9RYAjOlNsvpyUw==

Dieser muss nun in die Konfiguration eingebunden werden. Aus Sicherheitsgründen wird die Konfiguration des Schlüssels ausgelagert und ausschließlich für Bind lesbar gemacht.

touch /etc/bind/master-slave.key && chown bind:bind /etc/bind/master-slave.key && chmod 400 /etc/bind/master-slave.key && nano /etc/bind/master-slave.key

Im Editor fügt man folgende Direktiven ein, wobei hier unter secret der generierte Schlüssel eingetragen werden muss.

key master-slave {
algorithm hmac-md5;
secret "8IyIiqMV9RYAjOlNsvpyUw==";
};

Danach wird die ausgelagerte Schlüsselkonfiguration in die Hauptkonfiguration per „include“ eingebunden.

nano /etc/bind/named.conf.local

Hier fügt man Folgendes ein.

include "/etc/bind/master-slave.key";
server 192.168.1.3 {
keys { master-slave ;};
};

Die IP-Adresse die hier angegeben wird entspricht jeweils der IP mit der man Zonendaten austauschen will. Auf dem primären DNS Server wird demnach die IP des sekundären DNS Servers angegeben auf dem sekundären DNS Server, die IP des primären DNS Servers.

Auf dem sekundären DNS Server muss Schritt 2 unter Verwendung des selben Schlüssels durchgeführt werden.

Schritt 3: Zonenkonfiguration anpassen

Zurück auf dem primären DNS Server wird in der Zonenkonfiguration nun noch definiert, mit welchem Key das ein Update und der Transfer überhaupt möglich ist.

nano /etc/bind/named.conf.local

Hier wird die Zone eingebunden, sodass Bind sie nach einem Neustart lädt.

zone "domain.local" {
type master;
file "/etc/bind/db.domain.local";
allow-update { key master-slave ;};
allow-transfer { key master-slave ;};
};

zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.1";
allow-update { key master-slave ;};
allow-transfer { key master-slave ;};
};

Schritt 4: Transfer und Update Anfragen global ablehnen

Um alle anderen Transfer und Update Anfragen von fremden DNS Servern abzulehnen sollten in /etc/bind/named.conf.options noch die folgenden zwei Direktiven eingefügt werden.

nano /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
allow-transfer {none;};
allow-update {none;};
};

Schritt 5: Clientzugriff einschränken

Damit nur selektierte Clients Anfragen an den DNS Server schicken können werden zunächst ACLs definiert, die dann in den Options mit Berechtigungen versehen werden.

nano /etc/bind/named.conf.local

Hier definiert man beispielsweise eine ACL für seine lokalen Clients. Es können IP-Adressen aber, wie im Beispiel gezeigt, auch ganze Netze angegeben werden.

acl lan-clients {
192.168.1.0/24;
192.168.0.0/24;
};

In /etc/bind/named.conf.options definiert man anschließend die Berechtigungen der einzelnen ACLs.

nano /etc/bind/named.conf.options
options {
 directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
allow-transfer {none;};
allow-update {none;};
allow-query { lan-clients; };
allow-recursion { lan-clients; };
};

Diese Direktiven erlauben der oben definierten ACL (lan-clients) Anfragen an den DNS Server zu senden. Clients anderer Netze können bekommen nun keine Antwort mehr von dem DNS Server. Um die Direktiven zu aktivieren folgt ein Neustart von Bind.

/etc/init.d/bind9 restart

Die Schritte 4 und 5 sollten auf dem sekundären DNS Server ebenfalls durchgeführt werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.