Installation Bind9
Nach dem Neustart kann das Bind9 Paket installiert werden.
Sudo apt-get install bind9
Wer schnell zum Ziel kommen will, dem sei hier das Bind Konfiguationsscript von Virtual Aspects empfohlen. Dieses baut schnell die notwendigen Konfigurationsdateien und Zonefiles auf.
Ich werde hier auf die wichtigen Files und ihre Funktion eingehen. Alle Dateien liegen im Pfad /etc/bind.
- named.conf: Die zentrale Konfigurationsdatei. Von ihr werden weitere Konfigurationsdateien über include eingebunden. Dies dient der Übersichtlichkeit.
- named.conf.options: Wird von named.conf geladen. Hier wird das Basisverhalten von Bind definiert. So z.B. auf welchen Interfaces bind antworten soll und an wen DNS Anfragen weitergeleitet werden (Forwarders). Bei der Installation von Bind wird eine Datei dieses Namens mit Default werten abgelegt. Es empfiehlt sich, diese umzubenennen und eine eigene neu aufzubauen.
- named.conf.local: Wird von named.conf geladen. Hier werden lokale Zonen (DNS-Bereiche) definiert. Für jeden Forward- und Reverse-Zone sind hier die Datenbank Files hinterlegt, in denen die eigentlichen Adresszuordnungen definiert werden.
- named.conf.default-zones: Wird von named.conf geladen. Aufbau ähnlich wie named.conf.local, jedoch mit Zonen für localhost und broadcast.
- db.<domain>: Forward Zonefile für jede Domain
- db.<subnet>.in-addr.arpa: Reverse Zonefile für jedes Subnetz. Das Subnetz wird in umgekehrter Reihenfolge angegeben. Z.B. 10.1.20.0 hätte das Reverse-Zonenfile db.20.1.10.in-addr.arpa
Aufbau einer simplen Zone
Bind9 Zonefiles haben zahlreiche Parameter und Konfigurationsmöglichkeiten. Darauf möchte ich in diesem Artikel nicht eingehen und wir beschränken uns auf ein Minimum. Es geht schließlich um ein Homelab und nicht um einen sicherheitskritisches System.
Meine Lab-Domäne heisst “lab.local” und umfasst das Subnet 10.0.10.0/24 (Class-C Netz mit 256 Adressen). Dafür müssen wir zwei Zonenfiles anlegen. eines für Forward-Auflösung und eines für Reverse-Auflösung.
sudo touch /etc/bind/db.lab.local sudo touch /etc/bind/db.10.0.10.in-addr.arpa
Damit werden zwei leere Dateien erstellt, die wir als Zonefiles verwenden werden. Die Forward-Zonendatei heisst immer db.<domain>. Beim Namen des Reverse-Zonefiles muss man etwas aufpassen. Der Name lautet db.<Subnetz in umgekehrter Reihenfolge>.in-addr.arpa. Mein Subnetz 10.0.10.0/24 ist ein ungünstiges Beispiel, da 10.0.10 forwärts wie rückwärts gleich ist. Wäre mein Subnets beispielsweise 10.1.20.0/24, so wäre der Dateiname db.20.1.10.in-addr.arpa.
Nachdem wir die Dateien erstellt haben, werden wir uns zunächst um die Forward-Zone kümmern.
sudo nano /etc/bind/db.lab.local
Der erste Parameter ist $ORIGIN. Das ist der Name der Domäne, gefolgt von einem Punkt. Dieser Eintrag sorgt dafür, dass Anfragen um den Domänennamen ergänzt werden. Aus host01 wird host01.lab.local. Korrekte Syntax ist bei Bind ausserordentlich wichtig und der Dienst startet nicht, falls Fehler in den Konfigurations- oder Zonenfiles sind.
Der zweite Parameter beschreibt die Gültigkeit der Einträge, bzw die Aublaufdauer $TTL (time to live). Im Beispiel unten ist sie auf einen Tag eingestellt (1d).
Die ersten beiden Zeilen lauten also:
$ORIGIN lab.local. $TTL 1d
Danach folgt die SOA (start of authority) Deklaration mit Information zum Nameserver und der Hostmaster Email Adresse. Dazu noch die fortlaufende Seriennummer und Refresh- und Ablaufzeiten.
Nach der SOA Deklaration erfolgt die Angbae des Nameservers, der für diese Zone zuständig ist. Im Beispiel ist das der Hostname des Raspi dns.lab.local.
Die eigentlichen Adress-Einträge sind die sogenannten A-Records.
<host> IN A <IP>
Daneben gibt es noch Alias-Namen oder Canonical Names (CNAME). In meinem Fall ist der DNS Server gleichzeitig NTP Server. Daher zeigt der Alias ntp auf dns.lab.local. Ganz wichtig ist hier der Punkt am Ende des Namens. Daran merkt Bind, dass es sich um einen vollqualifizierten Namen handelt (FQDN) und damit nicht noch einmal die Endung der Domäne angehängt wird.
Unten ist das minimale Zonenfile der lab.local Forwardzone dargestellt.
$ORIGIN lab.local. $TTL 1d @ IN SOA localhost. root.localhost. ( 2020042901 ; Serial 1d ; Refresh 2h ; Retry 1w ; Expire 2d ; Negative Cache TTL ) IN NS dns.lab.local. ; dns IN A 10.0.10.2 ntp IN CNAME dns.lab.local. ; esx01 IN A 10.0.10.111 esx02 IN A 10.0.10.112 esx03 IN A 10.0.10.113 esx04 IN A 10.0.10.114 vc IN A 10.0.10.100
Kommentare im File beginnen mit einem Semikolon. Alles was in einer Zeile einem Semikolon folgt wird daher ignoriert. Am Ende der Eingabe speichern wir das Zonenfile mit [Ctrl] + [o] und verlassen den Editor mit [Ctrl] + [x].
Jetzt ist das Reverse-Zonenfile dran.
sudo nano /etc/bind/db.10.0.10.in-addr.arpa
Das Reverse-Zonenfile ist sehr ähnlich aufgebaut. Die Einträge der Zeiger haben folgendes Muster:
<Adresse> IN PTR <fqdn>.
Ganz wichtig auch hier der Punkt nach dem vollqualifizierten Namen. Unten sehen wir ein minimales Beispiel eines Reverse-Zonenfiles.
$ORIGIN 10.0.10.in-addr.arpa.
$TTL 1d
@ IN SOA localhost. root.localhost. (
2020042901 ; Serial
1d ; Refresh
2h ; Retry
1w ; Expire
2d ; Negative Cache TTL
)
IN NS dns.lab.local.
;
2 IN PTR dns.lab.local.
;
111 IN PTR esx01.lab.local.
112 IN PTR esx02.lab.local.
113 IN PTR esx03.lab.local.
114 IN PTR esx04.lab.local.
;
100 IN PTR vc.lab.local.
Am Ende der Eingabe speichern wir das Zonenfile mit [Ctrl] + [o] und verlassen den Editor mit [Ctrl] + [x].
Jetzt haben wir zwar die beiden Zonenfiles der Zone lab.local, aber damit diese wirksam werden, müssen wir sie Bind bekannt geben. Dazu ändern wir die Datei named.conf.local.
sudo nano named.conf.local
Wir fügen folgende Zeilen an die Konfiguration an:
zone "lab.local" {
type master;
notify no;
file "/etc/bind/db.lab.local";
};
zone "10.0.10.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/db.10.0.10.in-addr.arpa";
};
Die Änderungen speichern wir mit [Ctrl] + [o] und verlassen den Editor mit [Ctrl] + [x]. Der Bind Dienst muss nun neu gestartet werden, damit die Änderungen wirksam werden.
sudo service bind9 restart
Sollte irgendetwas mit der Syntax oder der Konfiguration nicht stimmen, so wird der Dienst nicht starten.
Zusammenfassung
Wir haben mit einfachen Mitteln einen vollwertigen DNS- und Zeitserver gebaut. Dieser kann Dank der geringen Energieaufnahme dauerhaft in Betrieb bleiben, oder vor dem Start der Lab-Umgebung aktiviert werden. Bei mir ist der DNS-Raspi an einer schaltbaren Stromleiste, gemeinsam mit den ESXi-Hosts angeschlossen. Zunächst startet der Raspi. Dessen Bootvorgang ist in der Regel abgeschlossen noch bevor das IPMI Management der Server bereit ist. Beim Start des Clusters hat dieser volle NTP- und DNS-Funktionalität.