| Nameserver mit MaraDNS |
|
|
|
|
Es muß nicht länger BIND sein Lange Zeit hatte der Nameserver BIND quasi ein Monopol im Internet. Doch BIND 8 zeigte allmählich sein Alter. Durch den grundlegend unsicher geschriebenen Code gab es zahlreiche Sicherheitslücken und auch die Funktionalität war nicht mehr zeitgemäß. Das Internet Software Consortium ließ daraufhin BIND 9 schreiben, der völlig neu implementiert war und die geforderten neuen Funktionen zur Verfügung stellte. An BIND 9 kann man jedoch kritisieren, daß er monolithisch ist und viel Speicher braucht. Inzwischen stehen einige Alternativen zur Verfügung; eine freie Alternative ist MaraDNS. Von Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst
Ich betreibe meinen eigenen Nameserver für meine interne Domain »hjbaader.home«, der rund um die Uhr läuft und per DSL-Flatrate mit dem Internet verbunden ist. Schon vor einiger Zeit hatte ich festgestellt, daß der Nameserver von Zeit zu Zeit, aufhörte, Namensanfragen aufzulösen. Der Nameserver war bis jetzt »BIND 9«, und das Problem äußerte sich folgendermaßen: Ich stelle eine Anfrage, z.B. nslookup dbapp.de, und es tut sich 15 Sekunden lang nichts, dann kommt eine Timeout-Fehlermeldung. Dabei ist die Internetverbindung offen, der Nameserver läuft, und es ist auch sonst kein Problem feststellbar. Es läßt sich auch nicht debuggen, da fünf Threads von BIND laufen und man nicht weiß, welcher gerade zuständig ist. Stoppen und Neustarten des Nameservers behebt das Problem - bis zum nächsten Hänger. Ich hatte allmählich die Schnauze voll davon. Es passierte anscheinend immer dann, wenn meine DSL-Leitung stark ausgelastet war. So begann ich nach Alternativen zu suchen. Für das Verständnis dieses Artikels dürfte der Artikel Ein Beispiel zur Konfiguration des Nameservers BIND nützlich sein. Was dort bereits definiert wurde, brauche ich hier nicht mehr zu erklären. Insbesondere am Resolver, der die Client-Konfiguration darstellt, ändert sich nichts. Es gibt inzwischen mehrere freie Alternativen zu BIND. Meine Anforderungen waren lediglich, daß der Server sowohl als »authoritative« als auch als rekursiver Server arbeiten sollte. Damit schied zum Beispiel NSD aus. Reine rekursive bzw. Caching-Nameserver schieden ebenfalls aus. Damit blieben PowerDNS, Posadis und MaraDNS in der engeren Wahl. Ich entschied mich für MaraDNS, weil dieses Programm in Debian (seit 3.0 vermute ich) enthalten ist. Wichtig war für mich die Sicherheit, weniger wichtig die Performance. MaraDNS arbeitet als maßgeblicher und rekursiver Nameserver. Nicht benötigte Funktionen kann man abschalten. Derzeit habe ich ihn noch nicht als sekundären Nameserver laufen, dies sollte aber nicht weiter schwer sein. Laut FAQ hat MaraDNS keinen expliziten Support dafür, aber man kann die Konfigurationsdatei kopieren, per Cronjob getzone für die Zonen laufen lassen und dann muß man wohl MaraDNS neu starten, um die Änderungen einzulesen. Befriedigend kann das allenfalls bei kleinen Servern sein, da die Startzeit von MaraDNS proportional mit der Anzahl der einzulesenden Zonen ansteigt. Die Konfiguration beginnt in Debian mit der Datei /etc/default/maradns, die man aber nicht zu ändern braucht, wenn man nur einen Server hat. Die weitere Konfiguration findet im Verzeichnis /etc/maradns statt, wo alle Konfigurationsdateien liegen und in das der Server mit chroot wechselt. Die Haupt-Konfigurationsdatei ist /etc/maradns/mararc. Ein Beispiel für diese Datei ist im Folgenden aufgeführt. Ihre Syntax ist eine eingeschränkte Version von Python 1.5.2. Typisch für die Syntax der Datei ist, daß leere Listen angelegt werden, wie beispielsweise mit csv1 = {}, die dann mit Elementen gefüllt werden. Technisch gesehen handelt es sich hier um Hashtabellen, in Python als Dictionaries bezeichnet. Doch dieses Detail soll uns jetzt nicht weiter aufhalten. Kommentare beginnen mit einem #-Zeichen und erstrecken sich bis zum Ende der Zeile. Das folgende Listing definiert zunächst die Zonen und ordnet diesen Zonendateien zu. So wird die Zone hjbaader.home. (wichtig: der Punkt am Ende des Namens) in der Datei hjbaader.home definiert, die wie die anderen Dateien im Verzeichnis /etc/maradns abgelegt wird. Dieses Verzeichnis wird auch als chroot_dir definiert. In bind_address wird definiert, daß MaraDNS an allen Netzwerkinterfaces lauschen soll. Oft ist das nicht erwünscht. In der aktuellen Version ist es jedoch nicht möglich, statt 0.0.0.0 eine Liste von IP-Adressen anzugeben. Die Lösung ist derzeit, zwei (oder mehr) getrennte Serverinstanzen laufen zu lassen, jede mit eigener Konfigurationsdatei, in der MaraDNS jeweils an einem Netzwerkinterface lauscht. Dies ist im FAQ dokumentiert. Es soll in MaraDNS 1.2 behoben werden. Die anderen Punkte sind selbsterklärend bzw. in der Dokumentation, auch in der Manpage zu mararc, zu finden. Die Liste root_servers bleibt bei mir wie immer leer, denn für rekursive Abfragen soll niemals direkt einer der ohnehin stark belasteten Root-Server, sondern einer der Server meines Providers (upstream_servers) befragt werden. Wichtig ist noch die Zugriffserlaubnis für rekursive Anfragen: recursive_acl = "localhost,192.168.0.0/16" legt fest, daß alle Hosts im lokalen Netz solche Anfragen stellen können. Andernfalls könnten sie keine Internet-Hostnamen auflösen.
Kein Nameserver ohne Zonendateien, so auch MaraDNS. Hier kommt allerdings ein eigenes Format zum Einsatz, das etwas kompakter ist als das von BIND, im Grunde aber keine Vereinfachung darstellt, da die gleichen Angaben vorhanden sind. Auch MaraDNS kennt normale und reverse Zonen. Die normalen sind die, die Hostnamen in IP-Adressen übersetzen, die reversen leisten das Umgekehrte. In meinem Beispiel gibt es eine normale Zone, hjbaader.home, der jedoch zwei reverse zugeordnet sind, nämlich die, deren IP-Adressen mit 192.168.0 bzw. 192.168.1 beginnen. Die Zonendateien sind in der Manpage csv1 dokumentiert.
Obiges ist zunächst die normale Zone. Die ersten beiden Zeilen müssen in der Datei in einer Zeile stehen, sie wurden hier nur wegen der Lesbarkeit getrennt. Die erste Zeile enthält den SOA-Datensatz. Sie besteht wie auch die weiteren Zeilen aus mehreren Feldern, die mit dem senkrechten Strich | getrennt sind. Die neun Felder des SOA-Datensatzes haben folgende Bedeutung:
Danach folgen drei Zeilen, die mit N beginnen, die Nameserver-Definitionen. Wie bei den anderen Zeilen (Ressource Records) ist das zweite Feld die TTL in Sekunden. Die nächsten vier Zeilen beginnen mit A. Es sind Adress-Datensätze. Deren Bedeutung dürfte klar sein. Sie sagen: Der Rechnername auf der linken Seite (z.B. hades.hjbaader.home) hat die IP-Adresse auf der rechten Seite. Als Besonderheit taucht hades.hjbaader.home in zwei Zeilen auf. Das ist nichts Ungewöhnliches. Dieser Rechner hat zwei IP-Adressen. Auch das umgekehrte ist möglich, daß zwei Rechnernamen die gleiche IP-Adresse haben, daß es sich also in Wirklichkeit um denselben Rechner handelt. Für diesen Fall ist es aber auch möglich, einen CNAMEn zu vergeben. Einen solchen Datensatz, der mit C beginnt, sehen wir am Ende der Datei. Der Rechner rx (.hjbaader.home) ist auch unter dem Namen ry erreichbar. Für CNAMEs muß man keinen reversen Eintrag anlegen; zu den reversen Einträgen der A-Records kommen wir gleich. In den Zonendateien kann man einige Abkürzungen verwenden, die in der Manpage dokumentiert sind. Leider macht das Programm getzone keinen Gebrauch von diesen, sondern schreibt die Einträge komplett aus. Im folgenden sehen wir eine reverse Zone, diejenige, deren IP-Adresse mit 192.168.0 beginnt. Wie bei BIND müssen auch bei MaraDNS die IP-Adressen in umgekehrter Reihenfolge geschrieben werden, woran man dann ein .in-addr.arpa. anhängen muß.
Die ersten vier Zeilen der Datei sind wie bei der normalen Zonendatei. Darauf folgen vier Einträge, die die Umkehrung der vier A-Datensätze in der normalen Zone darstellen. Diese Datensätze nennt man PTR (von Pointer), und sie beginnen mit P. Als ich von BIND auf MaraDNS umstieg, hatte ich weder eine Ahnung, wie die Konfigurationsdateien aussehen, noch hatte ich Lust, alle Daten noch einmal einzugeben. Glücklicherweise macht MaraDNS die Migration sehr einfach. Unter Einsatz von getzone kann man alle Zonendateien transferieren, was nicht nur mit BIND, sondern auch mit den meisten (allen?) anderen Nameservern funktioniert. Zuerst muß man seine Konfigurationsdatei /etc/maradns/mararc zumindest in einer vorläufigen Version erstellen, die die Zonen definiert. Dann stellt man den anderen Nameserver so ein, daß er Zonentransfers erlaubt, sofern er noch nicht so konfiguriert ist. Nun verwendet man das von MaraDNS mitgelieferte Programm getzone für jede Zone einmal, wobei man am besten zuerst in das Verzeichnis /etc/maradns wechselt, da die Zonendateien dort auch liegen sollen. Man kann getzone zuerst einmal testen mit:
Voraussetzung ist, daß der bisherige Nameserver noch läuft, hier auf localhost. Statt 127.0.0.1 kann man natürlich auch den Hostnamen des Nameservers verwenden. Nun sollte getzone unsere künftige Zonendatei auf die Standardausgabe geben. Um sie in eine Datei zu speichern, wiederholen wir das Ganze noch einmal mit Ausgabeumleitung und machen das auch für die anderen Zonen, in meinem Fall die beiden reversen Zonen:
Nun, da die Zonen importiert sind, kann man den alten Nameserver abschalten (und später deinstallieren). MaraDNS startet man auf den meisten Systemen mit /etc/init.d/maradns start. Danach sollte man mit ps ax prüfen, ob er wirklich läuft, und auf jeden Fall die Logdatei /var/log/messages (oder das Äquivalent dazu) ansehen. MaraDNS startet nämlich auch dann, wenn eine oder mehrere Konfigurationsdateien Fehler enthalten, und schreibt dies nur ins Log! Es versteht sich von selbst, daß man nun die erfolgreiche Namensauflösung testen muß. Dazu bieten sich ping und nslookup bzw. dig an. Ein bei MaraDNS mitgeliefertes Programm ist askmara. Es erfüllt seinen Zweck für einfache Abfragen, unter Bedienbarkeit stelle ich mir aber etwas anderes vor. Will man Zonentransfers, muß man auch noch den Zoneserver mit /etc/init.d/zoneserver start starten. Und der Speicherverbrauch? Der ist nicht ganz einfach zu ermitteln, da neben dem MaraDNS-Daemon noch der zoneserver sowie zwei logger-Prozesse gestartet werden. MaraDNS selbst belegt bei mir bis zu 3,3 MB Speicher, davon aber nur 700 K RSS, das heißt, der Rest ist ausgelagert. Zoneserver begnügt sich mit 120 K RSS, die Logger nehmen 108 bzw. 236 K RSS in Anspruch. Auch zusammen ist das deutlich weniger als bei BIND. In den ersten Monaten des Betriebs von MaraDNS traten bei mir keinerlei Probleme auf. MaraDNS ist ein funktionaler, sehr zuverlässiger DNS-Server mit geringem Ressourcenverbrauch und guter Performance. Die Leistungsfähigkeit ist der von BIND äquivalent, lediglich einige erweiterte Features fehlen vielleicht noch. Statistiken bekommt man anscheinend keine, aber meines Wissens hat auch BIND in dieser Hinsicht sehr wenig zu bieten. ¡Adiós, BIND; hola, MaraDNS!
|
||||||||||||||
| < Zurück | Weiter > |
|---|