FreeBSD als DNS-Server
Domain Name Service
Der Domain Name Service übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.
Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die /etc/hosts (unter Windows die %WINDIR%\system32\drivers\etc\hosts) editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die /etc/hosts auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.
Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. FreeBSD nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.
Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!
Wie komme ich zu einer Domäne
Wenn man keine eigene Domäne registriert hat, kann man die Topleveldomäne .internal nutzen, um Kollisionen mit bestehenden Domänen zu vermeiden. Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
- Ionos.de
- Internic.at
- Domain.com - kein IPV6!
Aufbau einer Domäne
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. cmoser.org ist die Domäne cmoser in der Toplevel Domäne org.
Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. cmoser.org ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.
Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter /usr/local/etc/namedb/primary für primäre Zonen, /usr/local/etc/namedb/secondary für Sekundärzonen und /usr/local/etc/namedb/dynamic für dynamische Zonen.
Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel FreeBSD als DHCP-Server werde ich darauf näher eingehen.
Primäre Zonen
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.
Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.
Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.
LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.
Sekundäre Zonen
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.
Installation und Konfiguration von BIND
Die für die Installation von BIND benötigten Pakete sind bind918 und bind-tools. Diese lassen sich einfach mit pkg installieren.
root@rpi# pkg install -y bind918 bind-tools
Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der /etc/rc.conf aktivieren.Die Erstellung des rndc-Schlüssels übernimmt das Service-Script automatisch. Der Service heißt named.
root@rpi# sysrc named_enable=YES
Der Service muss noch gestartet werden, damit er aktiv ist und die rndc-Schlüssel-Datei erzeugt wird.
root@rpi# service named start
Konfiguration
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen rndc-Schlüssel.
root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key
Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei /usr/local/etc/namedb/named.conf importieren.
... include "/usr/local/etc/namedb/meinedomain.de.key"; ...
Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei /usr/local/etc/namedb/named.conf. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der BIND9 Referenz.
Als Erstes suchen wir den Eintrag listen-on in den options und fügen hier den localhost (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
options {
...
listen-on { 127.0.0.1; 192.168.1.254; };
...
};
Wer ein IPv6 Netzwerk betreibt, gibt mit der Option listen-on-v6 noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert any erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
options {
...
listen-on-v6 {
fe80::2;
};
...
};
Der nächste Eintrag in den options ist der des Forwarders. In den Eintrag forwarders tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen.
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
options {
...
forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};
...
};
Meine Quelle und weitere DNS-Server findet ihr auf https://www.kuketz-blog.de/empfehlungsecke/#dns.
Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
... include "/usr/local/etc/namedb/meinedomain.de.key"; ...
Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden. Entweder mit:
# service named restart
Oder:
# rndc reconfig
Primäre Zonen
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein. In diesem Beispiel ein statische Zone, die keine dynamischen Updates erfahern darf.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};
Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit nsupdate oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option allow-update hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};
Sekundäre Zonen
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der /usr/local/etc/namedb/named.conf wie folgt aus.
zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};
Konfiguration überprüfen und neu laden
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit named-checkconf überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit rndc reconfig kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
# named checkconf # rndc reconfig
Erstellen der Zonendatei
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem SOA (Start Of Authority) Eintrag.
Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus:
$TTL 3D
Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.
Ein Beispiel SOA-Eintrag sieht wie folgt aus:
@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching
Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. mkzone
Erstellen der Forward Lookup Zone
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.
Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!! Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
@ IN NS ns1.meinedomain.de.
Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
@ IN MX 30 mail.meinedomain.de.
Dann sind da noch die Adresseinträge. Diese werden mit A für IPv4 bzw. AAAA für IPv6, gefolgt von der Adresse, angegeben.
ns1 IN A 192.168.1.254 ns1 IN AAAA fe80::2
Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
drucker IN CNAME printer.meinedoamin.de.
Eine komplette Zone könnte wie folgt aussehen:
$ORIGIN meinedomain.de. $TTL 3D @ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. ( 6 ; Serial 1H ; Refresh 1H ; Retry 1W ; Expire 1H ) ; Negative Caching TTL @ IN NS ns1.meinedoamin.de. @ IN NS ns2.meinedomain.de. @ IN MX 10 mail1.meinedomain.de. @ IN MX 20 mail2.meinedoamain.de. @ IN A 192.168.1.1 @ IN AAAA fe80::f435:344f:fe7f:8992 ; Nameserver ns1 IN A 192.168.1.254 ns1 IN AAAA fe80::1 ns2 IN A 192.168.1.253 ns2 IN AAAA fe80::2 ; Mailserver mail1 IN A 192.168.1.251 mail1 IN AAAA fe80::f435:344f:fe7f:f345 mail2 IN A 192.168.1.250 mail2 IN AAAA fe80::f435:344f:fe6f:f456 ; LAN router IN A 192.168.1.1 router IN AAAA fe80::2 server1 IN A 192.168.1.241 server1 IN AAAA fe80::3 server2 IN A 192.168.1.240 server2 IN AAAA fe80::4 printer IN A 192.168.1.2 printer IN AAAA fe80::1234:5678:9abc:1 ; Alias drucker1 IN CNAME printer1.meinedomain.de.
Erstellen einer Reverse Lookup Zone
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum in-addr.arpa, im Falle von IPv4 bzw. ip6.arpa angegenben. Wie z.B: 1.168.192.in.addr.arpa bzw. 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa, im IPv6 Netzwerk fe80:0:0:0:x:x:x:x.
Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.
In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
1 IN PTR router.meinedomain.de.
In der IPv6 Zone:
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.
Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3D
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL
; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.
; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.
Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 3D
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum
; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de
; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de
; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.
Bearbeiten von Zonen
Zonen lassen sich manuell, mit rndc oder dynamisch, mit nsupdate, bearbeiten.
Zonen manuell editieren
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug rndc.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet. Das Einfrieren funktioniert nur bei dynamischen Zonen!
# rndc freeze 1.168.192.in-addr.arpa
Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
# vi /usr/local/etc/namedb/dynamic/1.168.192.in-addr-arpa
Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen. Das Auftauen von Zonen funktioniert nur bei dynamischen Zonen.
# rndc thaw 1.168.192.in-addr.arpa
Will man eine Zone einfach nur neu laden, lässt sich das mit rndc reload bewerkstelligen.
# rndc reload meinedomain.de
Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines NS-Eintrags oder das Vergessen des Adresseneintrags des Nameservers, wenn dieser sich in derselben Zone befindet.
Zonen überprüfen
Mit named-checkzone lassen sich manuell editierte Zonen auf Fehler überprüfen. Das Tool gibt die Art des Fehlers und die jeweilige Zeilennummer an. <named-checkzone> übergibt man als Argumente den Zonennamen und den Pfad der Zonendatei.
named-checkzone meinedomain.de /usr/local/etc/namedb/primary/meinedomain.de