Um Rechner in einem Netzwerk mit Domainnamen wie client.test.local statt IP-Adressen wie 192.168.0.101 ansprechen zu können, ist eine Zuordnung von Namen und Adressen erforderlich. Diese Zuordnung kann im einfachsten Fall durch Einträge in einer Datei, unter Linux z. B. /etc/hosts, erfolgen. Nachteilig ist bei diesem Verfahren, dass die Datei auf jedem Client-Rechner vorhanden sein muss und bei Änderungen alle Dateien zu aktualisieren sind.
Sinnvoll ist in Netzwerken mit mehr als einer Handvoll Rechnern der Einsatz eines DNS(„Domain Name System“)-Servers zur Namensauflösung. Dieser wird zentral eingerichtet und administriert.
Nachfolgend werden wir den DNS-Server / Nameserver Bind installieren und konfigurieren. Wir setzen Bind dabei nur für die Auflösung von Domainnamen aus unserem lokalen Netzwerk ein. Ein externer Zugriff aus dem Internet wird nicht eingerichtet. Eine ausführliche Dokumentation zu Bind ist das BIND 9 Administrator Reference Manual.
Voraussetzungen
Wir haben unseren Server z. B. gemäß der Anleitung zur Basisinstallation für Ubuntu Server 14.04 im lokalen Netzwerk 192.168.0.0/24 installiert und durch Updates / Upgrades auf den neuesten Stand gebracht. Der Server hat die IPv4-Adresse 192.168.0.1, der Router für die Internetverbindung die Adresse 192.168.0.254. Unsere Rechner haben feste IP-Adressen, das DHCP („Dynamic Host Configuration Protocol“) ist nicht aktiviert. Die Befehle führen wir mit Root-Rechten aus, z. B. nach Öffnen einer Rootshell mit sudo -i.
DNS-Server Bind installieren
Wir installieren den DNS-Server Bind mit folgender Anweisung auf unserem Server:
root@server:~# apt install bind9
Erreichbarkeit auf IPv4 beschränken
In der Standardkonfiguration löst Bind Domainnamen für die beiden Protokolle IPv4 und IPv6 auf. Falls wir ins unserem lokalen Netzwerk nur IPv4 verwenden und kein IPv6 benötigen, sollten wir in der Datei /etc/default/bind9 die Startoptionen ändern:
... #OPTIONS="-u bind" OPTIONS="-4 -u bind" ...
Dies kann die Arbeit von Bind deutlich beschleunigen.
Zusätzlich passen wir den Eintrag listen-on-v6 in der Optionsdatei /etc/bind/named.conf.options wie folgt an:
options {
...
//listen-on-v6 { any; };
listen-on-v6 { none; };
...
};
Optionsdatei anpassen
In der Optionsdatei /etc/bind/named.conf.options fügen wir im options-Block folgende Optionen hinzu:
options {
...
listen-on { 192.168.0.1; };
forwarders { 8.8.8.8; 8.8.4.4; };
forward only;
};
Die erste Option beschränkt die Namensauflösung auf Anfragen an die Adresse 192.168.0.1 und somit auf Clients unseres lokalen Netzwerks 192.168.0.0/24. Das ist sinnvoll, falls der Server beispielsweise gleichzeitig als Gateway arbeitet und über mehrere Netzwerkkarten/-interfaces verfügt.
Mit der zweiten und dritten Option werden Namen, die nicht von Bind aufgelöst werden können, d. h. in der Regel Anfragen, die nicht in das lokale Netz gehen, direkt an die DNS-Server 8.8.8.8 und 8.8.4.4 von Google weitergeleitet.
Da unser Server nicht aus dem Internet erreichbar ist, ist eine Einschränkung des Client-Zugriffs z. B. mit allow-query { 192.168.0.0/24; }; nicht notwendig. Die Weitergabe von Zoneninformationen an andere DNS-Server müssen wir ebenfalls nicht beschränken oder mit der Option allow-transfer { none; }; unterbinden.
Zonendateien anlegen
Der Hauptteil der Konfiguration von Bind wird in den Zonendateien vorgenommen. Für unser lokales Netzwerk benötigen wir zwei Zonendateien, die wir im Verzeichnis /etc/bind anlegen. In der Datei db.test.local konfigurieren wir die „Forward Lookup“-Zone zur Auflösung von Rechnernamen in IP-Adressen, in der Datei db.0.168.192 die entsprechende „Reverse Lookup“-Zone für die Auflösung von IP-Adressen in Rechnernamen.
„Forward Lookup“-Zonendatei
Zunächst erzeugen wir die „Forward Lookup“-Zonendatei db.test.local mit den passenden Zugriffsrechten:
root@server:~# touch /etc/bind/db.test.local root@server:~# chown root:bind /etc/bind/db.test.local
Für den vereinfachten Fall eines Netzwerks mit einem Server server und nur einem Client client reichen folgende Einträge in db.test.local aus:
$TTL 604800
@ SOA server.test.local. root.test.local. (
2015082401 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Minimum
@ NS server.test.local.
@ A 192.168.0.1
server A 192.168.0.1
client A 192.168.0.101
Die Zonendatei besteht im wesentlichen aus sogenannten „Resource Records“, die zusammen die DNS-Zone, in unsererem Fall die Domain test.local, komplett definieren. Die Reihenfolge der Resource Record-Angaben spielt dabei keine Rolle. Eine detaillierte Referenz findet sich in RFC 1035: Domain Names – Implementation and Specification der Internet Engineering Task Force IETF.
Mit der $TTL(„Time to Live“)-Anweisung am Anfang legen wir global fest, wie lange die Resource Records gültig sind. In unserem Beispiel verbleiben die Informationen 604800 Sekunden = 1 Woche im Cache des anfragenden Clients oder eines anderen anfragenden DNS-Servers. Dieser Wert kann innerhalb eines Resource Records individuell überschrieben werden.
Die Resource Records haben allgemein das Format Name TTL Klasse Typ Daten. Den optionalen Eintrag TTL haben wir weggelassen, so dass für jeden Resource Record die globale Einstellung 604800 Sekunden gilt. Die optionale Klasse ist bei allen Resource Records der Default-Wert IN und muss daher ebenfalls nicht angegeben werden.
Der erste Resource Record vom Typ SOA („Start of a Zone of Authority“) muss genau einmal in der Zonendatei vorkommen und enthält die wesentlichen Informationen über die Zone. Das @-Zeichen am Anfang dient als Platzhalter für den Zonennamen, bei uns also test.local. Die Daten bestehen aus dem Nameserver server.test.local, der E-Mail-Adresse des Administrators root@test.ibf.local, bei der das @-Zeichen durch einen Punkt ersetzt ist, der Seriennummer und verschiedenen eingeklammerten Zeitangaben. Die zusätzlichen Punkte am Ende des Nameservers und der E-Mail-Adresse kennzeichnen die Angabe eines vollqualifizierten Domainnamens FQDN („Fully Qualified Domain Name“). Eine Besonderheit ist, dass der SOA-Record auf mehrere Zeilen verteilt ist und wir daher Klammern verwenden müssen. Kommentare wie z. B. Serial werden mit einem Semikolon abgetrennt.
Falls wir neben unserem (primären) DNS-Server einen oder mehrere sekundäre DNS-Server einsetzen, müssen wir die Seriennummer Serial bei jeder Änderung der Zonendatei erhöhen. Hiermit signalisieren wir sekundären DNS-Servern, dass sie einen Zonentransfer durchführen sollen, bei dem die aktuellen Zonendaten mit dem primären DNS-Server abgeglichen werden. Ein gebräuchliches Schema für die Seriennummer ist yyyymmddvv, wobei yyyymmdd für das Datum im Format Jahr yyyy, Monat mm und Tag dd und vv für die unterschiedlichen Dateiversionen eines Tages stehen.
Die Werte für Refresh, Retry, Expire und Minimum entsprechen wie der Eintrag $TTL den Vorgaben aus der Beispieldatei /etc/bind/db.local und werden in RFC 1035 genauer beschrieben.
Der zweite Resource Record vom Typ NS („Authoritative Name Server“) muss mindestens einmal in der Zonendatei enthalten sein. Hier hinterlegen wir den FQDN des Nameservers server.test.local unserer Zone test.local, wie beim SOA-Record mit einem zusätzlichen Punkt am Ende.
Die weiteren Resource Records sind jeweils vom Typ A („Host Address“) und können in beliebiger Anzahl vorkommen. Mit ihnen ordnen wir dem Zonennamen test.local (Platzhalter @) und den Rechnern server und client in unserem lokalen Netzwerk die IP-Adressen 192.168.0.1, 192.168.0.1 und 192.168.0.101 zu. Für die Einträge server und client müssen wir nicht die FQDN benutzen, da Namen ohne Punkt am Ende automatisch durch den Zonennamen ergänzt werden.
Falls es in unserem lokalen Netz einen Mail-Server mail.test.local mit der IP-Adresse 192.168.0.2 gibt, ergänzen wir die „Forward Lookup“-Datei noch um 2 Einträge:
... @ MX 10 mail.test.local. mail A 192.168.0.2 ...
Der Resource Record vom Typ MX („Mail Exchange“) enthält einen ganzzahligen Wert für die Priorität des Mail-Servers, hier 10, und seinen Domainnamen mail.test.local. Beim Einsatz mehrerer Mail-Server werden diese in der Reihenfolge steigender Prioritätswerte genutzt. Da der Domainname des MX-Records auf einen A-Record verweisen muss, definieren wir diesen ensprechend in der nächsten Zeile. Der Mail-Server kann natürlich auch identisch mit unserem Server sein. In diesem Fall ersetzen wir den Eintrag 192.168.0.2 durch 192.168.0.1. Unser Server wäre dann unter server.test.local und mail.test.local ansprechbar.
„Reverse Lookup“-Zonendatei
Als zweite Datei legen wir die „Reverse Lookup“-Zonendatei db.0.168.192 mit den entsprechenden Berechtigungen an:
root@server:~# touch /etc/bind/db.0.168.192 root@server:~# chown root:bind /etc/bind/db.0.168.192
Die „Reverse Lookup“-Zonendatei ist ähnlich aufgebaut wie die „Forward Lookup“-Zonendatei db.test.local. Für unser Beispiel mit Mail-Server sieht sie folgendermaßen aus:
$TTL 604800
@ SOA server.test.local. root.test.local. (
2015082401 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Minimum
@ NS server.test.local.
1 PTR server.test.local.
2 PTR mail.test.local.
101 PTR client.test.local.
Statt der A-Records für die Auflösung von Namen in IP-Adressen werden Resource Records vom Typ PTR („Pointer“) für die umgekehrte Zuordnung von IP-Adressen zu vollqualifizierten Domainnamen verwendet. Die IP-Adressen notieren wir hierbei nicht vollständig, sondern nur ihren Hostanteil (d. h. den letzten Block) ohne den Netzanteil (die ersten 3 Blöcke) 192.168.0.. MX-Records werden in der „Reverse Lookup“-Zonendatei nicht angegeben.
Konfigurationsdatei ergänzen
Die Zuordnung der Informationen aus den beiden Zonendateien erfolgt in der Konfigurationsdatei /etc/bind/named.conf.local, die bereits während der Installation von Bind angelegt wird. Jede Zonendatei wird dabei mit Hilfe einer zone-Definition eingebunden, die unterschiedliche Optionen beinhalten kann:
...
zone "test.local" {
type master;
file "/etc/bind/db.test.local";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.0.168.192";
};
Mit der Option type legen wir unseren Server als primären DNS-Server (master) fest. Mit file ordnen wir der Zone eine Zonendatei zu. Die in der zweiten Zonenendefinition verwendete in-addr.arpa-Domäne ist eine spezielle Domäne für „Reverse Lookups“ von IP-Adressen. Für den Netzanteil einer Adresse gibt es hierbei pro Block eine Subdomain-Ebene, die in umgekehrter Reihenfolge notiert werden. Für den Adressbereich 192.168.0.0 – 192.168.0.255 unseres IPv4-Netzwerks ist die Subdomain somit 0.168.192.in-addr.arpa. Ausführlichere Informationen enthält z. B. RFC 1035.
Bind testen
Vor dem Neustart von Bind überprüfen wir die Zonendateien mit dem Programm named-checkzone, das zusammen mit Bind installiert wird, auf Syntax- und Integritätsfehler:
root@server:~# named-checkzone test.local /etc/bind/db.test.local root@server:~# named-checkzone 0.168.192.in-addr.arpa. /etc/bind/db.0.168.192
Nachdem eventuelle Fehler behoben sind, starten wir Bind neu:
root@server:~# service bind9 restart
Wie den Clients müssen wir auch unserem Server noch den neuen DNS-Server mitteilen. Hierzu ändern wir den dns-nameservers-Eintrag in der Datei /etc/network/interfaces:
... #dns-nameservers 8.8.8.8 8.8.4.4 dns-nameservers 192.168.0.1 8.8.8.8 8.8.4.4 ...
Damit die geänderten Einstellungen wirksam werden, starten wir den Netzwerk-Service neu:
root@server:~# /etc/init.d/networking restart
Nun sollten wir unsere Domain mit ping erreichen können:
root@server:~# ping -c 4 test.local
Falls dies nicht funktioniert, müssen wir die Netzwerkschnittstelle, hier eth0, zunächst stoppen und danach neu starten:
root@server:~# ifdown eth0 && ifup eth0
eth0 ist bei Bedarf durch den entsprechenden Eintrag für die Netzwerkschnittstelle in /etc/network/interfaces zu ersetzen.
Abschließend testen wir unsere Konfiguration mit dem Programm dig („Domain Information Groper“), das diverse Informationen von DNS-Servern abfragt:
root@server:~# dig test.local ANY root@server:~# dig -x 192.168.0.1
Mit dem ersten Aufruf werden alle (Abfrageoption ANY) Resource Records der „Forward Lookup“-Zone ausgegeben. Der zweite Aufruf mit der Option -x liefert die Resource Records der „Reverse Lookup“-Zone.
Clients konfigurieren
Für die betriebssystemabhängige Client-Konfiguration werden in der Regel folgende Daten benötigt:
- DHPC: deaktiviert
- IPv4-Adresse: 192.168.0.xxx
- Subnetzmaske 255.255.255.0
- Gateway: 192.168.0.254
- Nameserver: 192.168.0.1
- Weitere Nameserver: 8.8.8.8, 8.8.4.4
Details finden sich in der Dokumentation des jeweiligen Betriebssystems.
Zum Testen nutzen wir ping, unter Linux beispielsweise mit dem Aufruf:
hans@client:~ ping -c 4 test.local
Unter Windows geben wir in der Eingabeaufforderung entsprechend ein:
C:\Windows\System32>ping test.local