3400

Fünf Jahre hat es gedauert, bis Ende März die zehnte Major Release des Nameservers Bind fertig war. Die ist ein kompletter Rewrite des DNS-Servers – mit modularem Aufbau und neuen Konfigurationstools. Allerdings eignet sie sich zurzeit nicht für den Einsatz in Unternehmen.

Der Nameserver Bind genießt einen durchwachsenen Ruf. Zwar betreibt er einen Großteil der DNS-Server im Web, doch altgediente Administratoren erinnern sich – mit einer Mischung aus Melancholie und Schrecken – an den problematischen Umstieg von Bind 4 auf Bind  8: Zwar blieben die Zonendateien fast identisch, aber die Konfiguration fand sich nicht mehr in der Datei »named.boot« , sondern auf einmal in der »named.conf« . Deren Format enthielt plötzlich Klammern und Semikola, die vorher nicht da waren. Hinzu kam, dass Bind 8 und sein Nachfolger mehr Konfigurationsoptionen erlaubten, für die sich das alte Format als nicht ausreichend erwies.

Fünf Jahre später

Nach fünf Jahren Entwicklungszeit (Abbildung 1) kommt jetzt Bind 10 und bringt für die Admins einen noch größeren Umbruch, da sich nicht nur die Konfiguration, sondern auch die Architektur grundlegend geändert hat. SQlite-Datenbanken ersetzen die Datei »named.conf« , Zonen konfiguriert der Admin zwar über die altbekannten Zonefiles, im laufenden Betrieb sind sie jedoch ebenfalls in SQlite abgespeichert.

Abbildung 1: 2008 begonnen, 2013 fertiggestellt – alles im Plan bei Bind 10?

Diese Standardeinstellung kann der Admin aber deaktivieren, auch das Ablegen in normalen Zonefiles ist jederzeit möglich. Die Konfiguration erfolgt über ein Rest-API via HTTPS. Dafür bringt Bind 10 ein Kommandozeilen-Utility mit, das dem Admin in einer eigenen Sprache Konfigurationsänderungen erlaubt.

Modular, aber nicht für jeden

Schließlich laufen statt eines für »named« nun bis zu zwölf Prozesse (DHCP nicht eingerechnet), die meisten davon Python-Prozesse. Die verbauten DHCP-Komponenten sind laut Webseite des Projekts noch im Status “Experimentell”, lassen sich aber bereits ebenfalls konfigurieren und testen.

Generell gilt: Die Modularisierung von Bind 10 in einzelne Daemons bedeutet die größte Umstellung für Administratoren, und sie verhindert das Upgrade manches bisherigen Standard-Szenarios in Unternehmen. Abbildung 2 zeigt schematisch das Setup, nach dem in den meisten Firmen die Namensauflösung abläuft. Eine Nameserver-Instanz erledigt dabei sowohl den autoritativen wie auch den rekursiven Dienst. Alle Clients verwenden den einen existierenden Nameserver, der alle Antworten bereitstellt.

Doch ideal ist das nicht. Sauberer wäre es, die beiden Funktionen voneinander zu trennen, so wie in Abbildung 3. Der rekursive Nameserver hat in diesem Aufbau Einträge für die lokalen Zonen, die ihn diese explizit bei dem maßgeblichen Nameserver abfragen lassen – entweder über den Secondary-Mechanismus oder über Forward-Zone-Einträge.

Abbildung 2: Im heute in Unternehmen üblichen Setup erledigt ein DNS-Server die ganze Arbeit.

Abbildung 3: Das eigentlich empfehlenswertere Setup mit getrenntem DNS-Resolver und Authoritative Server ist mit Bind 10 derzeit nicht möglich.

Nachgefragt

Wie eine Rückfrage auf der Bind-10-Mailingliste bestätigte, ist so ein Setup jedoch mit Bind 10 derzeit nicht möglich. Anfragen für das lokale Netz würden da den Weg übers Internet gehen, ohne Aussicht auf erfolgreiche Antworten, da diese nur lokal vorliegen.

