Domain Name Service

Übersicht

Anmerkung: In der Literatur finden Sie die Bezeichnungen Domain Name System und Domain Name Service. Im Grunde meinen beide einunddasselbe. Domain Name System bezeichnet genau genommen die Methode der Umsetzung von IP-Adressen in symbolische Namen. Die technische Umsetzung hingegegen, also alle Routinen zusammen genommen, die das System implementierten, formen einen Dienst - den Domain Name Service. Der Praktiker spricht also vom Service und der Theoretiker vom System.

Vorläufer des DNS

Zu Beginn der sechziger Jahre, als die USA und die damalige UdSSR sich mitten im Kalten Krieg befanden und das Internet (bzw. ARPAnet) als solches noch gar nicht existierte, gab das amerikanische Verteidigungsministerium (Department of Defense, DoD) den Auftrag, ein dezentrales, ausfallsicheres und technisch fortschrittliches Netzwerk zu entwickeln und zu implementieren, um die vermeintliche Bedrohung durch die UdSSR möglichst gering zu halten.

Einige der renommiertesten Universitäten, Organisationen und Unternehmen arbeiteten an der Umsetzung und 1969 war es schließlich soweit. Vier Universitäts-Rechner in Kalifornien (University of California, Los Angeles, University of California Santa Barbara, Stanford Research Institute) und Utah (University of Utah) bildeten die Grundlage des neuen ARPAnets und konnten miteinander kommunizieren. In diesem Stadium der Entwicklung wurden die Informationen der verschiedenen Systeme noch in einer einzigen Datei, der »HOSTS.TXT«, verwaltet, von der alle angeschlossenen Systeme über identische Kopien verfügten. Diese Datei ist quasi ein Vorläufer der heutigen /etc/hosts-Datei.

Von der Idee und des dahinter steckenden Aufwandes war dies eine außerordentlich clevere und einfach zu handhabende Administrationsangelegenheit. Doch mit der Umstellung des Netzwerkprotokolle auf TCP/IP Mitte der siebziger Jahre stieg die Anzahl der zu verwaltenden Systeme immens an, womit die Aktualität der Datei »HOSTS.TXT« kaum mehr gewährleistet werden konnte und deren Umfang unpraktikable Ausmaße annahm. Der ursprüngliche Ansatz, eine dezentrale Verwaltung zu erschaffen, wurde aufgrund des benötigten Überblicks bei der Vergabe neuer Rechnernamen und -adressen »ad absurdum« geführt.

So war es unumgänglich, dass in den achtziger Jahren - die Anzahl der verbundenen Rechner betrug mittlerweile über 1000 - ein neues System, das Domain Name System (DNS), entwickelt und eingeführt wurde.

Ziele und Funktionen des DNS

Wie bereits erwähnt, übernimmt DNS die Aufgabe der Umwandlung von Internetnamen in numerische Internetadressen und umgekehrt. Diese Auflösung basiert auf der Verwendung des TCP/IP-Protokoll-Stacks. Hierbei wird jedem öffentlich zugänglichen System (Host, Router, Gateway, ...) eine eindeutige 32-Bit große binäre Zahl zugeordnet (IP-Adresse), über die es angesprochen werden kann. Zur Vereinfachung des Umgangs mit IP-Adressen werden diese in vier Oktetts unterteilt und in Form von durch Punkte getrennten Dezimalzahlen dargestellt (»11111111 11111111 11111111 11111111« »255.255.255.255«). Ein Oktett besitzt somit einen Werteumfang von 0..255 (2⁸ = 256). Seltener anzutreffen ist die hexadezimale Notation (»FF.FF.FF.FF«), wobei diese vorrangig beim Nachfolger des jetzigen IP-Adressformats angewandt wird (IPv6).

Da das menschliche Gehirn bekanntlich besser mit Namen als mit Zahlen umgehen kann, wird jeder dieser Adressen ein eindeutiger Namen zugeordnet. So lässt sich grundsätzlich mit der IP-Adresse »216.239.39.101« als auch mit dem Namen »www.google.de« die gleiche Web-Seite auf dem gleichen System erreichen. Da die Vermittlung im Internet aber einzig auf IP-Adressen basiert, ist bei Verwendung von symbolischen Rechnernamen vorab eine Adressauflösung durchzuführen.

Abbildung 1: DNS-Namensraum

