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.
Die Zonendateien
Kein Nameserver ohne Zonendateien, so auch MaraDNS. Hier kommen allerdings eigene Formate zum Einsatz, die etwas kompakter sind als das von BIND. Im Grunde stellen sie aber keine Vereinfachung dar, da die gleichen Angaben vorhanden sind. MaraDNS 1.0 unterstützte nur das Format csv1, MaraDNS 1.2 zusätzlich csv2. Vorhandene Zonen im Format csv1 können unverändert weiter verwendet werden.
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.
Shjbaader.home.|86400|dns1.hjbaader.home.| postmaster@dns1.hjbaader.home.|2004061301|10800|1800|3600000|259200 Nhjbaader.home.|86400|dns1.hjbaader.home. Nhjbaader.home.|86400|dns2.hjbaader.home. Nhjbaader.home.|86400|dns3.hjbaader.home. @hjbaader.home.|86400|10|hades.hjbaader.home. Ahades.hjbaader.home.|86400|192.168.0.1 Ahell.hjbaader.home.|86400|192.168.0.99 Ahades.hjbaader.home.|86400|192.168.1.1 Arx.hjbaader.home.|86400|192.168.1.99 Cry.hjbaader.home.|86400|rx.hjbaader.home.
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:
- Domain-Name
- TTL (Time to live) in Sekunden
- Origin, der Name des primären Nameservers
- Email-Adresse dieser Domain. Laut Manpage sollte diese ohne abschließenden Punkt, also nicht in dem Format sein, das BIND erwartet. Die Manpage ist falsch!
- Seriennummer der Domain. Die Seriennummer ist eine willkürliche Zahl, die bei jeder Änderung hochgezählt werden sollte. Eine gute Möglichkeit ist die hier gezeigte Konvention, das Datum der Änderung (20040613) und eine laufende Nummer aus zwei Ziffern, beginnend mit 01, zu verwenden.
- Refresh-Dauer in Sekunden
- Retry-Anzahl
- Expire (Gültigkeitsdauer in Sekunden)
- Minimale (Default-) TTL in Sekunden
Danach folgen drei Zeilen, die mit N beginnen, die Nameserver-Definitionen. Es können beliebig viele Nameserver definiert werden. 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, dass zwei Rechnernamen die gleiche IP-Adresse haben, dass 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 CNAMEn muss man keinen reversen Eintrag anlegen; zu den reversen Einträgen der A-Records kommen wir gleich. Die mit @ beginnende Zeile definiert hades als Mailserver mit Priorität 10. Je niedriger die Zahl, desto höher die Priorität. Üblich ist es, als höchste Priorität 10 zu verwenden und in Zehnerschritten niedrigere Prioritäten zu vergeben.
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 muss.
S0.168.192.in-addr.arpa.|86400|dns1.hjbaader.home.| postmaster@dns1.hjbaader.home.|2003090101|10800|1800|3600000|259200 N0.168.192.in-addr.arpa.|86400|dns1.hjbaader.home. N0.168.192.in-addr.arpa.|86400|dns2.hjbaader.home. N0.168.192.in-addr.arpa.|86400|dns3.hjbaader.home. P1.0.168.192.in-addr.arpa.|86400|hades.hjbaader.home. P99.0.168.192.in-addr.arpa.|86400|hell.hjbaader.home. P1.1.168.192.in-addr.arpa.|86400|hades.hjbaader.home. P99.1.168.192.in-addr.arpa.|86400|rx.hjbaader.home.
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.
Um csv2 zu nutzen, ersetzt man in obiger Datei mararc csv1 durch csv2 und ändert das Format. Die Zonendatei vereinfacht sich normalerweise und würde bei mir dann so aussehen:
% mx 10 hades.% hades.hjbaader.home. +86400 A 192.168.0.1 hell.hjbaader.home. +86400 A 192.168.0.99 hades.hjbaader.home. +86400 A 192.168.1.1 rx.hjbaader.home. +86400 A 192.168.1.99 ry.hjbaader.home. +86400 CNAME rx.hjbaader.home.
Der SOA-Datensatz sowie die Nameserver-Daten sind optional und werden aus den anderen Angaben automatisch erstellt. Man kann sie auch explizit definieren, was zumindest dann nötig ist, wenn die automatischen Einträge falsch sind. Auch das Format des MX-Datensatzes ändert sich; das Prozentzeichen kann in allen Daten für die aktuelle Domain verwendet werden.
Umstieg von BIND
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 muss 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, dass 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:
getzone hjbaader.home 127.0.0.1
Voraussetzung ist, dass 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:
getzone hjbaader.home 127.0.0.1 > hjbaader.home getzone 0.168.192.in-addr.arpa. 127.0.0.1 > db.192.168.0 getzone 1.168.192.in-addr.arpa. 127.0.0.1 > db.192.168.1