Die Entwickler haben jedoch nach eigener Aussage vor, das Setup aus Abbildung 3 in einer späteren Version zu implementieren, indem sie den Server das RD-Bit der Abfrage auswerten lassen. Dann, so der Plan, solle dieser die Anfrage entweder zur maßgeblichen Komponente oder zum Resolver weiterleiten. Wenn ein Administrator diese Funktion benötigt, dann scheidet Bind 10 zurzeit aber aus.

Die Installation

Weil die Software noch neu ist, gab es zum Redaktionsschluss noch keine offiziellen Pakete geschweige denn Repositories; es blieb den Testern des Linux-Magazins nur das Bauen aus den Quellen, die unter [1] zu finden sind. Kurz vor Redaktionsschluss fanden sich Pakete für Bind 10 auf dem Open Suse Build Service, die eine einfache Installation mit nur einem Mausklick ermöglichten [2].

Bei der für den Test verwendeten Gentoo-Installation verlangte Bind vor dem Übersetzen die Pakete »boost« , »botan« , »log4cplus« und »sqlite3« , außerdem ist Python in Version 3.1 oder neuer erforderlich. Die DHCP-Komponente benötigt MySQL, worauf man aber für einfache Tests auch verzichten kann. Nach der Installation der Pakete ist das Kompilieren mit »./configure && make && make install« schnell erledigt. Soll der DHCP-Server mit MySQL-Backend laufen, dann greift der Admin zu der Option »–with-dhcp-mysql« .

Nach der Installation benötigt Bind  10 zunächst einen Administrator-Account für das Konfigurationsinterface. Dafür nutzt der Admin das Dienstprogramm »b10-cmdctl-usermgr« , das interaktiv einen Benutzernamen und ein Passwort abfragt, die es dann der Datei »cmdctl-accounts.csv« in »$INSTALLDIR/etc/bind10« hinzufügt. Das Programm ist noch sehr rudimentär implementiert und erlaubt nur das Hinzufügen, sonst hat es keine weiteren Funktionen. Die Dienstprogramme beginnen übrigens alle mit dem Kürzel »b10« .

Bevor der Administrator sich an die Konfiguration des Nameservers macht, muss er entscheiden, in welchem Modus er ihn betreiben will: rekursiv oder autoritativ, also als Master für eigene Zonen. Im Gegensatz zu den vorherigen Versionen führt die Modularisierung bei Bind 10 dazu, dass auf einer IP-Adresse jeweils nur eine Komponente Verbindungen akzeptiert. Bei einem Host mit mehreren IPs sieht das anders aus.

Inbetriebnahme

Um den Nameserver zu starten, ruft der Administrator »INSTALLDIR/sbin/bind10« auf. Dies ist ein Wrapper-Skript, das seinerseits »b10-init« startet, das sich im »libexec« -Verzeichnis der Installation befindet und die konfigurierten Komponenten startet. Beim ersten Start gibt Bind 10 alle Logmeldungen auf der Konsole aus. In einer zweiten Shell auf dem gleichen Rechner startet der Admin »bindctl« aus dem Verzeichnis »INSTALLDIR/bin« . Dieses Kommandozeilen-Frontend zum Restful-API dient bei Bind 10 zur Konfiguration.

Der Server nimmt in der Standardkonfiguration Anfragen auf dem Localhost-Port 8080 entgegen und akzeptiert nur mit SSL abgesicherte Verbindungen. Ein selbst signiertes Zertifikat installiert Bind 10 mit, es lässt sich aber bei Bedarf austauschen. »bindctl« fragt bei der ersten Verbindung Benutzernamen und Passwort ab, diese landen zur Wiederverwendung in »~/.bind10/default_user.csv« – aber im Klartext!

Nach dem Anmelden am Server mit dem erzeugten Benutzer muss der Admin zunächst die gewünschte Komponente anlegen. Im ersten Beispiel (Listing  1) ist dies ein »authoritative nameserver« . Die erste Zeile legt eine Instanz eines Authoritative Nameservers an. Zeile zwei dient dazu, Bind-Dienste zu markieren, die bei Start und Stopp besondere Aufmerksamkeit erfordern, dazu gehören der Resolver und der Webserver zur Konfiguration. Dabei wird jeweils das Feld »b10-Name_des_Dienstes/special« auf »Name_des_Dienstes« gesetzt.

