Linux Netzwerker-Handbuch Tony Bautts, Terry Dawson & Gregor N. Purdy 3. Auflage Juli 2005 ISBN 3-89721-414-8 382 Seiten Weitere Informationen zur gedruckten Version des Buches finden Sie unter: www.oreilly.de/catalog/linag3ger/ Zur Übersicht aller OpenBooks

Kapitel 5

Konfiguration des Namensdienstes

Wie wir bereits in Kapitel 2 beschrieben haben, können in einer TCP/IP-Umgebung verschiedene Methoden zum Konvertieren von Namen in Adressen zum Einsatz kommen. Am einfachsten ist es, eine Liste aller Hosts in der Datei /etc/hosts abzulegen. Das eignet sich aber nur für kleine LANs, die von einem einzigen Administrator betreut werden und keinen IP-Kontakt zur Außenwelt haben. Das Format der hosts-Datei wurde in Kapitel 4 vorgestellt.

Während der Ansatz mit der hosts-Datei für ein kleines Netzwerk ausreichend sein mag, müssen die meisten Administratoren einen DNS-Server aufsetzen. Es gibt mehrere Dienste, die Sie einsetzen können, um IP-Adressen aufzulösen. Am verbreitetsten ist der Berkeley Internet Name Domain Service (BIND) in der Version 8.x. Seit einiger Zeit ist auch BIND v9.x verfügbar. Die neue Version bietet einige neue Funktionen und behebt außerdem einige Sicherheitsprobleme, die bei BIND v8.x bestanden. Der Sprung von BIND 8 zu BIND 9 ist nicht ganz so bedeutend wie der Übergang von BIND 4 zu 8; viele der Konfigurationsdateien und -optionen sind identisch. Das Konfigurieren von BIND kann wirklich ziemlich aufwändig sein; sobald Sie es aber geschafft haben, können Sie ganz einfach Änderungen an der Netzwerktopologie vornehmen. Unter Linux wird der BIND-Dienst wie bei vielen anderen Unix-artigen Systemen durch ein Programm namens named bereitgestellt. Beim Start lädt dieses Programm eine Reihe von Master-Dateien in seinen internen Cache und wartet dann auf Anfragen von entfernten oder lokalen Benutzerprozessen. Es gibt verschiedene Möglichkeiten, um BIND einzurichten, und nicht alle setzen voraus, dass Sie auf jedem Host einen Nameserver betreiben.

Wir werden Ihnen darüber hinaus einen einfacheren und sichereren Weg, nämlich djbdns von David J. Bernstein, vorstellen. Dieser Resolver wurde von Grund auf neu entwickelt. Bei seiner Entwicklung wurden Sicherheitsaspekte besonders berücksichtigt; außerdem vereinfacht er die Einrichtung eines Servers in vielerlei Hinsicht, vor allem da die Notwendigkeit für (verwirrende) mehrfache Zonendateien entfällt.

Dieses Kapitel kann Ihnen kaum mehr als einen groben Überblick darüber bieten, wie DNS funktioniert und wie Sie einen Nameserver betreiben müssen. Für Leser mit einem kleinen LAN und einer Internet-Anbindung sollte es dennoch ausreichen. Die neuesten Informationen finden Sie in den Dokumentationen von BIND bzw. djbdns. In den entsprechenden Quellcodepaketen sind Manpages, Versionsinformationen sowie - im BIND-Paket - der BIND Operator's Guide (BOG) enthalten. Lassen Sie sich von diesem Namen nicht einschüchtern, tatsächlich handelt es sich um ein sehr nützliches Dokument. Eine umfassendere Behandlung von DNS und verwandten Themen finden Sie in DNS und BIND von Paul Albitz und Cricket Liu (O'Reilly). DNS-Fragen werden auch in einer Newsgroup namens comp.protocols.tcp-ip.domains beantwortet. Geht es um technische Details, dann sollten Sie wissen, dass das Domain Name System in den RFCs 1033, 1034 und 1035 definiert ist.

Die Resolver-Bibliothek

Der Begriff Resolver bezieht sich nicht auf eine besondere Anwendung, sondern auf die Resolver-Bibliothek. Es handelt sich dabei um eine Sammlung von Funktionen, die in der Standard-C-Bibliothek zu finden sind und durch eine Vielzahl von Netzwerkanwendungen aufgerufen werden. Die wichtigsten Routinen sind gethostbyname(2) und gethostbyaddr(2), die alle zu einem Hostnamen gehörenden IP-Adressen zurückliefern und umgekehrt. Sie können die Funktionen so konfigurieren, dass sie einfach die Informationen in hosts nachschauen oder eine Reihe von DNS-Nameservern abfragen.

Die Resolver-Funktionen lesen beim Aufruf Konfigurationsdateien. Diesen Konfigurationsdateien entnehmen sie, welche Datenbanken abgefragt werden sollen, in welcher Reihenfolge diese Abfragen stattfinden, und weitere Details, die für Ihre Umgebung relevant sind. Die ältere Linux-Standardbibliothek, libc, benutzte /etc/host.conf als Master-Konfigurationsdatei, seit Version 2 der GNU-Standardbibliothek, glibc, ist jedoch /etc/nsswitch.conf im Einsatz.

Die Datei nsswitch.conf

Die Datei nsswitch.conf erlaubt dem Systemadministrator, eine Vielzahl von unterschiedlichen Datenbanken zu konfigurieren. Wir beschränken unsere Diskussion auf Optionen, die mit der Auflösung von Host- und Netzwerk-IP-Adressen zu tun haben. Informationen über die anderen Funktionen und Eigenschaften finden Sie in der Dokumentation der GNU-Standardbibliothek.

