DNS entschlackt
Nichtrekursiver Nameserver mit NSD
Ein Domain-Nameserver muß nicht immer unter Bind laufen, zumal sich zeigt, daß Bind für viele Situationen unangemessen viel Speicher benötigt. Für diese Fälle kann ein Server mit NSD brauchbar sein. Die Konfiguration ist einfach, wenn man eine Konfiguration von Bind 9 übernehmen kann, sogar fast trivial.
Die Zonendateien
Wir haben festgelegt, daß die Zone test.com in der Datei /etc/nsd/test.com zu finden ist und die Zone 11.22.33.44.in-addr.arpa in der Datei /etc/nsd/reverse. Nun müssen wir diese noch erstellen.
/etc/nsd/test.com
$TTL 86400 @ IN SOA www postmaster.www ( 2004101201 10800 1800 3600000 259200 ) IN NS ns IN MX 10 www ns IN A 44.33.22.11 www IN A 44.33.22.11 @ IN A 44.33.22.11
Es könnte Ihnen aufgefallen sein, daß nirgends in der ganzen Datei der Zonenname vorkommt. Da das Symbol @ für den Zonennamen steht und zudem dieser Name an alle Namen angehängt wird, die nicht mit einem Punkt enden, kann man sich das sparen. So kann man die gleiche Datei unter Umständen für viele Zonen verwenden.
In dieser Datei haben wir der Adresse 44.33.22.11 drei Namen zugewiesen: ns (ns.test.com), www (www.test.com) und test.com selbst. ns.test.com ist der einzige Nameserver für diese Zone, der Rechner also, auf dem NSD läuft. In einer realen Konfiguration sollte man alle sekundären Nameserver für diese Zone ebenfalls als NS-Record eintragen.
Diese Zonendatei ist kompatibel mit der, die Bind 9.x erwartet. Leider nur fast. In der Datei von Bind waren zwei Zeilen anders definiert:
@ IN NS ns @ IN MX 10 www
Beachten Sie das »@« am Anfang der Zeile! Als ich diese Datei so dem NSD vorlegte, wurde sie zwar fehlerfrei compiliert, aber jede Abfrage scheiterte mit der Fehlermeldung NXDOMAIN. Wie ich darauf kam, daß das »@« zuviel war? Das Konsultieren des Mailinglisten-Archivs brachte mich darauf, weil dort jemand eine offenbar funktionierende Zonendatei gepostet hatte.
/etc/nsd/reverse
$TTL 86400 @ IN SOA www.test.com. postmaster.www.test.com. ( 2004101403 10800 1800 3600000 259200 ) IN NS ns.test.com. IN MX 10 www.test.com. 11.22.33.44.in-addr.arpa. IN PTR www.test.com.
Zur Datei /etc/nsd/reverse gibt es nicht viel zu sagen. Der Kopf der Datei ist der gleiche wie bei der normalen Zone. Dahinter dürfte eine Zeile pro verwendeter IP-Adresse genügen.
Zonen compilieren
Da NSD die Zonendefinitionen aus einer Datenbank-Datei liest, müssen wir die eben erstellten Definitionen erst einmal dort hineinbekommen. Wir können den Zonen-Compiler zonec von Hand aufrufen:
zonec -v -f /var/lib/nsd/nsd.db /etc/nsd/nsd.zones
Hierbei bedeutet das optionale Flag -v, das auch mehrmals angegeben werden kann, daß zonec mehr Ausgaben macht. -f /var/lib/nsd/nsd.db bezeichnet die Datenbank-Datei. Das letzte Argument ist die Datei mit der Zonenliste. Wenn hierbei Fehlermeldungen kommen, sind die Zonendateien zu prüfen. Viel Hilfestellung bietet der Compiler dafür nicht: Wie die Entwickler schreiben, ist es ziemlich schwierig, die Zonendateien vernünftig zu parsen, da das Format so variabel ist. Doch selbst ein erfolgreicher Durchlauf ist keine Garantie dafür, daß es funktioniert. Man muß den NSD mit diesen Zonen starten und testen, ob die gelieferten Daten stimmen.
Allerdings hätten wir uns den Aufruf von zonec auch sparen können, denn beim Start von NSD via /etc/init.d/nsd start erledigt das die Debian-Installation automatisch.
Laufender Betrieb
NSD kann als unprivilegierter Benutzer laufen, indem man die Option -u verwendet. Bei Debian ist das Standard, es wird bei der Installation gleich ein User nsd angelegt. Zusätzlich könnte man NSD noch in eine chroot-Umgebung sperren, was aber einen gewissen Aufwand bedeutet. Ob der sich lohnt, kann man anhand meines Artikels Den Nameserver BIND sicherer machen in etwa abschätzen.
NSD schreibt normalerweise nichts ins Syslog, da es die Meinung der Autoren ist, daß dies die Aufgabe anderer Programme sei. So ist auch die Statistik, die man mit der Option -s ins Syslog schreiben lassen kann, sehr schwierig zu lesen. Es wird empfohlen, das Programm dnsstat zur Analyse einzusetzen.
dnsstat lauscht am Netzwerkinterface, um den DNS-Traffic mitzubekommen. Ich will hier nicht weiter auf dnsstat eingehen, da ich es nicht zum Laufen bekommen habe. Hinweise oder gleich ein ganzer Artikel über dnsstat sind willkommen!
Mit dem Programm nsdc kann man im laufenden Betrieb Kommandos an nsd senden. Ich brauche die Kommandos hier nicht näher zu erläutern, da sie in der Manpage erklärt sind und keine Verständnisschwierigkeiten bergen. Man kann beispielsweise den Daemon stoppen, starten, die Datenbank neu erzeugen oder neu in den Daemon laden.
Zugangskontrolle
Läuft NSD als primärer Server, dann wird der Zonentransfer an die sekundären Nameserver durch den TCP-Wrapper-Mechanismus kontrolliert, sofern dieser ins Programm eincompiliert wurde. Um sicherzugehen, daß die sekundären Nameserver sich die Daten holen können, sollte man dies testen. Vom lokalen oder einem anderen Rechner ruft man nsd-xfer auf:
nsd-xfer -z test.com -f somefile servername
Sollte dies nicht funktionieren, muß man möglicherweise die Einstellungen in /etc/hosts.allow und /etc/hosts.deny kontrollieren. Der Servicename, der hier einzutragen ist, lautet axfr oder axfr-zone. Bei letzterem ist zone durch den Zonennamen zu ersetzen, in unserem Falle also ergibt sich also der Servicename axfr-test.com. (Achtung: Punkt am Ende beachten).
Fazit
Was haben wir gewonnen durch den Einsatz von NSD? Der Speicherbedarf ist von 11 bzw. 3 MB auf 2 bzw. 0,7 MB gesunken, also um rund 75 Prozent:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 5 101 4310 1 16 0 1868 740 wait4 Ss ? 0:00 /usr/sbin/nsd 1 101 4311 4310 15 0 2044 784 - S ? 0:00 /usr/sbin/nsd
NSD ist ein brauchbarer Ersatz für Bind, wenn man nur die beschriebenen Features benötigt. Geringer Speicherbedarf, Sicherheit (zum einen durch den Einsatz eines weniger verbreiteten Programmes, aber auch durch sorgfältige Programmierung) und Schnelligkeit sind seine Pluspunkte. Dürftige Dokumentation und mangelnde Fehlermeldungen des Zone-Compilers sind die Schattenseiten.