01 dns-test ~ # /opt/bind10/bin/bindctl
02 ["login success "] login as dnsadmin
03 > config add Init/components b10-auth
04 > config set Init/components/b10-auth/special auth
05 > config set Init/components/b10-auth/kind needed
06 > config commit
07 > quit
08
09 Exit from bindctl
10 dns-test ~ #

Die dritte Zeile gibt an, ob der Dienst »auth« als notwendig für diese Konfiguration gilt. Mit »config commit« schaltet der Administrator die Änderungen scharf und kann sofort den Nameserver testen. Den Eintrag »version.bind« fragt er beispielsweise mit folgendem Kommando ab:

dig @127.0.0.1 -c CH -t TXT version.bind

Nun ist es an der Zeit, dem Nameserver auch Zonen beizubringen, die er bereitstellen soll. Die verwaltet Bind 10 in einer SQlite-Datenbank oder in klassischen Zonefiles. Auch mit SQlite muss der Administrator aber weiterhin Zonefiles verwenden.

Abgesehen von dynamischen DNS-Updates landen Änderungen im Zonefile, das durch einen erneuten Import automatisch die alte Zonendefinition überschreibt. Zwar ist es möglich, die Datenbank direkt per Requests zu modifizieren, aber dies führt mit hoher Wahrscheinlichkeit zu Inkonsistenzen, sodass auch die Bind-Autoren auf Rückfrage davon abraten. Für den Import steht das Programm »b10-loadzone« bereit. Listing 2 zeigt einen Beispielaufruf.

01 dns-test ~ # /opt/bind10/bin/b10-loadzone 1.168.192.in-addr.arpa db.192.168.1
02 2013-03-19 21:18:47.381 INFO  [b10-loadzone.loadzone/2644] LOADZONE_SQLITE3_USING_DEFAULT_CONFIG Using default configuration with SQLite3 DB file /opt/bind10/var/bind10/zone.sqlite3
03 2013-03-19 21:18:47.483 INFO  [b10-loadzone.loadzone/2644] LOADZONE_ZONE_CREATED Zone 1.168.192.in-addr.arpa./IN does not exist in the data source, newly created
04 2013-03-19 21:18:47.566 INFO  [b10-loadzone.loadzone/2644] LOADZONE_DONE Loaded 31 RRs into zone 1.168.192.in-addr.arpa./IN in 0.08 seconds

Zonen-Import

Das Programm importiert nicht nur die Zonen sondern führt auch implizit die »bindctl« -Kommandos aus, die zum Anlegen der Zone notwendig sind. Die Zone ist danach sofort scharf geschaltet. Es ist zwar möglich, eine eigene SQlite-Datenbank mit der Option »-c« anzugeben, sie aufzusplitten ist aber vermutlich nur dann notwendig, wenn ein großer Provider viele Zonen anbieten möchte. Will der Administrator die Zone nicht in die Datenbank kopieren, sondern weiterhin mit klassischen Zonedateien arbeiten, dann muss er doch bei »bindctl« bleiben (Listing 3).

01 config add data_sources/classes/IN
02 config set data_sources/classes/IN[1]/type MasterFiles
03 config set data_sources/classes/IN[1]/params { "bind10test.local" : "/var/bind/db-test" }
04 config set data_sources/classes/IN[1]/cache-enable true
05 config commit

Im ersten Schritt legt das Vorgehen eine neue Instanz der Klasse »IN« an, danach versorgt es sie mit Parametern. Der Typ ist »MasterFiles« im Gegensatz zu »sqlite3« in der Standardkonfiguration. Die Parameter sind die Zone und die entsprechende Datei im Json-Format. Die letzte Zeile schließlich aktiviert den Cache, was die Zone aus dem Hauptspeicher statt von der Festplatte bereitstellt. Dies ist bei Zonen aus Textdateien zwingend erforderlich.

