DNS-Server BIND9 als Slave einrichten

In den meisten IT-Umgebungen findet man ein Microsoft Active Directory vor. Damit verbunden wird meistens auch der Microsoft DNS-Server auf dem Domain Controller mit installiert. Das liegt zum Einem an der einfachen Administration aber auch das quasi bei der Installation des Active Directory nur ein „Haken“ zu setzen ist. Nach der Grundeinrichtung des DNS-Servers (weitere Forward Zonen, Reverse Zonen für jeden IP-Adressenbereich) ist nicht mehr viel zu tun.

Bei heutigen Planungen wird als Active Directory Namen gerne eine offizielle Domain als Fully-Qualified Host Name (FQDN) gegeben. In meinen Fall wäre es z.B. der Name wydler.eu. Das entspricht inzwischen auch den Best Practice seitens Microsofts, was früher nicht der Fall war.

Sobald Anwendungen, welche im lokalen, geschützten Netzwerk (LAN) installiert sind über das Internet erreichbar sein müssen, muss man sich zwangsweise mit dem Thema Split-DNS auseinandersetzen. Denn die obengenannte Domain wydler.eu ist über einen Anbieter wie z.B. Core Networks registriert. D.h. dessen DNS-Server verwaltet die Domain autoritativ. Damit muss man automatisch die Zone auf zwei DNS-Server pflegen.

Mit den zunehmenden Sicherheitsvorfällen steigt inzwischen auch das Sicherheitsbewusstsein. Damit verbunden werden immer häufiger vorhandene Strukturen um eine DMZ erweitert. Die Kommunikation zwischen Internet und DMZ bzw. DMZ < -> LAN wird jeweils mit einer Firewall geschützt und kontrolliert. In der DMZ werden Applikationen platziert, welche a) sowohl aus dem LAN als auch Internet erreichbar sein müssen b) Proxysysteme welche Anwendungen im LAN veröffentlichen.

Für die Kommunikation vom LAN die DMZ über den jeweiligen FQDN wird einfach im DNS-Server im LAN ein entsprechender A bzw. PTR-Eintrag angelegt. Somit wird bei Anwendungen, welche ein offizielles, gültiges Zertifikat verwenden keinerlei Fehlermeldungen ausgegeben. Andersherum sieht es schon anders aus. Meist wird der Einfachheit halber die jeweilige HOST-Datei des betroffenen Servers in der DMZ modifiziert. Was bei einer geringen Anzahl von Systemen den administrativen Aufwand im Grenzen hält. Gibt es viele Sever in der DMZ, so ist die Verwaltung über die HOSTS-Datei mit hohem Aufwand verbunden und die Übersicht geht schnell verloren.

Hier empfiehlt sich der Einsatz eines DNS-Servers in der DMZ. Dieser wird als Slave konfiguriert und erhält die notwendigen Zonen (Forward & Reserve) automatisch aus dem DNS-Server im LAN (Master). Damit kommt das klassische Design Master-Slave zum Einsatz.

Umgebung
LAN:
– Subnetz: 192.168.122.0/24
– 1x virtuelle Maschine, Windows Server 2012R2 Standard (Active Directory und DNS-Server), 192.168.122.2/24
– Active Directory FQDN: lab01.wydler.eu
– Active Directory NetBios: lab01

DMZ:
– Subnetz: 192.168.123.0/24
– 1x virtuelle Maschine, Ubuntu Server 18.04.1 LTS (BIND9), 192.168.123.12/24

Installation und Konfiguration von BIND9

Installation:

/etc/bind/named.conf.options

/etc/bind/named.conf.wydler.eu

cat /etc/bind/named.conf

Konfiguration des Windows DNS Servers

Wenn es mehrere DNS-Server in der DMZ gibt, welche als Slave agieren sollen, sind hier alle IP-Adressen einzutragen.

Die Meldung „Auflösung nicht möglich“ kommt daher, wenn in der Forward-Lookupzone der A-Eintrag für den DNS-Server in der DMZ fehlt.


Diese Schritte sind für jede Zone (egal welches Typs) zu wiederholen.

Anmerkungen

  • Regelwerk der Firewall zwischen den Sicherheitszonen LAN und DMZ ergänzen.
  • Regeln der Firewall auf den jeweiligen Server anpassen.
  • Für eine einwandfreie Kommunikation der DNS-Server ist eine bidirektionale Kommunikation notwendig (Port 53/UDP).
  • Reverse-Lookupzone für den IP-Adressbereich der DMZ im Microsoft DNS-Server anlegen und pflegen. Somit funktioniert die Namensauflösung auch rückwärts.
  • Gibt es mehrere Microsoft DNS-Server im LAN, sind die obigen Schritte (Konfiguration des Windows DNS Servers) pro Server und Zone zu wiederholen. Die Benachrichtigung wird immer auf dem Server ausgelöst, auf dem die Änderung durchgeführt wurde.

Testlauf
Zuerst den Dienst BIND9 neu starten, damit die geänderte Konfiguration geladen und aktiv wird.

Anschließend kann die Funktionalität geprüft werden.

Nun kann der Slave DNS-Server in der DMZ von dortigem Server genutzt werden. Damit er seinen Zweck auch erfüllt, müssen die Einträge der HOSTS-Datei noch entfernt werden. Anderenfalls fällt die fehlerhafte Konfiguration erst auf, wenn es einen DNS-Namen nicht mehr gibt oder unter einer anderen IP-Adresse erreichbar ist.

Viel Spaß beim Ausprobieren. 🙂