Mit dem DNS(„Domain Name System“)-Server Bind kann man neben der Namensauflösung in einfachen Netzwerken mit nur einem Domainnamen auch komplexere Strukturen mit mehreren Domains realisieren.
Aufbauend auf dem Grundlagenbeitrag über Bind werden wir nachfolgend exemplarisch in einem lokalen Netzwerk die drei Domainnamen test.local, example.local und dummy.local einrichten. Hierbei gehen wir der Übersichtlichkeit halber nicht auf Konfigurationsmöglichkeiten für externe Zugriffe aus dem Internet ein.
Voraussetzungen
Wir haben unseren Server z. B. gemäß den Anleitungen zur Ubuntu-Server-Basisinstallation und zur Bind-Installation im lokalen Netzwerk 192.168.0.0/24 installiert und konfiguriert und durch Updates / Upgrades auf den neuesten Stand gebracht. Der DNS-Server server.test.local hat die IPv4-Adresse 192.168.0.1, der Mailserver mail.test.local ist unter 192.168.0.2 erreichbar. Die drei Domains und je ein Server server sind folgenden Adressen zugeordnet:
IP-Adresse Domain Server 192.168.0.1 test.local server.test.local 192.168.0.11 example.local server.example.local 192.168.0.21 dummy.local server.dummy.local
Die Befehle führen wir mit Root-Rechten aus, z. B. nach Öffnen einer Rootshell mit sudo -i.
Zonendateien ergänzen
Für eine Bind-Konfiguration mit drei Domainnamen benötigen wir insgesamt vier Zonendateien. Eine „Forward Lookup“-Zonendatei pro Domain dient dabei der Auflösung von Namen in entsprechende IP-Adressen. In einer gemeinsamen „Reverse Lookup“-Zonendatei ordnen wir umgekehrt den Adressen Domainnamen zu.
„Forward Lookup“-Zonendateien anlegen
Analog zur Datei db.test.local erzeugen wir für die Domains example.local und dummy.local zunächst „Forward Lookup“-Zonendateien mit passenden Zugriffsrechten:
root@server:~# touch /etc/bind/db.example.local /etc/bind/db.dummy.local root@server:~# chown root:bind /etc/bind/db.example.local /etc/bind/db.dummy.local
Ohne Einträge für weitere Rechner / Subdomains neben einem Server pro Domain und dem Mailserver sehen die Zonendateien für test.local und die neuen Zonen wie folgt aus:
; Zonendatei db.test.local für Zone test.local
$TTL 604800
@ SOA server.test.local. root.test.local. (
2016062701 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Minimum
@ NS server.test.local.
@ A 192.168.0.1
@ MX 10 mail.test.local.
server A 192.168.0.1
mail A 192.168.0.2
; Zonendatei db.example.local für Zone example.local
$TTL 604800
@ SOA server.test.local. root.test.local. (
2016062701 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Minimum
@ NS server.test.local.
@ A 192.168.0.11
@ MX 10 mail.test.local.
server A 192.168.0.11
; Zonendatei db.dummy.local für Zone dummy.local
$TTL 604800
@ SOA server.test.local. root.test.local. (
2016062701 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Minimum
@ NS server.test.local.
@ A 192.168.0.21
@ MX 10 mail.test.local.
server A 192.168.0.21
Der Aufbau der „Forward Lookup“-Zonendateien db.example.local und db.dummy.local ist dem von db.test.local sehr ähnlich. Die Resource Records vom Typ SOA, NS und MX sind identisch, da alle Domains denselben Nameserver und Mailserver nutzen und der Administrator für alle Zonen die gleiche E-Mail-Adresse root@test.local hat. Nur die Resource Records vom Typ A unterscheiden sich entsprechend der weiter oben beschriebenen Zuordnung der Domainnamen und Server zu den IP-Adressen.
Es ist natürlich auch möglich, unterschiedlichen Domains dieselbe IP-Adresse zuzuweisen. Neben den A-Records sind dazu die nachfolgend behandelten PTR-Records in der „Reverse Lookup“-Zonendatei anzupassen.
„Reverse Lookup“-Zonendatei erweitern
Die „Reverse Lookup“-Zonendatei db.0.168.192 müssen wir nun noch um Resource Records vom Typ PTR für die beiden Server in den Domains example.local und dummy.local erweitern. Die komplette Datei hat dann folgenden Aufbau:
; Zonendatei db.0.168.192 für Netzwerk 192.168.0.0/24
$TTL 604800
@ SOA server.test.local. root.test.local. (
2016062701 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Minimum
@ NS server.test.local.
1 PTR server.test.local.
2 PTR mail.test.local.
11 PTR server.example.local.
21 PTR server.dummy.local.
Konfigurationsdatei ergänzen
Damit die zusätzlichen „Forward Lookup“-Zonendateien von Bind berücksichtigt werden, ergänzen wir abschließend die Konfigurationsdatei /etc/bind/named.conf.local um entsprechende zone-Definitionen:
zone "test.local" {
type master;
file "/etc/bind/db.test.local";
};
zone "example.local" {
type master;
file "/etc/bind/db.example.local";
};
zone "dummy.local" {
type master;
file "/etc/bind/db.dummy.local";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.0.168.192";
};
Bind testen
Die geänderte Konfiguration können wir mit den im Artikel zur Bind-Installation beschriebenen Tests überprüfen.
Zunächst kontrollieren wir die Syntax der Zonendateien mit named-checkzone:
root@server:~# named-checkzone test.local /etc/bind/db.test.local root@server:~# named-checkzone example.local /etc/bind/db.example.local root@server:~# named-checkzone dummy.local /etc/bind/db.dummy.local root@server:~# named-checkzone 0.168.192.in-addr.arpa. /etc/bind/db.0.168.192
Nach dem Neustart von Bind mit
root@server:~# service bind9 restart
testen wir unsere Konfiguration mit dem Programm dig:
root@server:~# dig test.local ANY root@server:~# dig example.local ANY root@server:~# dig dummy.local ANY root@server:~# dig -x 192.168.0.1
Ob die Namensauflösung auf den Clients funktioniert, können wir mit dem ping-Befehl prüfen, unter Linux z. B. mit den Aufrufen:
hans@client:~ ping -c 4 test.local hans@client:~ ping -c 4 example.local hans@client:~ ping -c 4 dummy.local