Nicht für jede neue »IN« -Zone entsteht ein Eintrag in der Hierarchie »data_sources/classes/IN« , sondern nur für die Typen »MasterFiles« und »sqlite3« . Die SQlite-Datenbank darf mehrere Zonen enthalten, wobei der Typ »MasterFiles« pro Paar aus einer Zone samt der zugehörigen Datei einen Json-Eintrag verlangt, jeweils mit Kommata getrennt. Wie in den alten Versionen müssen Admins dem Nameserver Änderungen im Zonefile mitteilen, in Bind 10 lädt das Kommando »auth loadzone example.org« die Zone »example.org« neu.

Primär oder sekundär?

Normalerweise haben Primary Nameserver mindestens einen Secondary NS, der die Zonen herunterkopiert – der so genannte Zonetransfer. Damit es nicht jedem Unbefugten möglich ist, so einfach eine Liste aller Hosts einer Zone zu erhalten, sichert Bind den Zonetransfer entweder auf IP-Ebene ab oder – deutlich sicherer – durch einen Schlüssel oder eine Kombination aus Key und IP.

Bind 10 nutzt einen Keyring, der mehrere Schlüssel enthalten kann. Jeder Eintrag besteht aus einem Tripel aus dem Namen des Schlüssels, dem eigentlichen Key sowie dem Algorithmus. Den Default-Algorithmus HMAC-MD5 kann der Admin in der Bezeichnung weglassen, es empfiehlt sich aber generell, andere Algorithmen zu verwenden und diese dann auch explizit zu benennen.

Um einen neuen Schlüssel anzulegen steht »bindctl« bereit:

config add tsig_keys/key "example.org.:Nvf5WLM1LA0E2VuhnkbE4Q=="

Jetzt lässt sich der Schlüssel in ACLs unter dem Namen »example.org« referenzieren. Damit auch der Secondary Nameserver Zonetransfers durchführen kann, muss der Admin eine weitere Komponente aktivieren. Auch hier tritt wieder »bindctl« in Aktion (Listing 4)

01 config add Init/components b10-xfrout
02 config set Init/components/b10-xfrout/address Xfrout
03 config set Init/components/b10-xfrout/kind dispensable
04 config commit

In der Standardkonfiguration erlaubt der Nameserver Zonetransfers ohne Einschränkungen von überall. Dies zeigt sich auch in der implizit angelegten ACL, die »config show Xfrout/transfer_acl« anzeigt. Regelbar ist das entweder pro Zone mit eigenen ACLs oder aber auf der globalen Ebene.

ACLs lassen sich im Json-Format schreiben und haben folgendes Format:

{"action":"ACCEPT|REJECT|DROP", "from":"IP-Bereich","key":"Name_des_Schlüssels"}

Im »IP-Bereich« gibt der Administrator wie schon bei älteren Bind-Versionen eine einzelne Adresse oder einen Bereich in der Form 192.168.1.0/24 an. Dies gilt selbstverständlich für IPv4- und IPv6-Adressen und -Netze. »from« und »key« sind optional und müssen nicht vorkommen, stehen sie aber in einer Regel, so gilt dies als Und-Verknüpfung. Ein Regelwerk besteht aus mehreren Regeln, in denen Kommas die »{…}« -Blöcke trennen, eckige Klammern fassen das Ganze zusammen. Da es sich dabei um ein Array handelt, fügt der Admin die ACL mit einem Set-Kommando statt mit den sonst üblichen Add-Befehlen hinzu:

config set Xfrout/transfer_acl [{<I>Erster <I><I>Block<I>}, {<I>Zweiter Block<I>}, ...]

Allgemein lassen sich auch kompliziertere Verknüpfungen in den ACLs abbilden. Kapitel 9 des “Bind 10 Admin Guide” gibt einige Beispiele [3]. Im Test funktionierte allerdings nur, Zonen freizugeben, die Bind in der SQlite-DB vorhielt. Wahrscheinlich lag das daran, dass in der Datenbank weitere Tabellen für inkrementelle Zonetransfers dienen, diese Möglichkeit bei Flatfiles aber nicht vorgesehen ist.

