| 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. Von Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst
In diesem Artikel geht es um einen Server für das DNS (Domain Name System), kurz Nameserver genannt. Ein Nameserver sorgt dafür, daß die Eingabe eines Rechner- oder Domainnamens wie »www.pro-linux.de« oder »pro-linux.de« in die zugehörige IP-Adresse übersetzt wird und umgekehrt. Der hier vorgestellte Nameserver ist für Experten gedacht, mein Artikel spricht damit die gleiche Zielgruppe an. Trotzdem versuche ich Fachbegriffe zu erklären, so daß auch weniger erfahrene Leser etwas mit diesem Text anfangen können. Generell geht man davon aus, daß ein Nameserver nicht viele Ressourcen benötigt. So sagt es jedenfalls die Dokumentation zu bind, der Nameserver-Referenzimplementierung des Internet Software Consortiums (ISC). Die Realität sieht leider anders aus. Bind enthält jedes Feature, das man sich nur ausdenken konnte, und belegt entsprechend viel Speicher:
Das bedeutet, daß rund 3 MB im Speicher liegen, gut 11,5 MB sind alloziert. Bind ist einfach groß, da es keine Plugin-Architektur hat. Glücklicherweise stellt der Code selbst mit dieser Größe inzwischen kaum noch ein Sicherheitsrisiko dar, da Bind nicht mehr als Root laufen muß (wie man oben sieht, läuft er als User bind ohne irgendwelche Rechte). Dieser Speicherverbrauch erscheint nicht sehr hoch, besonders wenn man 1 GB oder mehr Speicher hat, doch wenn der Server noch andere Dinge tun soll als nur DNS-Anfragen beantworten, kann das schon lästig werden. Denn andere Dienste wie Webserver oder MySQL arbeiten um so besser, je mehr Speicher sie haben. Es macht also Sinn, zu sparen, wo man kann. Bis vor wenigen Jahren gab es keine mir bekannte freie Alternative zu Bind. Doch inzwischen hat sich einiges getan. Die Monokultur von Bind, die in Verbindung mit dem veralteten Code zu schweren Sicherheitsproblemen führte, hat die Entwicklung wohl auch beflügelt. Grundsätzlich gibt es zwei Arten von Nameservern: rekursive und nichtrekursive. Nichtrekursive sind einfacher: Sie beantworten Anfragen zu den Zonen, für die sie konfiguriert sind, und liefern auf alle anderen Anfragen lediglich einen Fehlercode (»Domain unbekannt« oder ähnliches). Solche Nameserver werden im Englischen auch als »authoritative« für ihre Zonen bezeichnet. Ein entsprechendes deutsches Wort existiert nicht. Man könnte höchstens sagen, daß diese Server »maßgeblich« für ihre Zonen sind. Wir können aber auch einfach von nichtrekursiven Nameservern sprechen, aber gelegentlich werde ich auch den Ausdruck »maßgeblich« gebrauchen. Rekursive Nameserver dagegen versuchen jede Anfrage zu beantworten. Da sie selbst entweder gar keine oder nur wenige Zonen kennen, müssen sie die meisten Anfragen an andere Server weiterleiten. Sie agieren damit gleichzeitig als Proxy, was in vielen Netzstrukturen sehr nützlich ist. Meistens verfügen sie auch über einen Cache für die Ergebnisse. Dieser wird im RAM gehalten und trägt damit natürlich auch zu erhöhtem Speicherbedarf bei. Vielleicht gibt es doch noch eine dritte Art von Nameservern, die aber nur für Domain-Registrare von Interesse sind: delegierende. Diese liefern auf Anfragen keine direkte Antwort, sondern lediglich einen Verweis auf die Nameserver, die maßgeblich für die angefragte Zone sind. Freie Nameserver gibt es mittlerweile in allen Variationen: Nichtrekursive, rekursive und solche, die alles können. Teilweise verfügen sie auch über eine Plugin-Architektur. Manche benutzen Zonendateien, die kompatibel mit denen von Bind sind, andere benutzen andere Methoden der Zonendefinition und -speicherung. Wenn man keinen rekursiven Nameserver benötigt und sowohl auf Sicherheit als auch auf niedrigen Ressourcenverbrauch Wert legt, dann bietet sich NSD als eine Möglichkeit an. Nützlich ist ein nichtrekursiver Nameserver dann, wenn man die rekursive Auflösung einem anderen Server im eigenen Netz oder einem öffentlichen Nameserver überlassen will. In der Regel sollte es nicht notwendig sein, NSD aus den Quellen zu compilieren. Es bleibt natürlich jedem unbenommen :-) Ich ziehe die Distributions-Pakete vor, wenn es solche gibt. In Debian Unstable ist es enthalten, und es genügt das Kommando apt-get install nsd zur Installation. In Debian Woody ist NSD allerdings noch nicht enthalten. NSD besteht aus mehreren einzelnen Programmen. nsd ist der eigentliche Nameserver, der als Daemon läuft. nsdc ist ein Skript, mit dem man NSD steuern kann. zonec ist der Zonencompiler, der die Zonendateien in ein Datenbankformat wandelt. Offenbar hat man diesen vom eigentlichen Daemon separiert, damit dieser weniger Code enthält und die Zonen beim Start schneller einlesen kann. nsd-notify ist ein Hilfsprogramm, das sekundäre Server über Änderungen in den Zonen benachrichtigt. nsd-xfer schließlich sorgt für den Zonentransfer, wenn NSD als sekundärer Server läuft. Dieses Programm stammt nicht von NSD, sondern wurde vom Debian-Maintainer aus dem Bind 8-Paket übernommen, wo es als named-xfer enthalten ist. Daß NSD primär für BSD-Systeme geschrieben wurde, merkt man nicht nur an der Lizenz, sondern auch daran, daß für alle Programme Manpages vorhanden sind. Generell ist die Dokumentation aber spärlich und für Experten gerade noch ausreichend. NSD besitzt eine Konfigurationsdatei, eine Liste der konfigurierten Zonen und die Zonendateien selbst. Die Konfigurationsdatei ist bei Debian /etc/default/nsd. Die Lage der Datei ist in dem Daemon wohl eincompiliert und nicht änderbar. Alles andere ist dagegen änderbar. In der Konfigurationsdatei machte ich nur eine Änderung, die auch nicht unbedingt nötig ist: Ich fügte die Option -s 3600 zu den Startoptionen von NSD hinzu. Damit wird einmal pro Stunde (alle 3600 Sekunden) eine Statistik ins Syslog geschrieben. Als nächstes ist die Liste der konfigurierten Zonen zu bearbeiten. Dazu öffnet man die Datei /etc/nsd/nsd.zones. Nehmen wir an, wir haben nur eine primäre Zone test.com, die nur eine IP-Adresse 44.33.22.11 besitzt. Dann benötigen wir folgende zwei Zeilen:
Am Anfang jeder Zeile muß immer zone stehen. Die zweite Spalte ist der Zonenname. In der zweiten Zeile ist dies die bekannte in-addr.arpa Domain, die für das Reverse Mapping sorgt. Die dritte Spalte enthält den Dateinamen der zugehörigen Zonendatei - hier haben wir die Zone test.com in der Datei test.com gespeichert, und die reverse Zone 11.22.33.44.in-addr.arpa in der Datei reverse. Man kann die Dateinamen als absolute Pfade angeben oder so wie hier relativ zu dem Verzeichnis, das in der Variablen configdir der Konfigurationsdatei /etc/default/nsd angegeben ist. Bei Debian liegen die Zonedateien daher standardmäßig in /etc/nsd. 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.
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:
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.
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. 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. 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. 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). 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:
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.
Lizenz Dieser Text unterliegt der Creative Commons ShareAlike License. Freie Verbreitung in modifizierter oder unmodifizierter Form ist erlaubt; Modifikationen müssen ebenfalls unter dieser Lizenz vertrieben werden. |
||||||||||||||||||||||||||||
| < Zurück | Weiter > |
|---|