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 Hans-Joachim Baader

Vorwort

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.

Features und ihre Folgen

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:

F UID PID PPID PRI NI VSZ RSS WCHAN STAT TIME COMMAND
1 104 29352 1 9 0 11592 3004 rt_sig Ss /usr/sbin/named -u bind

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.

Alternativen

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.

Hier kommt NSD

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.

Installation

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.

Konfiguration

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:

zone	test.com			test.com
zone	11.22.33.44.in-addr.arpa	reverse

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.