Soll ein Bind 10 als Secondary Nameserver arbeiten, dann sind zwei Komponenten hinzuzufügen und zu konfigurieren: Xfrin führt die eigentlichen Zonetransfers durch, Zonemgr prüft die SOA-Records, ob Änderungen vorliegen, und stößt bei Bedarf Xfrin an. Die Auth-Komponente gibt auch Notifies der Master-Nameserver an den Zonemanager weiter. Die Bindctl-Anweisungen in Listing 5 zeigen, wie Admins Bind 10 als Secondary konfigurieren und eine Zone einbinden.

01 config add /Init/components b10-xfrin
02 config set /Init/components/b10-xfrin/address Xfrin
03 config set /Init/components/b10-xfrin/kind dispensable
04 config add /Init/components b10-zonemgr
05 config set /Init/components/b10-zonemgr/address Zonemgr
06 config set /Init/components/b10-zonemgr/kind dispensable
07 config commit
08 config add Xfrin/zones
09 config set Xfrin/zones[0]/name "example.test"
10 config set Xfrin/zones[0]/master_addr "10.1.1.1"
11 config commit
12 config add Zonemgr/secondary_zones
13 config set Zonemgr/secondary_zones[0]/name "example.test"
14 config commit

Im Logfile finden sich anschließend Einträge, die belegen, dass Bind den Zonetransfer erst nach dem finalen »config commit« am Ende angestoßen hat. Ein Zonetransfer lässt sich aber auch manuell mit dem folgenden Kommando anstoßen:

Xfrin retransfer zone_name="example.test" master=10.1.1.1

Leider ist es in der aktuellen Release nicht möglich, ACLs auf die Notifies zu setzen, sodass diese durchaus fälschbar sind. Im “Bind 10 Admin Guide” [3] findet sich dafür nur der lakonische Eintrag: “Eine Zugangskontrolle, etwa für Notifies, stellt Bind 10 noch nicht zur Verfügung. Der Primary-/Secondary-Service ist noch nicht vollständig.”

Dynamisches DNS

Bind 10 unterstützt auch dynamische DNS-Updates, die den Rechner etwa von einem anderen DHCP-Server erreichen. Der in Bind 10 selbst verbaute DHCP-Server ist aber nicht in der Lage, diese zu erzeugen.

Immerhin: Für die Übernahme der Aktualisierungen ist im DNS-Server eine eigene Komponente vorgesehen, die der Admin per »bindctl« aktiviert. Außerdem muss er für jede Zone, die Updates empfangen soll, eine ACL eintragen, die dies explizit erlaubt. Listing 6 zeigt die Konfigurationsanweisungen sowie eine ACL für eine Zone.

01 config add Init/components b10-ddns
02 config set Init/components/b10-ddns/address DDNS
03 config set Init/components/b10-ddns/kind dispensable
04 config commit
05 config add DDNS/zones
06 config set DDNS/zones[0]/origin 2.168.192.in-addr.arpa
07 config add DDNS/zones[0]/update_acl {"action":"ACCEPT","from":"192.168.1.1"}
08 config commit

Sowohl rekursiver als auch Primary und Secondary Nameserver sind bei Bind 10 in zwei Komponenten aufgetrennt. Die sollten – geht es nach den Entwicklern – auch nicht auf demselben Host laufen. Schon weil jedes der Bauteile selbst Verbindungen auf dem DNS-Port 53 entgegennehmen möchte, kommen sie sich zwangsläufig ins Gehege. Wer die auf einem Host einsetzen will, muss Resolver und Primary zumindest an unterschiedliche IP-Adressen binden.

Listing 7 zeigt, wie »bindctl« den rekursiven Nameserver initialisiert. Da der rekursive Server in der Standardkonfiguration nur auf dem Localhost Verbindungen akzeptiert und dann bereits standardmäßig eine ACL eingerichtet ist, die rekursive Abfragen nur von Localhost akzeptiert, muss der Admin die Liste der Adressen, auf denen Bind Anfragen annimmt, noch um die 10.1.1.1 erweitern und eine ACL hinzufügen, die auch für das lokale Netz 10.1.0.0/16 rekursive Abfragen erlaubt. Steht ein Nameserver weiter innen in der Infrastruktur, so kann es notwendig sein, mit

