Nameserver mit MaraDNS

Es muss 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, dass es monolithisch ist und viel Speicher braucht. Inzwischen stehen einige Alternativen zur Verfügung; eine freie Alternative ist MaraDNS.

Von Hans-Joachim Baader

Vorwort

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, dass 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ässt 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.

Da dies rund zwei Jahre her ist, kann es durchaus sein, dass das Problem inzwischen behoben ist. Zu damaligen Zeitpunkt gab es jedoch noch keine neuere Version. So hatte ich allmählich genug 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.

Anforderungen

Es gibt inzwischen mehrere freie Alternativen zu BIND. Meine Anforderungen waren lediglich, dass der Server sowohl als maßgeblicher 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 konfigurieren

MaraDNS arbeitet als maßgeblicher und rekursiver Nameserver. Nicht benötigte Funktionen kann man abschalten. Derzeit habe ich ihn 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 Cron-Job getzone für die Zonen laufen lassen und dann muss 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.

/etc/maradns/mararc

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, dass 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, dass MaraDNS an allen Netzwerkschnittstellen lauschen soll. Oft ist das nicht erwünscht. In der Version 1.0.x war es jedoch noch nicht möglich, statt 0.0.0.0 eine Liste von IP-Adressen anzugeben. Damals hätte man zwei (oder mehr) getrennte Serverinstanzen laufen lassen müssen, jede mit eigener Konfigurationsdatei, in der MaraDNS jeweils an einer Netzwerkschnittstelle lauscht. Dies ist im FAQ dokumentiert. In MaraDNS 1.2 dagegen kann man ganz einfach eine durch Komma getrennte Liste von IP-Adressen angeben, z.B. bind_address = "127.0.0.1, 192.168.1.1".

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, dass alle Hosts im lokalen Netz solche Anfragen stellen können. Andernfalls könnten sie keine Internet-Hostnamen auflösen.

csv1 = {}
csv1["hjbaader.home."] = "hjbaader.home"
csv1["1.168.192.in-addr.arpa."] = "db.192.168.1"
csv1["0.168.192.in-addr.arpa."] = "db.192.168.0"
bind_address = "0.0.0.0"
chroot_dir = "/etc/maradns"
maradns_uid = 116
maradns_gid = 116
maxprocs = 10
hide_disclaimer = "YES"
no_fingerprint = 1
verbose_level = 1
zone_transfer_acl = "192.168.0/8"
ipv4_alias = {}
ipv4_alias["localhost"] = "127.0.0.0/8"
recursive_acl = "localhost,192.168.0.0/16"
random_seed_file = "/dev/urandom"
root_servers = {}
upstream_servers = {}
upstream_servers["."] = "212.110.100.250,213.133.100.100"

MaraDNS 1.2 startet neben dem eigentlichen Nameserver maradns auch einen Zonenserver zoneserver. Dieser ist nicht nur für die Zonentransfers zuständig, sondern auch für DNS über TCP. DNS-Abfragen über TCP leitet er als Proxy an den für UDP zuständigen maradns weiter. Er benutzt die gleiche Konfigurationsdatei wie maradns, wobei einige Direktiven wie zone_transfer_acl ausschließlich von ihm benutzt werden.

Ich hatte einmal unvermittelt ein Problem mit dem Zoneserver. Immer wenn er gestartet war, lieferten Anfragen an maradns keine Antworten mehr. Nach etlichem Fluchen konnte ich das Problem lösen. Die Ursache waren offenbar »unsaubere« Einträge in der Konfigurationsdatei, die jedoch ohne Fehlermeldung akzeptiert wurden.