Um diese Auflösung zu verstehen, sollten Sie den Aufbau des DNS-Namensraumes kennen (Abbildung 1). Ausgehend von einer Wurzel (root), die die Bezeichnung ».« trägt, sind die Domains in einer baumartigen Struktur organisiert. Die der Wurzel folgende Ebene umfasst die so genannten Top Level Domains (TLD's). Eine Ebene tiefer folgen die Subdomains, denen entweder unmittelbar die Rechnernamen folgen oder aber eine weitere Ebene lokaler Domains, unterhalb derer dann die Rechnernamen liegen.

Top-Level-Domains

Die Top-Level-Domains (TLD) gliedern sich in zwei Kategorien ein. Zur Kategorie der so genannten generischen TLD's zählen »org« (Non-Profit Organisationen), »mil« (militärische Einrichtungen), »com« (Kommerzielle Unternehmen), »edu« (Bildungseinrichtungen), »net« (Netzorganisationen) und »gov« (Regierungsbehörden). Im Jahre 2000 erfuhren die generischen TLD's eine Erweiterung um »biz«, »info«, »coop«, »aero«, »name«, »pro« und »museum«.
Die zweite Kategorie beinhaltet die länderspezifischen TLD's, wie bspw. »de« (Deutschland), »uk« (Grossbritannien), »aw« (Aruba), »cc« (Cocos Islands), »jp« (Japan) oder »ch« (Schweiz). Eine vollständige Liste aller TLD's wird von der Internet Assigned Numbers Authority (IANA), der Dachorganisation des Internets, verwaltet.

Die Abarbeitung eines Internetnamens, bspw. »www.linuxfibel.de«, erfolgt hierarchisch von rechts nach links, d.h. (vergleiche Abbildung 1) beginnend in der Wurzel führt der Zweig »de« (TLD) zum Zweig »linuxfibel« (registrierte Domain), der wiederum im Punkt »www« (Name eines Rechners der Domain »linuxfibel.de«) endet. Die Suche nach einem entsprechenden System erfolgt also stets baumabwärts beginnend im Root-Verzeichnis.

Korrekterweise müsste eine Domain immer mit einem abschliessenden Punkt, der das Root-Verzeichnis repräsentiert, geschrieben werden. Allerdings kann dies vernachlässigt werden, da inzwischen alle DNS-Werkzeuge hinreichend intelligent und tolerant sind, um trotzdem ein positives Ergebnis zurück zu melden. Bei einer Bind-Konfiguration wäre jedoch ein fehlender Punkt am Ende fatal, wie Sie später noch erfahren werden.

Forward- und Reverse-Lookup

Bei einer Namensauflösung wird i.d.R. das Äquivalent zu einem Internetnamen in Form einer Internetadresse, also eine Umsetzung von Namen nach Adresse, gesucht.

Abbildung 2: Auflösung der IP-Adresse eines Rechnernamens

Bedarf eine Anwendung der IP-Adresse zu einem Rechnernamen (»www.linuxfibel.de« vergleichen Sie das Beispiel in Abbildung 2), so übernimmt der so genannte Resolver, eine Sammlung von Funktionen aus der C-Bibliothek, die weitere Recherche. In typischen Konfigurationen wird der Resolver eines Clients (»sonne.galaxis.de«) zunächst die lokale Datei /etc/hosts nach entsprechenden Einträgen durchforsten. Wird er dort nicht fündig, reicht er die Anfrage an den zuständigen Nameserver weiter (in Abbildung 2 als »server.galaxis.de« bezeichnet). Jeder Nameserver verfügt über einen Cache, indem er die Daten der zuletzt recherchierten Anfragen eine Zeit lang zwischenspeichert. Erst wenn der lokale Nameserver die Adresse nicht in seinem Cache hat, beginnt der mit der Auflösung des Namens von $raquo;hinter her«. D.h. er fordert einen der Rootserver an (eine Liste solcher hält der Nameserver in einer Konfigurationsdatei), ihm die Adresse des für die Domain »de« zuständigen Nameservers mitzuteilen. An die gelieferte Adresse sendet er die folgende Anfrage nach der Adresses des für »linuxfibel.de« zuständigen Nameservers. Bei letzterem Server erhält er schließlich die gewünschte Informationen, die er sowohl in seinen Cache einträgt, als auch zum anfragenden Clientrechner weiterleitet.

Zur Auflösung in die Gegenrichtung (Adresse in Namen), das sogenannte Reverse Lookup, wurde eine neue Domain »in-addr.arpa« (Address and Routing Parameter Area domain) eingeführt. Unterhalb dieser speziellen Domain existieren 256 Subdomains (0..255). Insgesamt wiederholt sich diese Unterteilung viermal, bis die 32-Bit-Adresse vollständig dargestellt ist (Abbildung 3).

Abbildung 3: Reverse-Lookup mit Hilfe der Pseudodomain »in-addr.arpa«

Für das kommende IP-Adressformat IPv6 wurde die Domain »ip6.arpa« eingeführt, die nach einem ähnlichen Prinzip funktioniert, wie »in-addr.arpa« für IPv4 (offizielle Bezeichnung des IP für 32 Bit Adressen).

Anmerkung: Eine weitere Pseudodomain »e164.arpa« dient der Recherche von whois-Anfragen.

Unterschiede zwischen Domains und Zonen

Eine sehr wichtige Unterteilung in diesem Schema ist, um Verwirrungen auszuschließen, der Unterschied zwischen Domain und Zone. Leider ist dieser Unterschied nicht allzu groß und daher auch nicht allzu offensichtlich, aber immerhin vorhanden. Eine Domain beinhaltet alle unter ihm liegenden Domains, Zonen und Systeme (Hosts), d.h. alle baumabwärts liegenden Verwaltungseinheiten gehören zu dieser Domain. Da dies aber keinerlei Sinn macht alles auf dieser Ebene zu verwalten, wurden sogenannte Zonen eingerichtet. Diese Zonen konnten nun an die verschiedenen Einrichtungen und Unternehmen abgegeben werden, die die Verwaltung übernehmen und neue Knoten zeitnaher und schneller einbinden konnten. Jede Zone ist in sich abgeschlossen und beinhaltet nur die Knoten, die direkt zu ihr gehören. Sollten weitere Unterteilungen benötigt werden, so werden neue Zonen errichtet, die jedoch völlig unabhängig voneinander sind.

Abbildung 4: Zone und Domain

An dieser Stelle werden Namensserver (Nameserver) eingesetzt um die Verwaltung der Zonen zu übernehmen. Hierbei kann jedem Nameserver eine oder auch mehrere Zonen delegiert werden, für die er zuständig ist. Man spricht auch von "Autorität" einer Zone.

Generell besitzt jede Zone einen primären Nameserver ("primary Master", "Primary") und evtl. mehrere sekundäre Nameserver ("secondary Master", "Secondary"), die die Zonendaten untereinander austauschen, um auf dem neuesten Stand zu bleiben.

Eine Domain ist also ein logischer Oberbegriff, der zwar im täglichen Sprachgebrauch sehr häufig verwendet wird, im DNS wird jedoch lediglich mit Zonen gearbeitet. Oftmals findet auch keinerlei Unterscheidung statt, so dass die beiden Begriffe äquivalent behandelt werden.

Die Bind-Software

Die Entstehungsgeschichte der Bind-Software

Die Entwicklung des Berkeley Internet Name Domain Pakets, kurz Bind, startete Anfang der achtziger Jahre an der University of Berkeley als Diplomarbeitsprojekt einiger Studenten und stand unter Aufsicht namhafter Organisationen wie Defense Advanced Research Projects Administration (DARPA) und der Computer Systems Research Group (CSRG). Letztere Organisation zeichnete für die Versionen bis einschließlich 4.8.3 verantwortlich.

Zwischen 1985 und 1987 widmeten sich vorrangig Angestellte von Digital Equipment Corporation (DEC) der weiteren Entwicklung von Bind. Unter Federführung von DEC erschienen die Versionen 4.9 und 4.9.1. Die Version 4.9.2 sponserte Vixie Enterprices; Paul Vixie wurde zum Chefarchitekten von Bind.

Ab 4.9.3 ging die Verantwortung an das 1993 gegründete Internet Software Consortium (ISC) über, das von nun an für die Entwicklung und den Vertrieb bis einschließlich Version 8.2 zuständig war. Diese Organisation bezog ihre Mittel hauptsächlich von Sponsoren, die allerdings über die Jahre hinweg immer weniger freigiebig wurden, so dass mit Version 9 die Verantwortung an das Unternehmen Nominum Inc. abgegeben wurde, das seither die Weiterentwicklung vorantreibt.

Mit dem Start seiner Entwicklung wurde Bind zum Quasi-Standard und ist nahezu mit DNS selbst gleichzusetzen. Dieser Marktführerschaft trägt sogar Microsoft Rechnung, indem sie eine NT-Version von Bind herausbrachten, die allerdings in der internationalen IT-Infrastruktur keine bedeutende Rolle spielt.

Überblick über die einzelnen Versionen und ihre Merkmale

Die Wechsel der Verantwortlichkeiten für die Entwicklung von Bind deckt sich stets mit entscheidenden Versionssprüngen. Jede dieser drei Hauptversionen beinhaltete grundlegende Änderungen und Erweiterungen.

Die 4er Versionen brachten den Durchbruch von Bind und setzten so den Startpunkt als de-facto-Standard. Fortan fehlte Bind in kaum einem der Unix-Systeme. Das Kernstück in Bind-4 bildete eine Datei namens »/etc/named.boot«, in der sich die Informationen über die Lage aller weiteren Konfigurationsdateien, die zum Betrieb notwendig waren, befanden. Dem Konzept der zentralen Datei ist Bind bis heute treu geblieben.

Funktionen wie Caching, d.h. das Vorhalten von Adressinformationen bereits aufgelöster Namen bzw. Adressen, Forwarding, dem Weiterleiten an bspw. dedizierte Nameserver, oder Query Logging, die Analyse getätigter Auflösevorgänge, wurden implementiert. Bind-4 brachte allerdings ebenso ein erhöhtes Sicherheitsrisiko mit sich, da etliche entscheidende Programmteile mit teils extremen Fehlern (Bugs) behaftet waren. Trotzt zahlreicher Nachbesserungen am Quellcode konnte Bind-4 nie seinen Ruf als potentielle Sicherheitslücke abwerfen und verschwand mit Erscheinen der Version 8 binnen kurzer Zeit von der Servern.

In der Version Bind-8 wurden weite Teile des Quellcodes neu- bzw. komplett umgeschrieben. Weiterhin kamen neue Funktionen hinzu, die heute nicht mehr wegzudenken sind, wie dynamische Updates, Benachrichtigungen der Slaveserver bei Änderungen, ACLs zur Zugriffskontrolle auf den Server, verbesserte Zonentransfers und Updates sowie eine verbesserte Performance. Das Sicherheitsrisiko sank durch die Neuprogrammierung enorm.

Die aktuellste Version ist Bind-9. Auch hier wurden Sicherheit und Stabilität zum obersten Gebot. Signaturen ermöglichen nun gesicherte Zonenzugriffe (DNS Security, DNSSEC); Transaction Signatures (TSIG) ermöglichen signierte DNS-Anfragen. Das IPv6-Protokoll wird in Bind-9 vollständig unterstätzt, indem es neue Ressource-Einträge implementiert (»A6«, »AAAA«, »DNAME«) und beide Schreibformate der 128-Bit-Adressen akzeptiert (»Nibble« [veraltet] und »Bitstring«). Zur effizienteren Arbeit können Zonen mit konkreten Views angelegt werden, womit Definitionen getrennter Zonen für Anfragen aus dem internen und dem externen Netz möglich sind. Derartige Zonen sind komplett voneinander abgeschottet und parallel auf einunddemselben System lauffähig. Als wesentliche Neuerung unterstützt Bind-9 nun Multiprozessorsysteme. Wie auch seine Vorgänger ist Bind-9 für alle verbreiteteten Plattformen verfügbar.

Die wichtigsten DNS/Bind-Programme (Bind-Utils) kurz beschrieben

Zu diesem Zeitpunkt sollen die verschiedenen Programme und Daemons nur kurz benannt und ihr Zweck erläutert werden. Weitere Informationen zu den administrativen Vertretern der Programme erhalten Sie im weiteren Text. Die Hilfsprogramme zum Zugriff auf Informationen des DNS werden im Zusammenhang mit dem DNS-Client diskutiert.

Dig

Dig (Domain Information Groper) ermöglicht die interaktive Befragung von DNS-Servern. Es vollzieht DNS-Recherchen und veranschaulicht die Antworten aller befragten Server. Dig ist somit vorallem zur Diagnose der DNS-Funktionalität nützlich.

Dnssec-keygen, dnssec-makekeyset, dnssec-signkey, dnssec-signzone

Bei diesen Tools handelt es sich um die DNS Security Extensions, die dafür gedacht sind ein gesicherte Kommunikation zwischen den einzelnen Nameserver aufzubauen. Vor Bind9 war nur eine rudimentäre Unterstützung dieser Tools vorhanden. Das Prinzip, dass hier zugrunde liegt ist das Public-Key-Verfahren, bei dem ein Schlüsselpaar erstellt wird und der öffentliche Schlüssel bei einer Zertifizierungsstelle hinterlegt wird.
Da dieses Verfahren noch relativ neu ist und auch umwälzende Veränderungen weltweit haben wird, ist es kaum vorstellbar, dass es sich in nächster Zeit schnell durchsetzen kann.
dnssec-keygen: Mit diesem Befehl wird das Schlüsselpaar erstellt. Sie können wie bei PGP hier auch den Verschlüsselungs-Algorithmus und die Schlüssellänge mitgeben.
dnssec-makekeyset: Hiermit wird eine Datei erstellt, bei der Ihre Zone eingebunden ist und an den Betreiber Ihrer Parent-Zone geschickt wird, der diese signieren und akzeptieren kann. Sie sehen hier beginnen bereits die grössten Schwierigkeiten, da es sich hierbei meist um .de-Zonen handelt, auf die dann eine grosse Flut hereinbricht.
dnssec-signkey: Damit signiert der Parent-Zone-Betreiber Ihre Schlüssel mit seinem eigenen privaten Schüssel
dnssec-signzone: Letztendlich müssen Sie nun noch Ihre Zone mit dem erhaltenen Schlüssel signieren um Steueranweisungen sicher zu erhalten

Host

Host ist ein weiteres DNS-Abfragewerkzeug. In der Voreinstellung begnügt es sich mit der Ausgabe eines Adresse zu einem gegebenen Rechnernamen bzw. umgekehrt. Verschiedene Optionen ermöglichen ähnlich komplexe Recherchen wie »dig«.

Lwresd

Der Lightweight Resolver Daemon (lwresd) ist eine abgespeckte caching-Only Version des normalen Bind-Nameservers, der auf einem eigenen Protokoll (lrp - Lightweight Resolver Protokoll) basierend arbeitet. Normalerweise hört er lediglich auf Anfragen die über das Loopback-Interface (127.0.0.1) kommen.

Named-checkconf

Mit named-checkconf wurde ein Tool entwickelt, dass die Syntax der Konfigurationsdatei überprüft und gegebenenfalls interveniert. Sollte sich ein Fehler eingeschlossen haben so erscheint eine Fehlermeldung und die Zeilenangabe. Bei einer richtigen Konfigurationsdatei erhält man einen Return-Code von 0 und keine weitere Meldung. Standardmässig wird die /etc/named.conf als Konfigurationsdatei eingelesen. Sollten Sie diese also irgendwo anders abgelegt haben, so müssen Sie diese explizit angeben, damit die Überprüfung stattfinden kann.

named-checkzone

Ein weiteres Tool ist named-checkzone. Mit diesem Tool können Sie Ihre Zonen auf Fehler testen.
Bsp: named-checkzone zoneA.de /var/named/master/db.zoneA
Bei Beendigung wird ebenfalls ein Return-Code ausgegeben und evtl. eine kleine Zusammenfassung, ob die Überprüfung etwas ergeben hat.
Bsp: zone zoneA.de/IN: loaded serial 2003041108
ok

Nslookup

Nslookup liegt Bind-9 nur noch aus Kompatibilitätsgründen bei. Es ist quasi die »alte« Version von »dig« mit ähnlichem Funktionsumfang aber auch anderem Bedienkonzept (es beinhaltet einen interaktiven Modus). Nslookup beherrscht nicht den Umgang mit Adressen nach IPv6.

Rndc

Das RNDC ist ein Nameserver Kontrolltool, mit dem Anweisungen an den Nameserver geschickt werden können um ihn zu steuern. Dieses Tool ist neu seit Bind9 und löst damit den ndc der Vorgängerversionen ab. Prinzipiell wird in der Konfigurationsdatei des Tools eine Schlüsseldefintion vorgegeben, die den Algorithmus und ein Passwort enthält, mit diesem dann Clientsysteme Änderungen und Steuerungen am Server vornehmen dürfen.

Sicherheit von Bind

Der Domain Name Service ist eine der Schlüsselkomponenten des Internets und folglich ein vorrangiges Ziel potentieller Angreifer. Bei der Komplexität der Software sind Fehler kaum auszuschließen und in jeder bisherigen BIND-Version wurden mehr oder weniger gravierende Schwachstellen aufgedeckt. Gerade als Administrator eines öffentlichen DNS-Servers sollten Sie deshalb gewissenhaft die in Mailinglisten diskutierten Sicherheitsthemen verfolgen und ggf. ihre Serversoftware auf den aktuellsten Stand halten.

Inwiefern die aktuelle Bind-Auflage Fehler beinhaltet, vermag niemand zu erraten. Aber die problematischsten Schwachstellen früherer Versionen sollen im nachfolgenden Text Erwähnung finden.

Erlangen von Root-Rechten

Das höchste der erreichbaren Ziele für jeden Angreifer ist es, die UID 0 zu erhalten, d.h. Herr über den root-Account zu werden. Wurde der root-Account erst einmal übernommen, kann das System zu allem missbraucht werden, ohne die Gegenmaßnahmen fürchten zu müssen. Dieses Erlangen wird oftmals durch Fehler in der Software (Bugs) unterstützt, dass durch sogenannte Exploits ausgenutzt wird. Allerdings sind bei Bind9 bis dato noch keine Exploits bekannt, die fehlerhafte Codeteile ausnutzen können, was auch sehr für den Einsatz in unserer DMZ spricht. Bind4 und Bind8 dagegen waren, vor allem in der Frühphase ihrer Entwicklung, stark von Bugs betroffen und hatten immense Sicherheitsprobleme. Einer dieser Bugs soll hier einmal kurz exemplarisch dargestellt werden.

NXT-Bug: (Einstufung: critical)

Der NXT-Eintrag in den Konfigurationsfiles dient dazu, dass negative Antworten über signierte Zonen die nicht vorhanden sind, trotzdem abgeschickt werden. Er gibt an, welches der nächst erreichbare Zonen-Name ist.

Ein Angreifer, der diesen Bug ausnutzt, muss die DNS-Datenbank verändern und seinen Nameserver als Zonen-Autorität einsetzen. Danach wird eine Anfrage auf die Zone des Angreifers gestartet, der nun die Auflösung von sich selbst erhält. Wenn nun Bind versucht, die Abfrage abzuschließen, indem er eine Verbindung zu dieser Zone zu etablieren, gerät es in einen kritisch instabilen Zustand. Nun tritt der Exploit in Kraft und führt die folgenden Kommandos aus cd /; uname -a; pwd; id womit ein Buffer Overflow erreicht wurde, Bind abstürzt und der Angreifer eine Shell erhält, inklusive sämtlicher Privilegien, mit denen Bind gestartet wurde (meist root).

Eine weiterer Bereich, in dem Schwachstellen auftreten können, ist der administrative Bereich. Hier werden oftmals Konfigurationsfehler, wie zu geringe Zugangsbeschränkungen (Authentifizierung) oder falsche Zoneninformationen, in den Konfigurationsdateien gemacht meist lediglich zum debuggen, oftmals aber auch aus Unkenntnis oder Faulheit. Diese Schwächen können leicht zum Verlust der Kontrolle oder der Daten des Systems führen, werden jedoch durch die neuen Features wie ACL oder DNSSEC, die später noch ausführlich beschrieben werden, entschärft.

Stillegen eines Nameservers

Ein weitere verbreitete Methode einen Nameserver zu attackieren, ist die Möglichkeit ihn durch sogenannte Denial-of-Service-Attacken (DoS) einfach stillzulegen damit er seine Zoneninformation, die er vorhält, nicht mehr weiterverbreiten kann. Als Folge davon kann es zu einem sehr großen Chaos und Durcheinander kommen, da doch viele Anwendungen lediglich mit einer Namensauflösung funktionieren bzw. diese zwingend benötigen.

Insgesamt wird dem DNS-DoS weit weniger Aufmerksamkeit geschenkt, als dem bekannteren IP-Spoofing, mit dem Web-Server attackiert werden, was zur Folge hat, dass die Administratoren dieses Thema nur unzureichend ernst nehmen.

Umleiten einer Domain

Ein noch effektiveres Ergebnis wird durch die Umleitung von Domains erzielt. Hierbei legt der Angreifer in erster Linie kein destruktives Verhalten an den Tag, sondern will die Fähigkeit des bestehenden Nameservers und der Domain für sich ausnutzen. Die Verluste, die dabei entstehen lassen sich teilweise nur sehr schlecht einschätzen, da meist ein Vertrauensbruch zwischen Kunde und Anbieter entsteht. Denn wer wird seine Daten oder Geld weiterhin an einen Anbieter weitergeben, der sich nicht mal selbst schützen kann. Entgangene Gewinne in der Zeit der Umleitung und danach sind ebenfalls als ein großer Verlust zu betrachten, der vor allem Anbieter betrifft, die ihr Geld mit Informationen oder Angeboten aus dem Internet verdienen, wie amazon.de, ebay oder auch booxtra.

Mit Cache Poisoning versucht der Angreifer den bestehenden Puffer-Cache infolge von Zusatzinformationen dahingehend umzuleiten, dass ein Besucher nicht mehr die richtige IP-Adresse zurückgeliefert bekommt, sondern die neue (falsche) Adresse. Diese neuen Informationen erhalten außerdem einen sehr langen Lebenszeit-Eintrag (Time To Live, TTL), da Bind jeden Eintrag erst nach Ablauf der TTL aus seinem Cache verbannt und somit Falschinformationen lang in Umlauf sind.

Beim Response Spoofing (Query-ID-Prediction) erfolgt die Manipulation auf der Paketebene. ähnlich eines TCP/IP-Handshackes wird in den Paketen eine 16-Bit-ID mitgesendet, die oftmals sequentiell erhöht wird. Hierbei wird versucht bei einer Kommunikation diese ID vorherzusagen und vor der eigentlichen Antwort eine gefälschte Nachricht zu senden. Die eigentliche Antwort wird bei Eintreffen sofort ignoriert und verworfen, da die ID nicht mehr korrekt, bzw. nicht mehr zuordenbar ist.

Bei der Man-in-the-Middle-Attacke setzt der Angreifer ebenfalls eine Falschinformation bei einem Nameserver ein und bekommt nun alle Anfragen zu dieser bestimmten Adresse weitergeleitet. Da dies generell jedem Anwender auffallen würde, wenn er an einem anderen Punkt herauskommt als erwartet, leitet der Angreifer die Anfrage an das ursprüngliche Ziel weiter und arbeitet nun als Vermittler. Warum aber der Aufwand? Gesetzt der Fall, dass das Ziel eine Bank oder ein Anbieter ist, das heikle Daten erwartet, bspw. PINs, TANs oder Kreditkartennummern, würde der Angreifer alle diese Daten zu Gesicht bekommen, abspeichern und weiterleiten. Der Anwender bekommt von dieser Zwischenspeicherung überhaupt nichts mit, denn er bekommt nur sein erwartetes Login oder seine gültige Verifikation zu sehen. Alles was dazwischen geschehen ist, bleibt ihm weitestgehend verborgen.

Abbildung 5: Man-in-the-Middle-Attacke

Eine strikte Trennung zwischen den einzelnen Angriffszielen ist nicht möglich, da es oft ein Mix aus allen möglichen Varianten ist. Generell lässt sich sagen, dass zwar Bind9 viele Sicherheitsrisiken durch seine Features ausgeräumt hat, aber bei rein destruktiven Angriffen auf Hardware (siehe DoS) dennoch keine Chancen hat.

Standard-Konfigurationen von Bind

Die vorliegenden Beispiele basieren auf der derzeit (September 2002) aktuellesten Bind-Version 9.2.1. Des Weiteren erfordert die Unterstützung für DNSSEC die Installation von OpenSSL > 0.9.5. Alle Pfadangaben beziehen sich somit auf eine Standardinstallation, d.h. die Datei »named.conf« liegt in »/etc« und die Programme rund um Bind in den Verzeichnissen »/usr/local/bin« bzw. »/usr/local/sbin«.

Die Datei »/etc/named.conf«

Zentraler Anaufpunkt einer jeden Bind-Konfiguration ist die Datei »/etc/named.conf«. Sie enthält die frei wählbaren Namen der Dateien mit den eigentlichen Datenbankeinträgen. Des Weiteren umfasst sie u.a. Steuerdaten, wie Protokollierung, Zugangsbeschränkungen, Schlüssel- und Zonendefinitionen oder Startoptionen für den Bind-Daemon »named«.

Vorerst begnügen wir uns mit einer relativ einfach aufgebauten Datei »named.conf«, anhand derer die Schritte zu einem funktionierenden Nameserver demonstriert werden. Im Verlauf des Abschnitts werden Sie mit etlichen weitergehenden Möglichkeiten der Konfiguration in dieser Datei konfrontiert werden.

In dieser kleinen Beispielkonfiguration sieht man, dass der Nameserver, der diese Datei verarbeitet, für die Zone zoneA.de als Master fungiert, d.h. er der primäre Ansprechpartner anderen zur Verfügung steht und das alle änderungen von ihm ausgehen. Der Parameter file beschreibt den Pfad, in dem die Zoneninformationen in verschiedene listenartigen ASCII-Dateien abgelegt werden. Dies ist nicht notwendigerweise zwingend, jedoch bei zunehmender Anzahl zu verwaltender Zonen, würden sonst alle Listen im definierten Root-Verzeichnis eingestellt. Es dient lediglich zur übersichtlichen Haltung der Daten. Bspw. kann der Administrator bei einem manuellen Zonentransfer der Einfachheit halber alle Listen im Verzeichnis rev/slave und slave löschen, ohne vorher überprüfen zu müssen, welche Zonen sich dahinter verbergen.

Zusätzlich zu diesen Daten fehlt noch der Eintrag für den Localhost (127.0.0.1) und die Root-Dateien. Der Localhost ist normalerweise immer sein eigener Master-Nameserver kann aber auch als Slave von anderen fungieren, da diese Informationen stets die gleichen sein müssten. Sicherer ist es, wenn eine Master-Zonendatei lokal vorgehalten wird, da bei einem Ausfall der Localhost nicht mehr angesprochen werden kann.

Die Root-Datei beinhaltet die Adressen aller Root-Server. Dies ist notwendig, wenn der Nameserver die Anfrage nicht auflösen kann und, wie in Abbildung 2 zu sehen ist, ganz oben in der Hierarchie beginnen muss, nach dem Ergebnis zu suchen. Diese Datei ist allerdings bei einem Forwarding nicht erforderlich, da alle unbekannten Abfragen immer an den Forwarder weitergeleitet werden. Eine aktuelle Version dieser Datei kann beim Internic bezogen werden.

Die Root-Zone

Der zentrale Punkt des DNS-Namensraums ist die Wurzel. Vermag ein Nameserver eine Anfrage nicht selbst aufzulösen, beginnt er mit der Suche nach dem Ergebnis ganz oben in der Hierarchie, also bei einem Nameserver, der die Root-Zone verwaltet (Vergleichen Sie auch Abbildung 2). Dessen Adresse muss jeder Nameserver zwingend kennen. Deshalb liegt jedem Bind-Paket eine Datei bei, die die Liste der Root-Server enthält. Die Adressen der Root-Server werden i.d.R. niemals geändert, sodass Sie von der Aktualität der Liste ausgehen können.

Die lokale Zone

Zonendefinitionen der zu verwaltenden Zonen

In den Zonendefinitionen selbst werden die einzelnen Systeme auf Adressen abgebildet.

Neu seit Bind8.2 ist der Eintrag TTL. In früheren Versionen wurde diese Option an anderer Stelle aufgeführt, aber seit der Veröffentlichung von RFC 2308 musste die TTL-Anweisung an einem anderen Ort angegeben werden und hierfür wurde die erste Zeile gewählt. Dieser Wert gibt an, wie lange ein abfragender Nameserver die Daten in seinem Cache halten darf, bevor er die Daten aus dem Cache wieder entfernt.

Der zweite wichtige Eintrag ist der SOA ( Start of Authority )-Eintrag. In dieser Zeile stehen die Zone, die Klasse, der Ressource Record selbst, die Autorität der Zone und den Ansprechpartner (Mailadresse auf der Autorität) bei Problemen.

Zusätzlich zu diesen Angaben beinhaltet dieser SOA-Eintrag noch einige Steuerdaten, wie Seriennummer, Aktualisierung oder Zeitpunkt der Ungültigkeit, wobei der wichtigste die Seriennummer darstellt, wie im nächsten Kapitel noch beschrieben wird.

Nachfolgend wird die Abbildung der Namen und Adressen vorgenommen. Die NS-Records geben den Namen aller Nameserver an, die mit der Zone etwas zu tun haben, die A-Records sind eine einfache Abbildung von Namen auf IP-Adressen, Mailserver-Einträge (MX) und CNAME-Records ( canonical names ) sind Aliase auf bereits beschriebene Namen, womit es möglich ist, ein System mit mehreren Namen anzusprechen.

Die andere wichtige Datei für eine Zone ist die in-addr.arpa -Datei, mit der das Reverse-Lookup ermöglicht wird. Hier auch ein kurzer Auszug mit den wichtigsten Informationen und Einträgen.

Die ersten beiden Zeilen haben dieselbe Bedeutung wie in der db.zoneA -Datei und dürfen auch hier nicht fehlen. Da diese Datei für das Reverse-Lookup zuständig ist werden hier mit Pointer-Records (PTR) von Adressen auf Namen verwiesen. Dabei wird die IP-Adresse in umgekehrter Form inklusive der Domain in-addr und Arpa angeben (Vgl. Abbildung 4 und 5), da die Auflösung, gleich der Auflösung von Namen, von rechts nach links erfolgt.

Wichtig bei beiden Dateien ist der Punkt hinter den Adress- und Namensangaben . Dieser Punkt symbolisiert die Wurzel (Root), von der alles ausgeht. Wird dieser Punkt nicht angegeben, so hat dies fatale Folgen, denn Bind interpretiert alle Angaben ohne Punkt als relativ und hängt den Zonennamen an. Als Beispiel hier ein Systemeintrag:

Dieser Name wird durch den fehlenden Punkt am Ende als server1.zoneA.de.zoneA.de. gesetzt und der Nameserver reagiert auch nur auf diesen Namen, d.h. er kennt das System server1 überhaupt nicht. Alternativ dazu gibt es die Möglichkeit den Punkt wegzulassen.

In diesem Fall wird richtigerweise an den Namen server1, die Zone .zoneA.de. angehängt. Sind diese beiden Zonen-Dateien auf dem Server vorhanden, so kann das System bereits alle Anfragen zu der verwalteten Zone beantworten.

Um nicht in jede Konfigurations-Datei immer dieselben gleichbleibenden Daten, wie MX-Einträge, SOA-Einträge oder Steuerdaten, eintragen zu müssen, werden diese oft in Dateien außerhalb abgelegt und per INCLUDE-Anweisung in diese Konfigurationsdateien eingefügt. Der Vorteil dieser Vorgehensweise ist vor allem bei änderungen an diesen Daten zu spüren. Sollte sich der SOA-Eintrag ändern oder ein zusätzlicher MX-Record dazukommen muss der Neueintrag lediglich in einer, anstelle von 300 Dateien vorgenommen werden.

Master- und Secondaryzonen

Im vorhergehenden Kapitel ging es rein um die Master-Dateien auf einem Server. Ein System, das als Master für eine Zone fungiert muss die beiden gerade genannten Dateien vorhalten und den Slave-Servern (falls vorhanden) zur Verfügung stellen. Der Slave-Server erkennt durch die Einträge in der /etc/named.conf für welche Zonen er Daten und von welchem Server er diese abrufen muss, d.h. auf ihm werden diese beiden Dateien keinesfalls erstellt. Schon allein aus Redundanz- und Fehlergründen werden die Dateien einmal erstellt (Master) und bei Bedarf transferiert (Slave), so minimiert sich die Pflege erheblich. Dies bedeutet auch, dass beide Zoneninformationsdateien, sowohl auf dem Master- als auch auf dem Slave-Nameserver, vollkommen identisch sind und beide dieselben Records beinhalten [Vgl. G].

Der Slave-Nameserver wird auch nicht bei jeden Aufruf einen Transfer initiieren, sondern lediglich, wenn die TTL ausläuft, die Zonendaten aus dem Cache entfernt oder sich die Seriennummer erhöht. Nun wird auch der Sinn der Seriennummer deutlich. Der Administrator muss bei jeder änderung die Seriennummer erhöhen. überprüft nun der Slave-Nameserver die Zonendateien und stellt fest, dass sich die Seriennummer erhöht hat, initiiert er sofort einen Transfer und bringt seinen Informationsbestand auf den neuesten Stand. Schneller geht es durch die Option notify. Hierbei versendet der Master-DNS eine Benachrichtigung an alle Slave-Nameserver, damit ein Update durchgeführt werden kann.

Nameserver-Start

Der Nameserver-Dienst verfügt über ein paar Startoptionen, die Ihnen die Möglichkeit geben, Ihre Umgebung individuell einzustellen. Hier die wichtigsten:
-c config-file: Alternativer Pfad für die named.conf-Datei, in der die gesamte Konfiguration abgelegt ist.
-d debug-level: Je höher das Debugging-Grad ist, desto mehr Meldungen sind zu sehen
-f : Dies weist den Dienst an, im Vordergrund zu arbeiten (also das Gegenteil zu den Daemons, die lediglich bei Anfragen aktiv werden)
-g : Standardmässig arbeitet der Serverdienst im Hintergrund und wird nur aktiv, wenn eine Anfrage auf seinem Port eintrifft
-p Port: Einstellmöglichkeit eines anderen Port. Der Standard ist Port 53
-t directory: Wenn Sie ein chroot-Umgebung implementiert haben, können Sie diese hier mitgeben
-u user: Dies ist der User, unter dem der Nameserver seinen noramlen Dienst erledigt. Normalerweise ist dies der User named, der bei der Installation angelegt wird.
-v: Gibt die Version mit aus

Erweiterte Konfigurationen

Caching und Forwarding

Jedem Nameserver stet ein Cache zur Verfügung, in dem er alle bereits getätigten Abfragen hinterlegt. Dies dient in erster Linie zum schnelleren Bearbeitung von Anfragen, denn wenn das Ergebnis bereits im Cache vorhanden ist, wird sofort geantwortet und andere Nameserver werden außen vor gelassen. Dies geschieht so lange, bis der Cache entweder gelöscht oder veraltet ist (TTL). Erst dann wird wieder der Weg über andere (evtl. Root-Server) gewählt. Eine besondere Form dieses Caches ist ein Cache-Only-DNS. Dieser Cache-Only-DNS stellt seinerseits keine Anfragen, sondern leitet erhaltene Anfragen lediglich weiter und speichert die erhaltenen Ergebnisse. In dieser Konfiguration beschränkt sich die /etc/named.conf nur auf das nötigste an Optionen. Die wichtigste Option stellt das Forwarding dar.

Beim Forwarding werden die Anfragen exakt an die in den Optionen angegebenen Nameserver weitergegeben. Diese Forwarder sind meist gut dimensionierte Nameserver größerer Firmen bzw. Provider, die über eine hohe Bandbreite auf die Root-Server zugreifen können. Mit dem Forwarding wird auch die eigene Vorhaltung der Root-Server-Datei hinfällig, da alles über diese Forwarder läuft. Eine weitere verschärfte Form eines Forward-DNS ist die Option forward only. Bei dieser Betriebsart leitet der Nameserver ebenfalls alle Anfragen weiter, jedoch verlässt er sich 100%-ig auf die Forward-DNS. Sollte der Forward-DNS kein Ergebnis oder eine Timeout zurückliefern, kontaktiert unser Nameserver keinen weiteren externen Nameserver, sondern vertraut dem Ergebnis des Forward-DNS. Allerdings bleiben die internen Zonen von diesem Forwarding unbetroffen, d.h. wenn Auflösungsanfragen über eine Zone deren Autorität (Master oder Slave) er ist, ankommen, beantwortet er diese natürlich.

Weiterführende Sicherheitsfunktionen und Schutzmechanismen

Diese grundlegenden Konfigurationen ermöglichen zwar einen Betrieb des Nameservers, jedoch gibt es unter Bind9 noch einige weitere fortgeschrittene Funktionen, die ein sichereres und differenzierteres Arbeiten und Administrieren ermöglichen. Die Entwicklung dieser Funktionen zielt in erster Linie in Richtung Sicherheit mit kryptografischen Elementen oder Zugangsbeschränkungen ab und genau diese Features und Funktionen werden in unserem Konzept benötigt um etwas hardening [Vgl. Anhang A Hardening] durchzuführen.

chroot Die abgesicherte Umgebung

Beim chroot ( change root ) handelt es sich um eine geschützte Arbeitsumgebung für Bind. Es wird, ähnlich wie bei FTP- oder HTTP-Servern, eine passende Dateistruktur in einem geschützten Bereich aufgebaut, eine Art Gefängnis , bei dem /chroot als Root-Verzeichnis fungiert. Als weitere Sicherheitsmassnahme wird in diesem Zusammenhang auch noch der Besitzer des Daemons, meist root, auf einen ungefährlicheren User gesetzt. Dies geschieht aus dem Grunde, falls ein Angreifer jemals die Kontrolle über den Nameserver, bspw. wie beschrieben durch Buffer Overflows, erlangt, so besitzt er sofort die Rechte, des Users, der den Daemon gestartet hat. Wenn dieser Fall eintritt, findet sich der Angreifer als unterprivilegierter User in einem eingeschränkten Bereich wieder, was doch sehr schnell das Interesse sinken lässt.

Oftmals wird dieser geschützte Bereich auch noch auf ein zusätzliches Filesystem ausgelagert, um bei einer eventuellen DoS-Attacke das eigentliche System nicht der Gefahr auszusetzen, einen Reboot machen zu müssen. Hier kann beim Erkennen, sofort das Filesystem abgehängt werden und das Betriebssystem bleibt weitestgehend unbeeindruckt davon. Da /chroot nun als Wurzelverzeichnis dient, sind andere Verzeichnisse nicht sichtbar und deshalb auch nicht erreichbar.

Aus diesem Grund müssen einige Dateien manuell in dieses Gefängnis kopiert werden, damit ein Betrieb möglich ist. Bei Bind9 sind es nur noch wenige Dateien, wie die Konfigurationsdatei /etc/named.conf und natürlich alle bereits angelegten Zoneninformationsdateien. Eine genauere Dokumentation ist im Anhang D zu finden.

ACL - Zugriffslisten

Ein weitverbreitetes Feature von Bind sind die ACLs ( access control list ). Bei diesen ACLs wird unter einem Arbeits- oder symbolischen Name, Systeme mit gleichen Berechtigungen oder Eigenschaften zusammengefasst, die später unter diesem Namen angesprochen werden. Diese Zusammenfassung wird Address-Match List genannt.

Neben der eigenen Vergabe noch ACLs gibt es noch einige vorgegebene Schlüsselwerte wie all (alle Systeme), none (kein System), localhost (alle internen Interfaces) und localnets (alle Netze, zu denen der Server ein direktes Interface besitzt).

Mit Hilfe dieser ACLs können nun die Berechtigungen sehr feinkörnig definiert werden.

In diesem Beispiel sind alle vier möglichen Berechtigungen kurz aufgeführt, die für die Zone zoneA.de gelten. Sollen diese Berechtigungen global gelten, so müssen sie unter die option -Option gestellt werden, da alle dort gemachten Einstellungen für sämtliche folgenden Zonen Gültigkeit besitzen.

Views - DNS Split

Der nächste Schritt, nachdem die ACLs definiert sind, ist eine Aufteilung in Sichten (Views). Dies bedeutet, verschiedene Systeme bekommen bestimmte zugeteilte Zoneninformationen zu sehen, andere jedoch nicht. Besonders in einer DMZ ist dies sehr hilfreich, da einerseits externe Nameserver und Clients aus dem Internet, als auch interne Systeme auf einige Zonen zugreifen dürfen, die nicht unbedingt die gleichen sein müssen.. Bei dieser Konstellation ist es nicht förderlich, wenn die interne Struktur von außen einsehbar ist. Gerade aus diesem Grund dürfen externen Anfragern lediglich die öffentlichen Zoneninformationen zur Verfügung stehen. Vor Bind9 wurde dieses Problem durch eine Aufteilung auf 2 Nameserver gelöst, wobei der eine für interne Zonen und der andere für externe Abfragen zuständig war. Nun, da dies mit internen Funktionen möglich ist, können gezielt Szenarien aufgebaut werden, die einen weiteren Schutzmechanismus bilden.

Die Option match-clients gibt an, für welche Systeme überhaupt die nachfolgenden Zonen zugänglich, bzw. sichtbar sind. Zur besseren Verwaltbarkeit sind diese meist als ACL angegeben. Der nun folgenden Rest ist äquivalent zu den bereits in vorigen Kapiteln beschriebenen Zonendefinitionen. Vorsichtig sollte der Administrator bei der Rangfolge sein, denn eine ANY-Zusage zu Beginn der Definition kann später nicht mehr zurückgenommen werden. Aus diesem Grunde werden zuerst beschränkten Zugriffe definiert, damit auf diese Zonen auch wirklich nur ausgewählte Systeme zugreifen können und erst danach wird der Nameserver für alle anderen geöffnet.

Ligthweight-Resolver

Laufzeitkonfiguration und Diagnose

Laufzeitkonfiguration mit Rndc

Rndc (Remote Name Daemon Control) ist ein Administrationstool, das dem Administrator eine Eingriffsmöglichkeit bietet mit der Befehlszeile den Daemon zu steuern. Es ist die Weiterentwicklung des Tools ndc, dass mit Bind8 zur Verfügung stand, um auch über ein bestehendes TCP-Netz die Kontrolle zu behalten. Mit ihm können Befehle wie Neuladen von Konfigurationsdateien oder Zonen (reload), Laden von neuen oder veränderten Zoneninformationen (reconfig), Statistiken (stats), Erstellen von Cache-Dumps (dumpdb), Stoppen nach gesicherten Veränderungen (stop), sofortiger Stop ohne Sicherung (halt), Erhöhen des Debug-Levels (trace), Leeren des Caches (flush) oder Anzeigen des Status des Nameservers (status).

Die Sicherheit der Netzadministration wird durch einen signierten Schlüssel gewährleistet, der mit einigen anderen Angaben in einer Steuerungsdatei namens /etc/rndc.conf steht.

Diagnose

named-checkconf

named-checkzone

Dynamisches DNS

Dynamisches DNS - DDNS

Bis jetzt wurden die IP-Adressen und die zugehörigen Systemnamen lediglich von Hand eingetragen, was bei jeder Neuaufnahme Arbeit nötig machte. Dies mag bei 10-20 Systemen noch recht überschaubar sein, jedoch können darüberhinaus doch immer wieder Flüchtigkeitsfehler, wie doppelte IP-Adressen, vergessene Punkte, usw, passieren, die den ganzen Netzwerkbetrieb lahmlegen könnten. Aber keine Angst, auch hier legen Ihnen die Netzwerkdienste einige Handwerksgeräte zur Verfügung. Eines davon ist das dynamische DNS. Dies bedeutet, dass Sie in Zusammenarbeit mit DHCP die IP-Adressen völlig frei zuteilen, diese Adressen automatisch dem DNS-System hinzugefügt werden und somit im Netzwerk bekannt und ansprechbar sind.

Um dies bewerkstelligen zu können, bedarf es jedoch einiger weniger kleiner Änderungen in der Konfigurationsdatei.
Der wichtigste Eintrag sollte bereits vorhanden sein - der Key-Eintrag, also der Schlüssel, der zur Authorisation und Authentifizierung herangezogen wird. Ebenfalls muss den RNDC erklärt werden, wer dem Nameserver Steueranweisungen und wie zukommen lassen darf. Dies geschieht mit dem Signalwort controls.

Natürlich ist der Schlüssel nur zur Sicherheit gedacht, d.h. es würde auch ohne ihn funktionieren, allerdings sollte ein gewisser Schutz und Sicherheit stets gewahrt bleiben um nicht später als Opfer dazustehen. Die zweite Änderung, die Sie machen müssen ist die allow-update-Option in den Zone-Definitionen.

Mit diesen beiden Optionen dürfen nun nur Systeme Veränderungen vornehmen, die auch im Besitz des Schlüssels sind. Damit wäre die Konfiguration für den Nameserver abgeschlossen. Den Rest muss nun der DHCP-Server erledigen, indem er die nur noch durch die geöffneten Türen treten muss und seine Veränderungen festschreiben.
Um zu überprüfen, ob das Zusammenspiel der beiden Server richtig funktioniert, können Sie mit den mitgelieferten Tools host oder dig sicherstellen, dass die Auflösung richtig ist. Bei der Auflösung müssten nun die neuen IP-Adressen erscheinen.
Bei Bind9 wird im Master- bzw. Reverse-Verzeichnis eine Datei angelegt mit dem Namen der Zonendatei und der Endung .jnl (Journal). Diese ist leider eine Binärdatei (bei Bind8 war es noch ein ASCII-File) und für den Benutzer nicht lesbar, jedoch muss diese Datei vorhanden sein, da hier die neuen DHCP-Adressen den Namen zugeordnet sind und darüber auch abgefragt werden. Angelegt werden diese beiden Dateien beim ersten Aufruf.