01 config add Init/components b10-resolver
02 config set Init/components/b10-resolver/special resolver
03 config set Init/components/b10-resolver/kind needed
04 config set Init/components/b10-resolver/priority 10
05 config commit
06 config add Resolver/listen_on
07 config set Resolver/listen_on[2]/address "10.1.1.1"
08 config set Resolver/listen_on[2]/port 53
09 config add Resolver/query_acl
10 config set Resolver/query_acl[2] {"action":"ACCEPT","from":"10.1.0.0/16"}
11 config commit

config add Resolver/forward_addresses { "address":"172.16.1.1", "port":53 }

einen weiteren Nameserver für die Weiterleitung einzurichten, einen so genannten Forwarder.

Logging

In der Standardkonfiguration schreibt Bind 10 alle Log-Informationen auf die Konsole, an der er gestartet wurde. Für den Produktivbetrieb eignet sich das allerdings nur schwerlich, hier sollte er die Meldung entweder an Syslog übergeben oder in eine eigene Datei leiten. Dazu dient die Konfigurationshierarchie mit dem Schlüsselwort »Logging« . Unter ihr legt der Admin einzelne Instanzen vom Typ »logger« an. Ein Logger kann Aktionen einer oder mehrerer Komponenten protokollieren. Das ist über den Parameter »name« steuerbar, wobei »*« alle Komponenten abdeckt.

Listing 8 zeigt, wie man das Logging in eine Datei laufen lässt. Dabei kümmert sich Bind auch gleich um die Log-Rotation und erlaubt es, auch die Größe der Logdateien zu beschränken. Mit dem Wert »syslog« als »destination« bestimmt der Admin die Übergabe der Meldungen an den Syslog-Server. Dabei enthält der Parameter »output« die Syslog-Facility. Die »severity« in der Definition des Loggers (Zeile 3) ergibt sich beim Verwenden von Syslog automatisch. Die »output_options« sind zwar als ein Array angelegt, im Test führten zwei Einträge unter einem Logger aber dazu, dass keiner von beiden funktionierte.

01 config add Logging/loggers
02 config set Logging/loggers[0]/name *
03 config set Logging/loggers[0]/severity INFO
04 config add Logging/loggers[0]/output_options
05 config set Logging/loggers[0]/output_options[0]/destination file
06 config set Logging/loggers[0]/output_options[0]/output /var/log/dnslog
07 config set Logging/loggers[0]/output_options[0]/maxsize 204800
08 config set Logging/loggers[0]/output_options[0]/maxver 8
09 config commit

Performance

Die Antwortzeiten eines DNS-Servers erweisen sich als kritisch für das Verhalten vieler anderer Dienste, vom gefühlten Tempo von Webseiten-Aufrufen bis zum Ruf-Aufbau bei VoIP-Telefonaten. Zwar bestand die Bind-10-Installation für diesen Artikel aus einer virtuellen Maschine, dennoch haben die Tester des Linux-Magazins diverse Vergleichstests zwischen den Bind-Versionen 9.9.2 und 10 durchgeführt.

Abbildung 4 zeigt die Ergebnisse. Als Benchmarktool kam Dnsperf 2.0 von Nominum, einem Hersteller von DNS-Appliances, zum Einsatz [4]. Das Tool nimmt ein Textfile mit Records und Typen, also etwa »host.local a« , um den A-Record von »host.local« abzufragen. Die Textdatei kann der Benchmark dann mehrfach durchlaufen, für den Auth-Server dieses Artikels kamen jeweils vier Records 10 000-mal unter die Lupe.

Abbildung 4: Durchschnittswerte aus einem mit Dnsperf durchgeführten Benchmark: Bind 9 ist schneller.

Außerdem haben die Tester die verschiedenen Speicheroptionen, die Bind 10 bietet (Textfile, SQlite DB mit und ohne Memory Cache), ebenfalls gestestet. Für Version 9 musste allerdings nur die Standardkonfiguration herhalten.