Optionen in nsswitch.conf müssen auf eigenen Zeilen stehen. Felder können durch Leerräume (Leerzeichen oder Tabulatoren) getrennt werden. Ein Hash-Zeichen (#) steht vor einem Kommentar, der bis zum nächsten Newline-Zeichen reicht. Jede Zeile beschreibt einen bestimmten Dienst; die Hostnamenauflösung ist einer davon. Im ersten Feld jeder Zeile steht der Name der Datenbank, dahinter steht ein Doppelpunkt. Der Datenbankname, der mit der Auflösung der Hostadresse verknüpft ist, lautet hosts. Eine verwandte Datenbank ist networks, diese wird für die Auflösung von Netzwerknamen zu Netzwerkadressen eingesetzt. Den Rest der Zeile nehmen Optionen ein, die Möglichkeiten festlegen, wie die Datenbankanfragen ausgeführt werden.

Es stehen folgende Optionen zur Verfügung:

Benutzt das DNS zum Auflösen der Adresse. Das ist nur für die Auflösung von Hostadressen, nicht jedoch für Netzwerkadressen sinnvoll. Dieser Mechanismus verwendet die Datei fs, auf die wir später näher eingehen werden.

Durchsucht eine lokale Datei nach dem Host- oder Netzwerknamen und der dazugehörigen Adresse. Diese Option verwendet die traditionellen Dateien /etc/hosts und /etc/networks.

In der Reihenfolge, in der die Dienste angegeben sind, werden sie auch abgefragt, wenn ein Name aufgelöst werden soll. Diese Liste befindet sich in dem Abschnitt der Datei /etc/nsswitch.conf, in dem der Dienst beschrieben wird. Die Dienste werden von links nach rechts abgefragt; die Suche wird standardmäßig beendet, wenn die Auflösung erfolgreich war.

Beispiel 5-1 zeigt ein einfaches Beispiel einer Host- und Netzwerkdatenbankspezifikation, die das Verhalten unserer Konfiguration mit der älteren libc-Standardbibliothek nachbildet.

Dieses Beispiel veranlasst das System, Hosts zuerst im DNS zu suchen, und wenn dort nichts gefunden wird, die Suche in der Datei /etc/hosts fortzusetzen. Um Netzwerknamen aufzulösen, wird ausschließlich die Datei /etc/networks benutzt.

Sie können das Suchverhalten genauer kontrollieren, indem Sie zusätzlich Aktionen (action items) angeben, die anhand des Ergebnisses der jeweils vorhergehenden Suchanfrage ausgeführt werden. Handlungsanweisungen werden zwischen den Dienstangaben eingetragen und mit eckigen Klammern [ ] versehen. Die allgemeine Syntax einer Handlungsanweisung ist:

Es gibt zwei mögliche Handlungen:

Kontrolliert die Rückgabewerte an das Programm, das die Namensauflösung versucht hat. War ein Auflösungsversuch erfolgreich, liefert der Resolver die entsprechenden Details als Ergebnis, ansonsten eine Null.

Der Resolver nimmt den nächsten Dienst in der Liste in Anspruch und versucht damit eine Namensauflösung.

Das optionale Ausrufezeichen (!) gibt an, dass der Zustandswert vor dem Test invertiert werden soll; es entspricht dem logischen Nicht (not).

Es stehen folgende Statuswerte zur Verfügung:

Der angeforderte Eintrag wurde ohne Fehler gefunden. Die Standardaktion für diesen Zustand ist return.

Die Namenssuche verlief fehlerfrei, allerdings konnte der Zielhost oder das Zielnetzwerk nicht gefunden werden. Die Standardaktion für diesen Zustand ist continue.

Der angeforderte Dienst war nicht erreichbar. Das könnte bedeuten, dass die Dateien hosts oder networks für den files-Dienst unlesbar waren oder dass ein Nameserver oder NIS-Server für die Dienste dns oder nis nicht geantwortet hat. Die Standardaktion für diesen Zustand ist continue.

Dieser Zustand bedeutet, dass der Dienst zeitweise nicht verfügbar ist. Für den Dienst files weist dies normalerweise darauf hin, dass die relevante Datei von einem anderen Prozess blockiert wurde. Bei den anderen Diensten könnte es bedeuten, dass der Server zeitweise keine Verbindung akzeptiert hat. Die Standardaktion für diesen Zustand ist continue.

Beispiel 5-2 zeigt ein einfaches Anwendungsbeispiel für diesen Mechanismus.

In diesem Beispiel wird die Hostnamenauflösung mit dem Domain Name Service versucht. Ergibt sich ein anderer Zustand als »nicht verfügbar« (unavailable), dann liefert der Resolver das ermittelte Ergebnis zurück. Ergab der Versuch der Namensauflösung über das DNS den Zustand »nicht verfügbar«, dann (und nur dann) versucht der Resolver, die lokale Datei /etc/hosts zu benutzen. Das bedeutet, dass wir die hosts-Datei nur dann einsetzen sollten, wenn unser Nameserver aus welchen Gründen auch immer nicht erreichbar ist.

Konfiguration der Nameserver-Anfragen mit resolv.conf

Wenn Sie die Resolver-Bibliothek so konfigurieren, dass sie zur Ermittlung von Hostadressen den DNS-Namensdienst verwendet, müssen Sie ihr auch mitteilen, welche Server sie benutzen soll. Dafür gibt es eine eigene Datei namens resolv.conf. Fehlt diese Datei oder ist sie leer, nimmt der Resolver an, dass sich der Nameserver auf Ihrem lokalen Host befindet.

Um einen Nameserver auf Ihrem lokalen Host laufen zu lassen, müssen Sie ihn gesondert einrichten, wie es im folgenden Abschnitt, »Wie DNS funktioniert«, erläutert wird. Wenn Sie sich in einem lokalen Netzwerk befinden und die Möglichkeit haben, einen bereits vorhandenen Nameserver zu benutzen, sollten Sie auf jeden Fall darauf zurückgreifen. Falls Sie eine Wählverbindung ins Internet haben, werden Sie üblicherweise den Nameserver Ihres Providers in der Datei resolv.conf eintragen.

Die wichtigste Option in resolv.conf ist nameserver, die die Adresse eines Nameservers angibt. Wenn Sie die Option mehrmals festlegen, werden die Server in der angegebenen Reihenfolge ausprobiert. Deshalb sollten Sie unbedingt den zuverlässigsten Server zuerst eintragen. Wenn Sie keinen Nameserver vorgeben, nimmt der Resolver an, dass einer auf der lokalen Maschine läuft. Gegenwärtig werden bis zu drei nameserver-Einträge in resolv.conf unterstützt.

Zwei weitere Optionen, domain und search, erlauben es Ihnen, Kurznamen für die Hosts in Ihrer lokalen Domain zu benutzen. Wenn Sie beispielsweise einen anderen Host in Ihrer lokalen Domain ansprechen, wollen Sie im Allgemeinen nicht immer den voll qualifizierten Hostnamen eingeben, sondern auf der Kommandozeile lieber so etwas wie gauss benutzen und den Resolver den Domainnamen mathematics.groucho.edu anhängen lassen.

Genau dafür ist die domain-Anweisung da. Mit ihr können Sie eine Standard-Domain vorgeben, die immer dann angehängt werden soll, wenn ein Name nicht aufgelöst werden konnte. Wenn dem Resolver z.B. der Name gauss übergeben wird, versucht der Resolver zuerst, gauss. im DNS zu finden. Dieser Versuch schlägt fehl, da es keine solche Top-Level-Domain gibt. Wird mathematics.groucho.edu als Standard-Domain festgelegt, dann wiederholt der Resolver die Abfrage nach gauss, diesmal aber mit angehängter Standard-Domain, und ist erfolgreich.

Prima, werden Sie jetzt vielleicht denken, aber sobald Sie die Domain des mathematischen Instituts verlassen, müssen Sie wieder die voll qualifizierten Domainnamen schreiben. Natürlich wünschen Sie sich für die Hosts in der Domain des physikalischen Instituts ebenfalls Kurznamen wie quark.physics.

Hier kommt die Suchliste (search list) ins Spiel. Eine Suchliste kann mit der Option search angegeben werden und ist eine Verallgemeinerung der domain-Anweisung. Während Sie mit domain nur eine einzelne Domain angeben dürfen, akzeptiert search eine ganze Liste davon, deren Einträge alle der Reihe nach durchprobiert werden, bis ein gültiger Eintrag gefunden wird. Die einzelnen Namen der Liste müssen durch Leerzeichen oder Tabulatoren voneinander getrennt werden.

Die Befehle search und domain schließen einander aus und dürfen höchstens einmal auftauchen. Wenn keiner der beiden Befehle angegeben ist, versucht der Resolver, die Standard-Domain mit Hilfe des Systemaufrufs getdomainname(2) aus dem lokalen Hostnamen zu erraten. Hat der Hostname keinen Domain-Teil, dann wird als Standard-Domain die Root-Domain angenommen.

Angenommen, Sie sitzen in der virtuellen Brauerei und wollen sich auf foot.groucho.edu anmelden. Durch einen Tippfehler schreiben Sie aber foo statt foot. Dieser Server existiert jedoch nicht. Der Nameserver der GMU teilt Ihnen daher mit, dass er einen solchen Host nicht kennt. Bei älteren Suchmethoden würde der Resolver den Namen nun in den Domains vbrew.com und com suchen. Vor allem der letzte Fall ist problematisch, da es dort durchaus eine Domain namens groucho.edu.com geben kann. Wenn diese Domain dann auch noch einen Host namens foo enthält, landen Sie auf einer ganz anderen Maschine als beabsichtigt.

Für einige Anwendungen können diese fehlerhaften Zuordnungen ein Sicherheitsproblem darstellen. Aus diesem Grund sollten Sie die Suchliste auf die Unterdomains Ihrer Organisation oder etwas Vergleichbares beschränken. Im mathematischen Institut der Groucho-Marx-Universität würde die Liste beispielsweise nur maths.groucho.edu und groucho.edu enthalten.

Falls Ihnen das alles zu verwirrend vorkommt, dann werfen Sie einen Blick auf diese Beispieldatei resolv.conf der virtuellen Brauerei:

Wenn Sie den Namen vale auflösen, versucht der Resolver zuerst, vale. zu suchen, und wenn das fehlschlägt, vale.vbrew.com.

Robustheit des Resolvers

Wenn Sie ein LAN innerhalb eines größeren Netzwerks betreiben, sollten Sie auf jeden Fall zentrale Nameserver benutzen (falls verfügbar). Die Nameserver bauen im Laufe der Zeit umfangreiche Caches auf, die wiederholte Anfragen beschleunigen, da alle Anfragen an sie weitergeleitet werden. Dieses Vorgehen hat allerdings einen entscheidenden Nachteil: Als ein Brand ein Backbone-Kabel an der Universität eines der Autoren zerstörte, kam alle Arbeit im LAN seines Instituts zum Erliegen, da der Resolver keinen Nameserver mehr erreichen konnte. Daraus ergaben sich Probleme mit den meisten Netzwerkdiensten wie X-Terminal-Logins und Druckdiensten.

Obwohl es nun nicht gerade häufig passiert, dass Uni-Backbones in Flammen aufgehen, ist es durchaus sinnvoll, Vorsichtsmaßnahmen für solche Fälle zu treffen.

Eine Möglichkeit besteht darin, einen eigenen Nameserver aufzusetzen, der die lokale Domain bedient und alle Anfragen für andere Hostnamen an die zentralen Server weiterleitet. Natürlich funktioniert das nur, wenn Sie Ihre eigene Domain betreiben.

Alternativ können Sie eine Hosttabelle zur Sicherung Ihrer Domain oder Ihres LAN in /etc/hosts eintragen. Das ist schnell erledigt. Sie müssen einfach nur sicherstellen, dass die Resolver-Bibliothek zuerst das DNS abfragt und erst danach in der hosts-Datei nachschaut. In der Datei /etc/nsswitch.conf würden Sie daher mit hosts: dns files veranlassen, dass der Resolver auf die hosts-Datei zurückgreift, wenn der zentrale Nameserver nicht erreicht werden kann.

Wie DNS funktioniert

Das DNS verwaltet Hostnamen in einer Domain-Hierarchie. Eine Domain ist eine Ansammlung von Sites, die in einer bestimmten Beziehung zueinander stehen, sei es, weil sie ein gemeinsames Netzwerk bilden (z. B. alle Maschinen auf einem Universitätsgelände), weil sie alle einer bestimmten Organisation angehören (z. B. der US-Regierung) oder weil sie einfach nur geografisch dicht beieinander liegen. So sind beispielsweise amerikanische Universitäten gewöhnlich in der Domain edu zusammengefasst, wobei jede Uni ihre eigene Subdomain hat, die alle ihre Hosts umfasst. So hat die Groucho-Marx-Universität die Domain groucho.edu, in der das LAN des mathematischen Instituts die Subdomain maths.groucho.edu besitzt. Dieser Domainname wird an die Hostnamen der Hosts aus dem Institutsnetzwerk angehängt, so dass erdos den voll qualifizierten Domainnamen (FQDN) erdos.maths.groucho.edu trägt (siehe »Setzen des Hostnamens« in Kapitel 4).

Abbildung 5-1 zeigt einen Ausschnitt des Namensraums. Der Eintrag an der Wurzel dieses Baums, der durch einen Punkt gekennzeichnet ist, wird dementsprechend als Root-Domain bezeichnet und umfasst alle anderen Domains. Um zu verdeutlichen, dass ein Hostname ein voll qualifizierter Domainname ist und nicht etwa relativ zu einer (impliziten) lokalen Domain, wird er manchmal mit einem abschließenden Punkt geschrieben. Dieser Punkt zeigt an, dass die letzte Komponente des Namens die Root-Domain ist. Je nach ihrer Position in der Namenshierarchie wird eine Domain als Top-Level, Second-Level oder Third-Level bezeichnet. Es gibt noch weitergehende Unterteilungen, sie kommen aber selten vor. Tabelle 5-1 enthält diverse Top-Level-Domains, die Ihnen öfter begegnen werden.

Abbildung 5-1

Ein Ausschnitt des Domain-Namensraums

Früher wurden die ersten vier Domains den USA zugeordnet. Änderungen in der Politik führten aber dazu, dass diese globalen Top-Level-Domains (gTLD) nun von aller Welt genutzt werden können. Aktuelle Verhandlungen zur Ausweitung des Bereichs der gTLDs führten zu den drei letzten Ergänzungen. Allerdings haben sich diese neuen Möglichkeiten bisher noch nicht so recht durchsetzen können.

Außerhalb der USA benutzt jedes Land eine Top-Level-Domain aus zwei Buchstaben, die nach dem Landesnamen benannt und in ISO-3166 definiert sind. So verwendet z. B. Finnland die Domain fi, Frankreich fr, Deutschland de und die Antarktis aq. Unterhalb dieser Top-Level-Domains kann das NIC jedes Landes die Hostnamen nach Belieben organisieren. Australiens Second-Level-Domains sind denen der internationalen Top-Level-Domains sehr ähnlich, z. B. com.au und edu.au. Andere Länder wie Deutschland benutzen dieses Extra-Level nicht, sondern verwenden dafür ziemlich lange Namen, die direkt auf die Organisation hinweisen, die diese Domains inne hat. So sind z. B. Namen wie ftp://ftp.informatik.uni-erlangen.de durchaus üblich. Nennen Sie das deutsche Gründlichkeit, wenn Sie so wollen.

Natürlich bedeuten diese nationalen Domains nicht, dass ein Host unbedingt innerhalb dieser Domain im zugehörigen Land stationiert ist. Es bedeutet einfach nur, dass die Domain vom NIC des entsprechenden Landes registriert wurde. Zum Beispiel kann ein schwedischer Hersteller eine Filiale in Australien haben, deren Domain mit der Top-Level-Domain se endet.

Diese Praxis ist in den letzten Jahren sehr populär geworden. Länder wie Tuvalu (tv) und Togo (to) haben ihre TLDs an geschäftstüchtige Vermittler verkauft, die Domainnamen wie go.to oder watch.tv anbieten.

Die hierarchische Aufteilung des Namensraums in Domains löst auf elegante Weise das Problem der Eindeutigkeit von Namen. Mit DNS muss ein Hostname nur innerhalb seiner eigenen Domain eindeutig benannt sein; er ist damit weltweit eindeutig identifiziert. Außerdem kann man sich voll qualifizierte Namen leicht merken. Allein das sind schon sehr gute Gründe dafür, eine große Domain in mehrere Subdomains aufzuteilen.

Das DNS kann aber noch viel mehr für Sie tun. Es ermöglicht Ihnen auch, die Verantwortung über eine Subdomain an ihre Administratoren zu delegieren. Beispielsweise könnten die Verwalter des Groucho-Rechenzentrums für jedes Institut eine Subdomain erzeugen; den Subdomains maths und physics sind wir bereits oben begegnet. Wenn sie nun der Auffassung wären, das Netzwerk im physikalischen Institut ist zu groß und chaotisch, um von außerhalb verwaltet werden zu können (schließlich sind Physiker bekanntlich ja besonders widerspenstige Typen), könnten sie die Kontrolle der Domain physics.groucho.edu an die Administratoren dieses Netzwerks abgeben. Diese Administratoren könnten dann innerhalb dieser Domain nach Belieben Hostnamen und IP-Adressen aus ihrem Netzwerk vergeben, ohne sich dabei mit Außenstehenden absprechen zu müssen.

Aus diesem Grund wird der Namensraum immer in einzelne Zonen aufgeteilt, deren Wurzel jeweils eine Domain ist. Man beachte den feinen Unterschied zwischen einer Zone und einer Domain: Die Domain groucho.edu umfasst alle Hosts an der Groucho-Marx-Universität, während die Zone groucho.edu nur die Hosts enthält, die direkt vom Rechenzentrum verwaltet werden, z. B. die im mathematischen Institut. Die Hosts im Physik-Institut gehören dagegen einer anderen Zone an, nämlich physics.groucho.edu. In Abbildung 5-1 ist der Anfang einer Zone mit einem kleinen Kreis rechts neben dem Domainnamen markiert.

Namensanfragen mit DNS

Auf den ersten Blick scheint der ganze Zinnober um Domains und Zonen die Namensauflösung zu einer unnötig komplizierten Angelegenheit zu machen. Schließlich stellt sich ja die Frage: Woher soll eine schlichte Anwendung wissen, welche Namen zu welchen Hosts gehören, wenn es keine zentrale Autorität gibt, die diese Zuordnungen kontrolliert?

Jetzt kommt der wirklich geniale Teil von DNS. Wenn Sie beispielsweise herausfinden wollen, welche IP-Adresse zu erdos gehört, erhalten Sie von DNS die lapidare Antwort: »Fragen Sie diejenigen, die für dessen Verwaltung zuständig sind, die können es Ihnen sagen.«

Tatsächlich ist das DNS eine gigantische verteilte Datenbank. Implementiert ist sie mittels so genannter Nameserver, die Informationen über eine gegebene Domain oder eine ganze Reihe von Domains bereitstellen. Für jede Zone existieren mindestens zwei (bzw. höchstens einige wenige) Nameserver, die alle maßgeblichen Informationen über Hosts in dieser Zone bereithalten. Um die IP-Adresse von erdos zu bekommen, ist dafür lediglich der Nameserver für die Zone groucho.edu zu kontaktieren, der dann die gewünschte Information liefert.

Leichter gesagt als getan, werden Sie jetzt vielleicht denken. Woher soll ich denn wissen, wie ich den Nameserver an der Groucho-Marx-Universität erreiche? Keine Sorge, auch wenn Ihr Computer nicht gerade mit einem adressauflösenden Orakel ausgestattet ist, hilft Ihnen das DNS auch in diesem Punkt aus der Patsche. Wenn Ihre Anwendung Informationen über erdos haben möchte, setzt sie sich zunächst mit einem lokalen Nameserver in Verbindung, der dafür eine so genannte iterative Anfrage startet. Zunächst sendet er eine Anfrage an einen Nameserver für die Root-Domain, in der er nach der Adresse von erdos.maths.groucho.edu fragt. Der angesprochene Root-Nameserver erkennt, dass dieser Name nicht zu den von ihm autorisierten Zonen gehört, dafür aber zu einer unterhalb der Domain edu liegenden Zone. Folglich gibt er Ihrem Nameserver die Empfehlung, sich an einen Nameserver zu wenden, der für die Zone edu zuständig ist, und präsentiert ihm dafür eine Liste aller edu-Nameserver samt ihrer Adressen. Ihr lokaler Nameserver setzt daraufhin seine Arbeit fort und fragt einen der in der Liste enthaltenen Server, z. B. a.isi.edu. Dieser verfährt ähnlich wie der Root-Nameserver; er weiß, dass die Leute von groucho.edu ihre eigene Zone verwalten, und verweist Sie daher an deren Server. Schließlich befragt Ihr lokaler Nameserver einen dieser Server nach erdos und erhält endlich die gewünschte Antwort, da dieser Name zur Zone des befragten Servers gehört und dieser die zugehörige IP-Adresse zurückliefern kann.

Das Ganze erweckt den Eindruck, dass ziemlich viel Datenverkehr in Gang gesetzt werden muss, nur um so eine klitzekleine IP-Adresse herauszufinden. In Wirklichkeit ist das aber nichts, verglichen mit der heute üblichen Geschwindigkeit von Netzwerken. Es gibt aber immer noch Raum für Optimierungen.

Um die Antwortzeiten für zukünftige Anfragen zu verringern, speichert Ihr Nameserver die ermittelten Informationen in seinem lokalen Speicher (Cache). Wenn das nächste Mal jemand in Ihrem lokalen Netz eine Hostadresse der Domain groucho.edu benötigt, schaut Ihr Nameserver in seinem Cache nach und leitet die Anfrage direkt an den groucho.edu-Nameserver weiter.¹

Natürlich behält der Nameserver diese Informationen nicht für immer und ewig; er löscht sie nach einer gewissen Zeit. Diese Zeit bis zur Löschung wird Lebensdauer (Time To Live; TTL) genannt. Die Administratoren der betroffenen Zone teilen jedem Datensatz in der DNS-Datenbank eine solche TTL zu.

Arten von Nameservern

Nameserver, die sämtliche Informationen über die Hosts einer Zone verwalten, sind für diese Zone verantwortlich (autoritativ). Sie werden auch als Master-Nameserver bezeichnet. Jede Anfrage über einen Host in dieser Zone endet schließlich bei einem dieser Nameserver.

Master-Nameserver müssen immer ziemlich gut synchronisiert werden. Daher macht der Netzwerkadministrator einer Zone einen der Master-Server zum primären Server und die anderen zu sekundären Servern. Der primäre Server lädt alle seine Zoneninformationen aus Datendateien; die sekundären Server kopieren diese Informationen in regelmäßigen Abständen vom primären Master-Nameserver.

Wenn man mehrere Nameserver zur Verfügung hat, kann das Arbeitspensum auf sie verteilt werden; außerdem bieten sie die Möglichkeit zur redundanten Datenhaltung. Fällt einer der Nameserver einmal aus, z. B. durch Absturz oder Verlust der Netzwerkverbindung, werden alle Anfragen an diesen Server an die anderen weitergeleitet. Allerdings schützt Sie dieses Verfahren nicht vor Fehlfunktionen der Server, die sich anhand von falschen DNS-Antworten bemerkbar machen. Ursachen solcher Fehler können Bugs in der Serversoftware sein.

Sie können auch einen Nameserver betreiben, der für überhaupt keine Domain verantwortlich ist.² Das ist durchaus sinnvoll, da der Nameserver weiterhin DNS-Anfragen für die Anwendungen im lokalen Netzwerk in seinem Cache speichern kann. Ein solcher Server wird daher als Caching-only-Server bezeichnet.

Die DNS-Datenbank

Wir haben gesehen, dass DNS nicht nur mit IP-Adressen von Hosts arbeitet, sondern auch Informationen über Nameserver austauscht. DNS-Datenbanken können in der Tat viele verschiedene Arten von Einträgen aufweisen.

Jede Einzelinformation in einer DNS-Datenbank wird als Resource Record (RR) bezeichnet. Jeder Record enthält einen Typ, der Auskunft über die Art der Information liefert, sowie eine Klasse, die Auskunft über den Netzwerktyp gibt, für den die Information bestimmt ist. Die Klassen werden für die verschiedenen Adress-Schemata benötigt, wie IP-Adressen (die Klasse IN), Hesiod-Adressen (vom Kerberos-System des MIT benutzt) und einige mehr. Der Prototyp eines solchen Resource-Record-Typs ist der A-Record, der einen voll qualifizierten Domainnamen mit einer IP-Adresse verknüpft.

Ein Host kann unter mehreren Namen bekannt sein. Zum Beispiel könnten Sie einen Server besitzen, der sowohl FTP- als auch WWW-Dienste anbietet und unter den Namen ftp.machine.org und www.machine.org erreichbar ist. Einer dieser Namen muss als offizieller bzw. kanonischer Hostname eingetragen sein; die anderen Namen sind einfach nur Aliasnamen, die auf den offiziellen Hostnamen verweisen. Der Unterschied besteht darin, dass ein kanonischer Hostname immer mit einem A-Record assoziiert ist, während die Aliasnamen einen Record vom Typ CNAME besitzen, der auf den kanonischen Hostnamen verweist.

Wir werden hier nicht alle Record-Typen behandeln, stellen dafür aber ein kurzes Beispiel vor. Beispiel 5-3 zeigt einen Ausschnitt der Domain-Datenbank, die in die Nameserver für die Zone physics.groucho.edu geladen wird.

Außer den A- und CNAME-Records sehen Sie am Anfang der Datei einen speziellen Record, der sich über mehrere Zeilen erstreckt. Das ist der SOA-Resource-Record (Start of Authority). Er enthält allgemeine Informationen über die Zone, für die der Server zuständig ist, so zum Beispiel über die Lebensdauer aller Records.

Beachten Sie, dass alle Namen in der Beispieldatei, die nicht mit einem Punkt enden, als relativ zur Domain physics.groucho.edu aufzufassen sind. Der spezielle Name (@) im SOA-Record verweist auf den Domainnamen an sich.

Wir haben bereits früher gesehen, dass die Nameserver für die Domain groucho.edu irgendetwas über die Zone physics wissen müssen, um Anfragen an deren Nameserver stellen zu können. Diese Informationen werden normalerweise über ein Paar von Records bereitgestellt, bestehend aus dem NS-Record, der den FQDN des Servers ergibt, und einem A-Record, der eine IP-Adresse mit diesem Namen assoziiert. Da diese Records sozusagen der »Kleber« sind, der den Namensraum zusammenhält, werden sie oft als Glue Records bezeichnet. Sie sind die einzigen Arten von Records, bei denen eine übergeordnete Zone tatsächlich Informationen über Hosts der untergeordneten Zone enthält. Die Glue Records, die auf die Nameserver für physics.groucho.edu verweisen, sehen Sie in Beispiel 5-4.

Die BIND-Datei named.conf

Die primäre Konfigurationsdatei von BIND ist /etc/named.conf. Diese Art der Konfigurationsdatei wird von BIND benutzt, seit Version 8 die alte named.boot-Datei ersetzt hat.

Die Syntax ist einigermaßen komplex und unterstützt eine Vielzahl von Funktionen. Es ist aber relativ einfach, eine Grundfunktionalität zu konfigurieren. Beispiel 5-5 zeigt eine einfache Konfigurationsdatei für die Domain vbrew.

Wenn Sie genauer hinsehen, werden Sie feststellen, dass jede der Anweisungen ähnlich einer C-Anweisung geschrieben ist, wobei die Attribute in der named.conf-Datei in {  }-Zeichen eingeschlossen sind.

Die Kommentare, die in Linux oft durch ein Hash-Zeichen (#) gekennzeichnet sind, werden hier durch zwei Schrägstriche (//) eingeleitet.

Eine der wichtigsten Optionen in dieser Konfigurationsdatei ist zone. Mit dieser Datei teilen Sie BIND mit, was es wissen soll. Neben zone gibt es eine weitere wichtige Option, allow-transfer. Mit dieser Option können Sie die IP-Adressen festlegen, denen es gestattet ist, einen Zonentransfer durchzuführen. Es ist wichtig, diese Zonentransfers auf autorisierte Einheiten zu beschränken, da dabei eine Menge Informationen verarbeitet werden, die für potenzielle Angreifer von Bedeutung sein können. In den Beispielkonfigurationsdateien haben wir Zonentransfers auf die drei aufgeführten IP-Adressen beschränkt.

In der option-Anweisung haben wir außerdem die DNS-Rekursion deaktiviert. Auf diese Weise können wir die DNS-Server-Funktionalität von der DNS-Cache-Funktionalität trennen. Das ist schon aus Sicherheitsgründen ratsam. Zu diesem Thema ist schon viel geschrieben worden; eine der besten Erklärungen finden Sie unter http://cr.yp.to/djbdns/separation.html. Wenn Sie Rekursion benötigen, dann ist es am besten, einen Caching-Only-Server unter einer anderen IP-Adresse als derjenigen Ihres DNS-Servers zu konfigurieren. Wir werden in Kürze darauf eingehen, wie Sie mit BIND einen Caching-Only-Server aufsetzen.

Falls Sie nun beschlossen haben, dass Sie ohne Rekursion auf demselben Server nicht auskommen, dann gibt es innerhalb der Datei named.conf Möglichkeiten, die Rekursion auf bestimmte Domains zu beschränken. Indem Sie die Option allow-recursion anstelle von recursion no verwenden, können Sie einen Bereich von IP-Adressen einstellen, denen es erlaubt ist, rekursive Abfragen durchzuführen.

Sie haben vermutlich bemerkt, dass wir in diese Datei ein paar weitere Einträge als nur die Domain vbrew.com aufgenommen haben. Diese Einträge dienen der Konformität mit den Spezifikationen, die in RFC 1912, »Common DNS Operational and Configuration Errors«, niedergelegt sind. Diese Spezifikation fordert, dass Sites für die Localhost-Forward- und Reverse-Zonen sowie für Broadcast-Zonen die Autorität besitzen sollen.

Die BIND-Konfiguration unterstützt viele weitere Optionen, auf die wir hier nicht eingegangen sind. Wenn Sie sich über alle Optionen informieren wollen, empfehlen wir Ihnen die Dokumentation, die im Quellcodepaket von BIND Version 8 oder 9 enthalten ist.

Die DNS-Datenbankdateien

Zu jeder Master-Datei, die named bearbeitet, gehört eine Domain, die als Ursprung (origin) bezeichnet wird. Das ist der Domainname, der mit den Optionen cache und primary festgelegt wird. Innerhalb einer Master-Datei können Sie Domain- und Hostnamen relativ zu dieser Domain angeben. Ein Name, der in einer Konfigurationsdatei angegeben wird, wird als absolut betrachtet, wenn er mit einem Punkt endet, andernfalls ist er relativ zum Ursprung. Der Domainname @ bezieht sich auf den Ursprung selbst.

Die Daten in einer Master-Datei sind in Resource Records (RRs) aufgeteilt. Diese stellen die kleinste durch das DNS erhältliche Informationseinheit dar. Jeder Resource Record hat einen bestimmten Typ. A-Records bilden beispielsweise einen Hostnamen auf eine IP-Adresse ab, und ein CNAME-Record verknüpft einen Alias für einen Host mit seinem offiziellen Hostnamen. Im weiteren Verlauf dieses Kapitels lernen Sie ein Beispiel für eine vollständige Konfiguration und Zonendateien kennen.

In den Master-Dateien haben alle Resource Records ein gemeinsames Format:

Die einzelnen Felder werden durch Leerzeichen oder Tabulatoren voneinander getrennt. Manche Einträge können über mehrere Zeilen fortgesetzt werden, wenn vor dem ersten Newline-Zeichen eine öffnende Klammer steht und auf das letzte Feld eine schließende Klammer folgt. Alles zwischen einem Semikolon und dem Newline-Zeichen wird ignoriert. Es folgt eine Beschreibung der einzelnen Formate:

Dies ist der Domainname, für den der Eintrag gilt. Wenn kein Domainname angegeben ist, bezieht sich der RR auf die Domain des vorherigen RR.

Um Resolver dazu zu zwingen, im Cache gespeicherte Informationen nach einer bestimmten Zeit zu verwerfen, wird jedem RR eine Lebensdauer zugeordnet (Time To Live, TTL). Das Feld ttl legt die Zeit in Sekunden fest, die der Eintrag gültig ist, nachdem er vom Server abgerufen wurde. Der Wert ist eine Dezimalzahl mit höchstens acht Ziffern.

Wenn kein ttl-Wert angegeben ist, wird der im minimum-Feld des vorherigen SOA-Records festgelegte Vorgabewert verwendet.

Das ist eine Adressklasse, wie IN für IP-Adressen oder HS für Objekte in der Hesiod-Klasse. Für TCP/IP-Netzwerke müssen die Einträge den Typ IN haben.

Wenn keine Klasse angegeben ist, wird die Klasse des vorherigen RR angenommen.

Das beschreibt den Typ des RR. Die gebräuchlichsten Typen sind A, SOA, PTR und NS. In den folgenden Abschnitten werden die verschiedenen RR-Typen vorgestellt.

Dieses Feld enthält die Daten, die zum RR gehören. Das Format dieses Feldes ist von der Art des RR abhängig. Im Folgenden werden wir das Format für jeden einzelnen RR beschreiben.

Das Folgende ist eine unvollständige Liste von RRs, die in DNS-Master-Dateien verwendet werden können. Es gibt noch mehr, auf die wir hier aber nicht eingehen werden. Sie haben eher experimentellen Charakter und sind im Allgemeinen nicht besonders nützlich.

Dieser RR beschreibt eine Zone innerhalb des Verantwortungsbereichs dieses Servers (SOA bedeutet Start of Authority). Er macht deutlich, dass die Records, die dem SOA-RR folgen, autoritative Informationen für die Domain enthalten. Jede Master-Datei, die durch eine primary-Anweisung eingebunden wird, muss mit einem solchen SOA-Record beginnen. Das Datenfeld enthält folgende Felder:

Dieser Record verknüpft eine IP-Adresse mit einem Hostnamen. Das Datenfeld enthält die Adresse in Dotted-Quad-Notation.

Für jeden Hostnamen darf es immer nur einen A-Record geben. Der in diesem A-Record benutzte Hostname ist der offizielle oder kanonische Hostname. Alle anderen Hostnamen sind Aliase und müssen mittels eines CNAME-Records auf den kanonischen Hostnamen abgebildet werden. Wenn der kanonische Name unseres Hosts vlager wäre, hätten wir einen A-Record, der diesen Hostnamen mit seiner IP-Adresse assoziiert. Angenommen, wir wollten einen weiteren Namen mit dieser IP-Adresse haben, etwa news. Dann müssten wir einen CNAME-Record erzeugen, der diesen alternativen Namen mit dem kanonischen Namen assoziiert. Über CNAME-Records reden wir in Kürze.

Dieser Record ist identisch mit dem A-Record, wird aber ausschließlich für IPv6-Adressen benutzt.

NS-Records dienen dazu, den primären und alle sekundären Nameserver einer Zone anzugeben. Ein NS-Record zeigt auf den Master-Nameserver einer bestimmten Zone, das Resource-Datenfeld enthält den Hostnamen des Nameservers.

Ihnen werden NS-Records in zwei Situationen begegnen. Sie werden zum einen benutzt, wenn Sie die Autorität an eine untergeordnete Zone delegieren, andererseits tauchen sie in den Master-Zonendateien der untergeordneten Zone selbst auf. Die Listen der Server, die jeweils in der delegierenden und delegierten Zone aufgeführt werden, müssen übereinstimmen.

Der NS-Record legt den Namen des primären Nameservers sowie die Namen der sekundären Nameserver einer Zone fest. Diese Namen müssen zu einer IP-Adresse aufgelöst werden, um benutzt werden zu können. Manchmal gehören die Server aber zu der Domain, die sie selbst bedienen, was einem »Henne-und-Ei-Problem« gleichkommt. Wir können die Adressen nicht auflösen, bevor der Nameserver erreichbar ist, wir können aber auch den Nameserver nicht erreichen, bevor wir seine Adresse kennen. Um uns aus diesem Dilemma zu befreien, können wir spezielle A-Records direkt in den Nameserver der übergeordneten Zone eintragen, die es den Nameservern der übergeordneten Domain erlauben, die IP-Adresse der Nameserver der delegierten Zone aufzulösen. Diese Records werden normalerweise als Glue Records (glue = Leim) bezeichnet, da sie gewissermaßen die delegierte Zone an ihre übergeordnete Zone binden (kleben). Im Abschnitt »Die DNS-Datenbank« weiter vorn finden Sie eine Erklärung für die Funktionsweise dieses Mechanismus.

Dieser Record verknüpft einen Alias mit dem kanonischen Hostnamen eines Hosts. Er stellt einen alternativen Namen zur Verfügung, unter dem sich die Benutzer an den Host wenden können, dessen kanonischer Name als Parameter angegeben ist. Der kanonische Hostname ist derjenige, für den die Zonendatei einen A-Record enthält. Aliase verweisen über einen CNAME auf diesen Hostnamen und besitzen keine weiteren Records.

Dieser Record wird verwendet, um Namen in der Domain in-addr.arpa mit Hostnamen zu verknüpfen. Er wird für das Reverse Mapping von IP-Adressen auf Hostnamen benutzt. Beim angegebenen Hostnamen muss es sich um den kanonischen Hostnamen handeln.

Dieser RR legt einen so genannten Mail Exchanger für eine Domain fest. Mail Exchanger werden in 1, 2

host benennt den MX für domain. Jedem Mail Exchanger ist eine ganzzahlige präferenz zugeordnet. Ein Mail-Transportprogramm, das eine Nachricht an domain ausliefern möchte, probiert alle Hosts, die einen MX-Record für diese Domain haben, der Reihe nach durch, bis es die Mail erfolgreich ausliefern kann. Dabei beginnt es mit dem MX mit der niedrigsten Präferenz und arbeitet die Liste in aufsteigender Reihenfolge ab.

Dieser Record enthält Informationen über die Hardware und Software des Systems. Seine Syntax lautet:

Das hardware-Feld beschreibt die Hardware, auf der das System läuft, in einem besonderen Format. Wenn das Feld Leerzeichen enthält, muss es in doppelte Anführungszeichen eingeschlossen werden. Das software-Feld bezeichnet das Betriebssystem des Hosts. Aus Sicherheitsgründen ist es allerdings unklug, diese Informationen zu veröffentlichen, da Angreifern möglicherweise wertvolle Informationen geliefert werden. In jüngster Zeit sieht man diesen Record nur noch selten im Einsatz, allerdings machen sich manche Administratoren einen Spaß daraus, damit falsche oder lustige Informationen über ihre Hosts zu verbreiten.

HINFO-Records zum Beschreiben von Maschinen könnten so aussehen:

Caching-Only-Konfiguration für named

Bevor wir uns auf die vollständige Konfiguration eines Nameservers stürzen, sollten wir noch kurz über eine ganz besondere named-Konfiguration sprechen: die Caching-Only-Konfiguration. Eine solche Konfiguration stellt keinen Domain-Dienst an sich dar, sondern dient als Relais für alle DNS-Abfragen, die auf Ihrem Host erzeugt werden. Der Vorteil dieses Schemas liegt darin, dass damit ein Cache aufgebaut wird, so dass nur noch die erste Anfrage nach einem bestimmten Host an die Nameserver im Internet gesandt werden muss. Jede nachfolgende gleich lautende Anfrage wird dann direkt aus dem Cache Ihres lokalen Nameservers heraus beantwortet. Sie sollten dabei allerdings bedenken, dass ein Cache-Server nicht unter der gleichen IP-Adresse ausgeführt werden sollte wie der DNS-Server.

Eine named.conf-Datei für einen Caching-Only-Server sieht so aus:

Zusätzlich zu dieser named.conf-Datei müssen Sie die root.hint-Datei mit einer gültigen Liste von Root-Nameservern einrichten. Sie könnten dafür einfach Beispiel 6.10 kopieren. Oder noch besser: Sie könnten ein BIND-Programm namens dig einsetzen, um die neueste Version dieser Datei zu beziehen. Für die Konfiguration eines Caching-Only-Servers sind keine weiteren Dateien erforderlich. Wir werden dig weiter hinten in diesem Kapitel ausführlicher besprechen. Um die Informationen zu erhalten, die Sie zur Erstellung der root.hint-Datei brauchen, verwenden Sie vorerst folgenden Befehl:

Die Master-Dateien schreiben

Die Beispiele 5-6, 5-7, 5-8 und 5-9 zeigen Konfigurations- und Zonendateien für einen Nameserver in der Brauerei, der auf vlager läuft. Aufgrund der Natur des Netzwerks, das hier vorgestellt wird (ein einzelnes LAN), ist dieses Beispiel relativ einfach.

Die Cache-Datei root.hint, die in Beispiel 5-6 zu sehen ist, zeigt beispielhafte Hint-Records für einen Root-Nameserver. Eine typische Cache-Datei beschreibt normalerweise ungefähr ein Dutzend Nameserver. Sie können die aktuelle Liste der Nameserver für die Root-Domain mit Hilfe des Programms dig beziehen, wie oben beschrieben wurde.

Test Ihrer Nameserver-Konfiguration

dig ist das aktuelle Werkzeug der Wahl zum Abfragen von Nameservern und ersetzt das bekannte nslookup. Es ist flexibel, schnell und kann dazu verwendet werden, um nahezu alles von einem DNS-Server abzufragen. Die Syntax für dig ist sehr einfach.

Die Kommandozeilenparameter sind folgendermaßen definiert:

Das ist der Name des Servers, den Sie abfragen. Er kann als Name oder als IP-Adresse eingegeben werden. Falls Sie diesen Wert leer lassen, verwendet dig den DNS-Server, der in der Datei resolv.conf aufgeführt ist.

Das ist der Name des DNS-Records, den Sie abfragen wollen.

Das ist der Typ der Anfrage, die Sie ausführen wollen. Gebräuchliche Typen sind ANY, MX und TXT. Bleibt dieses Feld leer, sucht dig standardmäßig nach einem A-Record.

Mit Hilfe dieses Befehls wollen wir nun einmal nachschauen, welche Server die Mail für die virtuelle Brauerei verarbeiten. Wir führen daher folgende dig-Abfrage durch:

Ein anderes Beispiel für einen interessanten Abfragetyp, der ganz nützlich sein kann, ist die Abfrage der BIND-Version. Diese wird leicht mit dig und der folgenden Syntax erledigt:

nslookup benutzen

nslookup ist zwar inzwischen veraltet, bietet aber immer noch eine gute Methode, um die Funktionsweise Ihrer Nameserver-Konfiguration zu testen. Der Befehl kann sowohl interaktiv mit Prompts als auch als einfacher Befehl mit sofortiger Ausgabe benutzt werden. In diesem Fall rufen Sie ihn so auf:

nslookup befragt dann den in resolv.conf angegebenen Nameserver nach hostname. (Nennt diese Datei mehr als einen Server, wählt nslookup zufällig einen aus.)

Der interaktive Modus ist allerdings wesentlich spannender. Sie können in diesem Modus nicht nur einzelne Hosts auflösen, sondern auch nach beliebigen DNS-Records suchen und die gesamten Zoneninformationen einer Domain auflisten.

Wenn Sie den Befehl ohne Argumente aufrufen, gibt nslookup den Namen des verwendeten Nameservers aus und geht in den interaktiven Modus. Am Prompt können Sie nun beliebige Domainnamen eingeben. Per Voreinstellung fragt es nach A-Records, die die zum Domainnamen gehörende IP-Adresse enthalten.

Sie können sich bestimmte Record-Typen mit

ansehen, wobei typ einer der oben beschriebenen RRs oder der String ANY ist.

Ein Dialog mit nslookup könnte beispielsweise folgendermaßen aussehen:

In der Ausgabe erscheint zunächst der befragte DNS-Server und danach das Ergebnis der Anfrage.

Wenn Sie einen Namen angeben, zu dem es keine IP-Adresse gibt, aber andere Record-Typen in der DNS-Datenbank gefunden wurden, gibt nslookup die Fehlermeldung »No type A records found« zurück. Mit dem Befehl set type können Sie nslookup aber dazu bringen, auch andere Typen als A anzuzeigen. Um beispielsweise den SOA-Record für unc.edu zu bekommen, würden Sie etwa Folgendes eingeben:

Ganz ähnlich können Sie nach MX-Records fragen:

Wenn Sie den Typ auf ANY setzen, gibt nslookup alle Resource-Records aus, die zu dem angegebenen Namen gehören.

Außer für das Debugging Ihrer Konfiguration können Sie nslookup auch noch verwenden, um die aktuelle Liste der Root-Nameserver zu erhalten. Dazu fragen Sie nach allen NS-Records, die für die Root-Domain definiert sind:

Um eine Übersicht über alle Befehle zu bekommen, die nslookup bietet, geben Sie am Prompt den Befehl help ein.

Weitere nützliche Werkzeuge

Es gibt noch einige andere Werkzeuge, die Ihnen bei Ihren Aufgaben als BIND-Administrator helfen können. Wir werden zwei von ihnen kurz beschreiben. Wenn Sie wissen wollen, wie diese Programme bedient werden, lesen Sie bitte die Dokumentationen, die ihnen beiliegen.

hostcvt ist ein Programm, das Ihnen bei Ihrer anfänglichen BIND-Konfiguration behilflich ist, indem es Ihre /etc/hosts in Master-Dateien für named umsetzt. Es erzeugt sowohl A-Records (zur Vorwärtsauflösung) als auch PTR-Records (für Reverse Mapping) und achtet auf Aliase. Natürlich kann es Ihnen nicht alles abnehmen, zumal Sie vielleicht noch einige der Voreinstellungen im SOA-Record anpassen oder MX-Records eintragen wollen. Trotzdem ersparen Sie sich mit diesem Werkzeug einiges an Kopfschmerzen. hostcvt ist Teil der BIND-Distribution, ist aber auch als einzelnes Paket zu finden.

Nachdem Sie Ihren Nameserver aufgesetzt haben, wollen Sie wahrscheinlich Ihre Konfiguration auf Herz und Nieren überprüfen. Dafür stehen Ihnen einige gute Werkzeuge zur Verfügung. Dazu gehören dnswalk, ein Perl-basiertes Paket, sowie nslint. Beide durchwandern Ihre DNS-Daten, suchen nach häufig auftretenden Fehlern und stellen sicher, dass die Informationen konsistent sind. Ein weiteres nützliches Programm ist host, ein universell verwendbares Abfrageprogramm für DNS-Daten. Damit können Sie DNS-Datenbankeinträge manuell inspizieren und diagnostizieren.

Diese Werkzeuge erhält man üblicherweise in Form von vorgefertigten Softwarepaketen. dnswalk und nslint sind im Quellcode erhältlich von http://www.visi.com/~barr/dnswalk/ und ftp://ftp.ee.lbl.gov/nslint.tar.Z. Den Quellcode von host finden Sie unter ftp://ftp.weird.com/pub/local/host.tar.gz.

Alternativen zu BIND

Möglicherweise machen Sie sich ja Sorgen wegen der in den vergangenen Jahren im BIND-Server aufgetretenen Schwachstellen oder bevorzugen eine einfachere DNS-Lösung. Dann sollten Sie sich einmal mit einer Alternative, nämlich djbdns, vertraut machen. Diese Software, die von D.J. Bernstein von Grund auf neu entwickelt wurde, bietet ein robusteres, einfacheres und sichereres Framework für DNS. djbdns lässt sich einfach installieren und konfigurieren und ist nicht so komplex wie BIND, wobei es im Prinzip die gleiche Funktionalität liefert. Im nächsten Abschnitt behandeln wir die Grundlagen der Installation und Konfiguration eines DNS-Servers mit djbdns. Beachten Sie bitte, dass ein djbdns-DNS-Server genau dafür gemacht ist; nämlich um ein DNS-Server zu sein. Das bedeutet, dass er normalerweise keine Anfragen für Maschinen auflöst, die außerhalb Ihres Verantwortungsbereichs liegen. Für diesen Zweck müssen Sie einen separaten Caching-Server auf einer anderen Maschine oder unter einer anderen IP-Adresse aufbauen. Wie bereits empfohlen, sollten Cache-Server und DNS-Server aus Sicherheitsgründen voneinander getrennt werden. Weitere Informationen zu diesem Thema finden Sie auf der djbdns-Website unter http://cr.yp.to/djbdns.html.

djbdns installieren

Um djbdns auszuführen, müssen Sie zuerst ein anderes DJB-Programm namens daemontools installieren, das im Prinzip eine Sammlung von Programmen darstellt, mit denen sich verschiedene Unix-Dämonen verwalten lassen. Die vollständige Dokumentation und den Quellcode für daemontools finden Sie auf seiner Webseite unter http://cr.yp.to/daemontools.html. Wenn Sie die Software erfolgreich heruntergeladen haben, dann packen Sie sie in einem Verzeichnis auf Ihrer Maschine aus und kompilieren sie. daemontools enthält ein Skript, das die Software automatisch kompiliert und installiert. Dieses Skript starten Sie folgendermaßen:

Wenn das Skript fertig ist, können Sie die Installationsverzeichnisse löschen und damit beginnen, die nächste Abhängigkeit, ucspi-tcp, zu installieren, das DJB-eigene Programm zur TCP-Client-Server-Verarbeitung. Auch dies ist einfach zu bewerkstelligen:

Die Software wird im Verzeichnis /usr/local auf Ihrer Maschine installiert. Sie müssen für den Betrieb oder die Installation dieser Software momentan nichts tun.

Sobald die Installation abgeschlossen ist, können Sie die djbdns-Software installieren. Dazu gehen Sie genauso vor wie bei ucspi-tcp. Dieser Vorgang installiert djbdns im Verzeichnis /usr/local. Bevor Sie djbdns konfigurieren, müssen Sie sicherstellen, dass der sv-scan-Prozess läuft. svscan ist Teil des daemontools-Pakets und muss laufen, damit djbdns funktioniert.

Wenn Sie überprüft haben, ob svscan läuft, können Sie die Konfiguration des DNS-Servers starten. Der erste Schritt besteht darin, dass Sie zwei Benutzerzugänge anlegen, tinydns und dnslog. djbdns benutzt beide für seine Arbeit, anstatt als root zu laufen, wie das bei BIND-Installationen oft der Fall ist.

Als Nächstes müssen Sie ein Verzeichnis für die Konfigurations- und Logdateien Ihres DNS-Servers erzeugen und es dann folgendermaßen konfigurieren:

Die IP-Adresse 172.16.0.2 im Beispiel sollte durch die externe IP-Adresse Ihres DNS-Servers ersetzt werden. Anschließend muss svscan über den neuen Dienst informiert werden. Das wird mit diesen Befehlen erreicht:

Damit ist die Installation Ihres djbdns-Servers abgeschlossen. Jetzt müssen Sie nur noch Ihre Hosts konfigurieren. Unter BIND ist das die komplizierteste und verwirrendste Stelle; mit dbjdns ist das Hinzufügen neuer DNS-Records dagegen viel einfacher.

Hosts hinzufügen

Sie müssen Ihre Host-Informationen so konfigurieren, dass Ihr DNS-Server einen Dienst anbietet. Der erste Schritt besteht darin, dass Sie sich selbst als Autorität über Ihre Domain etablieren. In unserem Beispiel, der virtuellen Brauerei, konfigurieren wir unseren DNS-Server so, dass er alle Anfragen an die Domain vbrew.com beantwortet. Anstatt uns mit langen Zonendateien herumzuärgern, erledigen wir dies mit ein paar kurzen Schritten.

Nachdem unser Server nun Anfragen für unsere Domain vbrew verarbeitet, können wir ihn benutzen, um einzelne Hosts in unserem Netzwerk zu konfigurieren. Zum Glück ist das genauso einfach wie der vorherige Schritt. Um eine Adresse mit unserem bevorzugten Host, vlager, und mit unserem Webserver zu verknüpfen, benötigen wir folgende Befehle:

Mit Hilfe des Befehls add-host geben wir den FQDN, gefolgt von der IP-Adresse, ein, um unsere DNS-Records anzulegen. Sie werden vielleicht den anderen Befehl bemerkt haben, der im Beispiel verwendet wurde: add-alias. Dieser Befehl fügt einer bereits zugewiesenen IP-Adresse einen Alias hinzu. Im Beispiel haben wir unseren Host vlager so eingestellt, dass er auch auf den Namen mail antwortet. Das ist sinnvoll, wenn ein Server mehrere Aufgaben hat. Beachten Sie besonders den letzten Befehl, der in dieser Reihe ausgeführt wird, make. Die Dinge gehen schief, wenn Sie vergessen, diesen Befehl auszuführen, da er dafür verantwortlich ist, die Konfigurationsdatei in ein Format zu kompilieren, das der Server lesen kann. Wenn Sie Probleme mit Ihrer Installation haben, dann überprüfen Sie dies zuerst.

Die Befehle add-host, add-ns und add-alias bearbeiten einfach die djbdns-Master-Konfigurationsdatei namens data, die im Verzeichnis /service/tinydns/root zu finden ist. Falls Sie das manuell erledigen wollen, öffnen Sie die Datendatei in Ihrem Browser und fügen folgende Zeilen hinzu:

Sie werden feststellen, dass die Zeilen mit den Hosteinträgen mit = und die Alias-Zeilen mit + beginnen. Die manuelle Methode funktioniert zwar, erhöht aber die Komplexität, da Sie Ihre Datendatei nun von Hand auf doppelte Einträge überprüfen müssen. Um Komplikationen zu vermeiden, werden die meisten Administratoren einfach bei den automatisierten Werkzeugen bleiben.

Installation eines externen DNS-Cache

Wenn Sie Ihren DNS-Server erfolgreich angelegt haben und alles ordentlich funktioniert, wollen Sie vermutlich einen externen DNS-Cache erzeugen, damit Hosts aus Ihrem Netzwerk die IP-Adressen von externen Maschinen auflösen können. Dazu installieren Sie einen DNS-Cache, was mit djbdns wiederum recht einfach geht. Vorausgesetzt, svscan läuft, müssen Sie zuerst zwei Systemzugänge erzeugen (oder überprüfen, ob es sie bereits gibt), einen für das Cache-Programm und einen für den Protokollierungsmechanismus. Es ist zwar nicht erforderlich, bietet sich aber an, die Zugänge mit sinnvollen Namen zu benennen, etwa dnscache bzw. dnslog.

Als Nächstes müssen Sie die IP-Adresse ermitteln, unter der Ihr DNS-Cache laufen soll. Denken Sie daran, dass sich diese IP-Adresse von derjenigen Ihres DNS-Servers unterscheiden soll. Erzeugen Sie nun als root ein Verzeichnis für den DNS-Dienst und konfigurieren Sie es mit den folgenden Befehlen:

Nun müssen Sie, ebenfalls als root, svscan davon in Kenntnis setzen, dass Sie einen neuen Dienst haben, den es ausführen soll:

Um sicherzugehen, dass der neue Dienst wirklich ausgeführt wird, warten Sie einige Augenblicke und rufen dann folgenden Befehl auf:

Jetzt müssen Sie dem Dienst mitteilen, welche IP-Adressen autorisiert sind, auf den Cache zuzugreifen. Im Fall der virtuellen Brauerei wollen wir das gesamte 172.16-Netzwerk autorisieren. Deshalb geben wir folgenden Befehl ein:

Selbstverständlich wollen Sie noch sicherstellen, dass Ihre /etc/resolv.conf Ihren neuen DNS-Cache kennt. Sie können mit nslookup, dig oder einem der in djbdns enthaltenen Werkzeuge, etwa dnsip, testen, ob der Cache funktioniert:

Fussnoten