Ubuntu 12.04 Precise Pangolin
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
BIND ist ein von der Universität Berkeley (USA) entwickelter DNS-Server, der eine hohe Verbreitung in mittleren bis großen Netzen findet. Er ist als Open Source erhältlich und wurde auf fast jedes Betriebssystem portiert. Bis heute gilt BIND als "die Referenz" unter den DNS-Servern und bildet den Grundstock des heutigen Internets. Inzwischen wurde die Entwicklung des BIND-Servers vom herstellerunabhängigen Internet Systems Consortium (ISC) übernommen. Dieser Artikel behandelt die Version 9 der Software, die bisher in allen Ubuntu-Versionen zum Einsatz kam.
Als alternativer DNS-Server für kleinere (Heim-)Netze steht auch Dnsmasq zur Verfügung, der besonders einfach konfiguriert werden kann.
Folgendes Paket ist zu installieren [1]:
bind9
mit apturl
Paketliste zum Kopieren:
sudo apt-get install bind9
sudo aptitude install bind9
Da der Server zu diesem Zeitpunkt sowieso noch keine sinnvolle Konfiguration besitzt, wird er erst einmal gestoppt:
sudo /etc/init.d/bind9 stop
Ein DNS-Server muss eine statische IP-Adresse haben [4], damit er von den Clients gefunden werden kann.
Es existiert in den universe-Quellen von Ubuntu auch ein Paket namens bind. Dieses enthält die ältere Version 8 des BIND-Servers. Unbedingt darauf achten, bind9 zu installieren.
Die Konfiguration des BIND-Servers erfolgt über das Verzeichnis /etc/bind. Sollte die Installation korrekt verlaufen sein, sollten sich hier folgende Dateien finden:
db.0 db.local named.conf zones.rfc1918 db.127 db.root named.conf.local rndc.key db.255 db.empty named.conf.options
In den Dateien, die mit named. beginnen, wird die allgemeine Funktion des Servers konfiguriert. Die db.-Dateien sind dagegen die Zonendateien, in denen die eigentlichen DNS-Daten abgelegt werden.
Wichtig ist hierbei die genaue Einhaltung der Syntax, da BIND hier extrem pingelig ist.
Wenn nur IPv4 verwendet wird, sollte der Paramter "-4" in /etc/default/bind9 unter OPTIONS="..." hinzugefügt werden. Dies steigert die Performance drastisch.
Es müssen mindestens zwei neue db.-Dateien erstellt werden. [1] Eine Datei mit dem Namen db.domainname für die Forwardlookup-Zone (diese sorgt für die Auflösung von Hostnamen in IP-Adressen) und eine Datei namens db.z.y.x für die Reverselookup-Zone (das ist die Auflösung in umgekehrter Reihenfolge, also IP-Adresse -> Hostname).
Die Datei db.domainname könnte so aussehen:
;; db.domainname ;; Forwardlookupzone für domainname ;; $TTL 2D @ IN SOA rechnername.domainname. mail.domainname. ( 2006032201 ; Serial 8H ; Refresh 2H ; Retry 4W ; Expire 3H ) ; NX (TTL Negativ Cache) @ IN NS rechnername.domainname. IN MX 10 mailserver.domainname. IN A 192.168.0.10 rechnername IN A 192.168.0.10 localhost IN A 127.0.0.1 rechner1 IN A 192.168.0.200 mailserver IN A 192.168.0.201 rechner2 IN CNAME mailserver
Ressourcen von MX-Records (in diesem Beispiel also der "mailserver") müssen immer auf einen A-Record verweisen (RFC 2181).
Besonders wichtig an dieser Stelle ist eine Leerzeile am Ende der Datei!
Das TTL
(time to live) gibt an, wie lange Informationen im Cache gültig bleiben und danach neu angefordert werden (in diesem Fall 2D
ays also 2 Tage).
Als nächstes kommt dann der SOA
(start of authority resource records), welcher folgende Werte für den Bereich der Domäne festlegt:
zone-origin
ist der vollqualifizierte Domainname (FQDN
) des primären DNS-Servers. (In diesem Fall server.domainname., der Name des Servers, den gerade konfigurieren wird.) Der Punkt am Ende ist übrigens wichtig!
zone-contact
ist die Mail-Adresse des DNS-Verwalters. Das "@" wird hier jedoch durch einen Punkt ersetzet, somit müsste hier "mail.domainname." eingetragen werden. Auch hier den Punkt am Ende nicht vergessen!
serial
ist eine Seriennummer, die der Administrator nach seinen Vorstellungen vergeben kann. Allerdings muss die Seriennummer bei jeder Änderung erhöht werden, da diese Nummer sekundären DNS-Servern als Indiz dafür dient, dass sich was geändert hat. Nach allgemeiner Konvention benutzt man deswegen die Form YYYYMMDDSS, mit YYYY=Jahr, MM=Monat, DD=Tag und SS=zweistellige Seriennummer, die bei mehreren Änderungen an einem Tag jeweils um eins erhöht wird.
Die folgenden Einträge des SOA-Abschnitts befinden sich für die meisten Fälle schon auf vernünftigen Voreinstellungen und müssen im Allgemeinen nicht angetastet werden.
refresh
gibt die Zeit in Sekunden an, die ein sekundärer Server wartet, bis er beim primären Server nachfragt, ob sich die Zonendateien verändert haben.
retry
gibt die Zeit in Sekunden an, die ein sekundärer Server wartet, bis er eine Anfrage an den primären Server wiederholt, wenn dieser auf die vorherige Anfrage nicht geantwortet haben sollte (z.B. weil er offline war).
expire
gibt die Zeit in Sekunden an, die ein sekundärer Server auf einen erfolgreichen Kontakt zum primären Server wartet, bevor er die Zonendatei für ungültig erklärt.
nx
gibt die Zeit an, während der eine negativ beschiedene DNS Anfrage ("Name Error" / "NXDOMAIN") zwischengespeichert werden soll (zwischen 0 Sekunden und 3 Stunden).
Als nächstes kommen die Einträge der DNS-Server, die für die Zone verantwortlich sind. Diese haben alle die Form
Name IN RR Wert
Der Name kann dabei weggelassen werden, in welchem Fall er aus der vorherigen Zeile übernommen wird. Namen ohne Punkt am Ende werden dabei durch den Zonen-(Domain-)namen ergänzt, Namen mit Punkt gelten als vollqualifiziert. Ein besonderer Name ist das Zeichen @, das dem Zonennamen entspricht.
RR (Resource Record) muss einer von mehreren offiziellen RR-Bezeichnungen sein und der Wert hängt von der Art des RR ab. Einige RRs:
RR | Wert | Beschreibung |
NS | FQDN eines DNS-Servers | alle primären und sekundären DNS-Server der Domain sollten einen Eintrag besitzen |
A | IP-Adresse | "normaler" Eintrag: Name -> IP |
CNAME | richtiger Name | Alias-Definition - richtiger Name muss kein FQDN sein, sollte aber kein weiterer CNAME sein |
MX | Priorität Name | Mailserver, der Mail für die Domain annimmt - Priorität muss eine Zahl sein (niedriger: zuerst probieren), Name ist der Name des Mailservers |
PTR | FQDN | umgekehrte Auflösung: IP -> Name |
Weitere Resource Records finden sich in Wikipedia oder in der Fachliteratur.
In der Datei db.z.y.x, bspw. db.0.168.192 für das Subnetz 192.168.0.0, befinden sich überwiegend die Einträge aus der db.domainname, allerdings erfolgt der Lookup nun in umgekehrter Richtung:
;; db.0.168.192 ;; Reverselookupzone für domainname ;; $TTL 2D @ IN SOA rechnername.domainname. mail.domainname. ( 2006032201 ; Serial 8H ; Refresh 2H ; Retry 4W ; Expire 2D ) ; TTL Negative Cache @ IN NS rechnername.domainname. 10 IN PTR rechnername.domainname. 200 IN PTR rechner1.domainname. 201 IN PTR rechner2.domainname.
Man beachte die PTR-Records, die für die Rückwärtsübersetzung von IP-Adressen in Namen zuständig sind. Die Zahlen in der ersten Spalte stellen dabei das letzte Byte der IP-Adresse dar. Wichtig ist, dass die übersetzten Namen FQDNs (mit Punkt am Ende) sind.
Alias-Einträge, MX-Records, etc. werden hier nicht nochmal aufgeführt.
Nun müssen die Zonendateien dem Server noch bekannt gemacht werden. Dies geschieht durch folgenden Eintrag in der Datei named.conf.local, die in der eigentlichen named.conf-Datei referenziert wird:
zone "domainname" { type master; file "/etc/bind/db.domainname"; }; zone "0.168.192.in-addr.arpa" { type master; file "/etc/bind/db.0.168.192"; };
.in-addr.arpa
ist die offizielle "Domain für IP-Adressen". Diese sind pro Byte in Subdomains aufgeteilt. 0.168.192.in-addr.arpa
ist also die Subdomain für alle Adressen von 192.168.0.0 bis 192.168.0.255. Diese Bezeichnung aus der zone-Direktive ist auch gleichzeitig das, was in den Zonendateien als @ referenziert werden kann.
Die Option master
sagt dem Server, dass er der für die Domain verantwortliche Server ist, also der primäre Server und das file
verweist lediglich noch auf die Zonendateien.
Nun kann man den Server mal probeweise starten:
sudo /etc/init.d/bind9 start
Wenn keine Fehlermeldungen in der Datei /var/log/syslog auftauchen, kann der Server mit dem Werkzeug dig getestet werden:
dig @127.0.0.1 rechnername.domainname
Als Antwort sollte dann so etwas kommen:
; <<>> DiG 9.3.2 <<>> rechnername.domainname ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54891 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;rechnername.domainname. IN A ;; ANSWER SECTION: rechnername.domainname. 172800 IN A 192.168.0.10 ;; AUTHORITY SECTION: domainname. 172800 IN NS rechnername.domainname. ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Mar 25 04:34:52 2006 ;; MSG SIZE rcvd: 92
Wenn bis hierhin alles geklappt hat, muss man nur noch allen Client-Rechnern im Netz den neuen Nameserver bekannt machen, angefangen beim Server-Rechner selber. Wenn das Paket resolvconf installiert ist, passiert das hier allerdings automatisch. Ansonsten ändert man dafür die Datei [3] /etc/resolv.conf wie folgt:
domain domainname nameserver 127.0.0.1
Auf den Clients können unterschiedliche Methoden notwendig sein. Am einfachsten funktioniert das, wenn man einen DHCP-Server einsetzt. Dann braucht man die DNS-Einstellungen nur dort verändern. Ansonsten auf jedem Client einzeln. Natürlich muss man dafür dann die richtige IP-Adresse des Servers verwenden und nicht die 127.0.0.1.
Ältere Wiki-Artikel:
Erweiterte Konfiguration - an bestimmte Netzwerkschnittstellen binden, Clientzugriff beschränken, Forwarder, Chroot-Umgebung
Sekundäre Nameserver - Nameserver spiegeln, um die Ausfallsicherheit zu erhöhen
Diese Revision wurde am 13. November 2016 22:01 von noisefloor erstellt.