Im Vergleich lag Bind 9 auf der gleichen VM mit 3400 Queries pro Sekunde für dieselben Abfragen auf derselben Zone knapp vor dem offensichtlich noch recht jungen Bind 10. Für den Test des rekursiven Resolvers enthält Dnsperf ein zweites Programm namens Resperf, das zur Messung des Resolver-Durchsatzes erst eine Vorglühphase durchläuft, in der es den Cache befüllt, bevor die eigentliche Messung stattfindet. Hier fiel der Test noch deutlicher zugunsten von Bind 9 aus, der zirka 3000 Abfragen pro Sekunde im Vergleich zu 1600 von Bind 10 schaffte.

Zahlreiche Fallen

Während der Tests traten noch einige weitere Probleme auf. Beispielsweise ließen sich nach dem Aktivieren des Cache für die Zonen, die Bind 10 in SQlite vorhielt, nur noch die Zonen abfragen, die in der Liste der Cache-Zones eingetragen waren. Selbst die Secondary Zone, die in der gleichen SQlite-Datenbank vorlag, mussten die Tester erst eintragen, bevor sie sich wieder abfragen ließ. Dass der Auth-Server Zonetransfers per Default erst einmal erlaubt, stellt eine 180-Grad-Wendung des Verhaltens zur Vorgängerversionen dar. Unaufmerksame Administratoren handeln sich hier schnell ein Sicherheitsrisiko ein.

Gentoo-Anwender sollten sicherstellen, dass sie Python 3.2 mit dem »sqlite« -Useflag gebaut haben, da sonst die Komponenten, die Python verwenden, nicht funktionieren, weil sie ohne dieses Flag nicht an die Konfiguration kommen.

Des Weiteren fehlt zurzeit jede Möglichkeit, die eingerichteten Zonen aufzulisten, der Admin muss sich diese anderweitig merken. Eine Rückfrage auf der Mailingliste ergab konstruktive Vorschläge, wie sich dies in bestimmten Konfigurationen lösen ließe. Ein Vertreter des ISC bestätigte dabei sowohl das Fehlen des Feature, als auch die Bestrebungen, es noch einzubauen.

Verwendet der Administrator in der bestehenden Installation von Bind ACLs auf Primary- oder Secondary-Zonen oder setzt er bei Bind 9 Views ein, so ist dies mit den Bordmitteln von Bind 10 bisher nicht abbildbar.

Auch hier bekamen die Autoren des Linux-Magazins auf der Bind-Mailingliste eine abschlägige Antwort. Das ändert sich vielleicht, sobald Bind 10 außerhalb von Providern größere Verbreitung findet. Gegenwärtig kann schon dies ein Kill-Kriterium sein, das eine Migration verhindert.

Radikalkur ohne Vorteile

Bind 10 bedeutet eine radikale Umstellung, ohne dass der Administrator dafür mit Vorteilen belohnt wird, die den Aufwand rechtfertigen. Zwar macht die neu gewonnene Modularität Bind besser spezialisierbar und flexibler einsetzbar. Für einen Internetprovider, der viele Primary Zones anbietet, mag das auch sinnvoll sein. Aber die Einschränkungen in der Funktionalität wie das Fehlen von Views und vor allem die fehlende Möglichkeit, den maßgebenden und den rekursiven Nameserver auf einer Maschine laufen zu lassen, dürfte den Einsatz von Bind 10 für viele Administratoren in Firmennetzen zumindest schwierig machen.

Die DHCP-Komponente ist allerhöchstens zum Ausprobieren zu empfehlen und entspricht so voll und ganz den Warnhinweisen auf der Webseite. Auch wäre es logischer gewesen, das Kommandozeilen-Utility zur Verwaltung der Inhalte von Zonen zu verwenden, jedoch fehlt diese Möglichkeit vollständig. Und so lange Bind 10 – wie der kurze Benchmark in diesem Artikel nahelegt – noch eine schlechtere Performance als Bind 9 an den Tag legt, gibt es für Admins in Unternehmen wirklich wenig Anreiz zum Umstieg auf die neue Version.

options {[...]
        allow-recursion { 10.1.0.0/16; 127.0.0.0/8; ::1; };  [...]
}