Copyright © 1996 by O'Reilly/International Thomson Verlag

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches "Linux: Wegweiser durch das Netzwerk" dann klicken Sie hier.


Kapitel 6
Resolver und NameServer

In Kapitel 2, Aspekte der Netzwerarbeit mit TCP/IP habe ich bereits kurz beschrieben, daß in einer TCP/IP-Umgebung verschiedene Dienste zur Verfügung stehen, die Host-Namen auf IP-Adressen abbilden. Die einfachste Variante ist, eine Liste aller Host-Namen in der Datei /etc/hosts abzulegen, die dann von den Applikationen einfach nach dem gewünschten Namen durchsucht wird. Das Format dieser Datei wurde bereits in Kapitel 5, TCP/IP-Konfiguration beschrieben.

/etc/hosts ist aber nur für kleine LANs sinnvoll, die von einer einzelnen Person gewartet werden und keinerlei IP-Anschluß zur Außenwelt haben. Ansonsten würden die Größe der Datei und der Pflegeaufwand schnell den Rahmen des Erträglichen sprengen. Auf die Dauer fahren Sie da wesentlich besser mit DNS, dem Domain Name System.(1) Die Einrichtung eines Name-Servers kann recht mühselig sein, aber wenn Sie das einmal hinter sich gebracht haben, sind Änderungen in der Netztopologie fast problemlos.

Im Internet ist DNS ein Muß, ohne es kommen Sie nicht weit. Aber auch in isolierten LANs ist es manchmal sehr nützlich, bringt aber hier auch keine nennenswerten Vorteile gegenüber NIS. Für ein kleines Ethernet mit vielleicht einem Dutzend Maschinen wird man oft auf beides verzichten und sich mit einer einfachen hosts-Datei begnügen.

Wenn Sie nicht gerade ein Netz administrieren, sondern einfach nur Ihre Linux-Box an ein existentes LAN anschließen wollen, müssen Sie Ihr System an die dortigen Gegebenheiten anpassen. Dazu steht Ihnen die Resolver-Bibliothek zur Verfügung, die transparent auf die verschiedenen Dienste zugreift. Der erste Teil diese Kapitels wird sich daher mit der Konfiguration dieser Bibliothek befassen.

Im zweiten Teil wenden wir uns der Einrichtung eines Name-Servers zu. Auf Linux, wie auf den meisten anderen UNIXoiden Systemen auch, wird die Arbeit des Name-Servers von named verrichtet, name-dee ausgesprochen. named ist Teil der BIND-Software, einer Sammlung von DNS-Werkzeugen und Bibliotheks-Funktionen. BIND steht für Berkeley Internet Name Domain Server und kommt aus der BSD-Welt.

In diesem Kapitel kann ich Ihnen nur wenig mehr als einen groben Überblick über den Betrieb eines Name-Servers geben. Wenn Sie BIND in einem komplexeren Umfeld als nur einem kleinen LAN und vielleicht einem kleinen Internet-Link betreiben wollen, sollten Sie sich ein gutes Buch über BIND besorgen, zum Beispiel Cricket Lius »DNS and BIND«. Daneben finden Sie in den Sourcen zu BIND ebenfalls sehr aktuelle Informationen. Außer den Manual-Seiten und den Release-Informationen enthalten sie den »BIND Operator's Guide«, kurz BOG. Lassen Sie sich von dem Namen nicht abschrecken, es ist wirklich eine sehr nützliche Referenz. Schließlich gibt es noch die Newsgruppe comp.protocols.tcp-ip.domains, die ausschließlich für Fragen und Diskussionen um DNS da ist.

Die Resolver-Bibliothek

Das Gegenstück zum Name-Server ist die Resolver-Bibliothek, eine Gruppe von Funktionen, die bei Linux zur Standard-C-Bibliothek gehören. Ihre wichtigsten Routinen sind gethostbyname und gethostbyaddr, die alle zu einem Namen gehörigen IP-Adressen zurückliefern, bzw. den kanonischen Host-Namen zu einer gegebenen Adresse. Über die Datei host.conf können Sie einstellen, ob sie die gewünschten Informationen in /etc/hosts nachschlagen, das DNS befragen oder die hosts-Datenbank des NIS-Servers.(2)

Die Teile der Bibliothek, die sich mit DNS beschäftigen, stammen ursprünglich aus den BIND-Quellen, die auch den Name-Server enthalten. Die letzte aktuelle Version von BIND war lange Zeit 4.8, seit kurzem ist aber auch das neue BIND-4.9 öffentlich zugänglich.

Seit Version 4.6.8 enthält die Linux-C-Bibliothek den Resolver-Kode von BIND-4.9. Es ist wichtig zu wissen, daß BIND-4.9 einen wesentlichen Punkt des Resolvers geändert hat, die sogenannte search list, die weiter unten beschrieben wird. In allen anderen Punkten sollte sich das Verhalten der beiden Versionen nicht unterscheiden.

Die Datei host.conf

Die wichtigste Datei, die die Funktion Ihres Resolvers kontrolliert, ist host.conf. Sie liegt im Verzeichnis /etc und legt unter anderem fest, welche Dienste der Resolver in welcher Reihenfolge befragen soll.

Optionen in host.conf müssen in getrennten Zeilen erscheinen, wobei die Argumente durch Leerzeichen oder TABs voneinander getrennt sein müssen. Ein Doppelkreuz leitet einen Kommentar ein, der sich bis zum Zeilenende erstreckt. Die folgenden Optionen sind verfügbar:

order
Dieser Befehl bestimmt die Reihenfolge, in der der Resolver die verschiedenen Dienste ausprobiert. Die Liste darf die Schlüsselworte bind für DNS, hosts für /etc/hosts und nis für NIS-Abfragen enthalten.
multi
legt fest, ob Hosts in der Datei /etc/hosts mehrere Adressen haben dürfen; diese Eigenschaft wird im Englischen oft als multi-homed bezeichnet. Gültige Argumente sind on und off. Dieses Kommando hat keinerlei Auswirkungen auf DNS- und NIS-Anfragen.
nospoof
Wie im vorherigen Kapitel beschrieben, kann DNS über die Domain in-addr.arpa IP-Adressen auf den zugehörigen kanonischen Host-Namen abbilden. Nun könnte ein böswilliger DNS-Administrator versucht sein, die tatsächlichen Namen seiner Hosts zu verschleiern, zum Beispiel, um Sicherheitsvorkehrungen zu umgehen. Um sich vor so einem versuchten Schwindel (= spoof) zu schützen, kann der Resolver zusätzlich überprüfen, ob die Adresse tatsächlich zu den gültigen Adressen des so erhaltenen Namens gehört. Tut sie das nicht, verwirft der Resolver den Namen und gibt einen Fehler an die Applikation zurück. Dieses Verhalten wird mit nospoof on eingestellt.
alert
Wenn Sie diese Option mit alert on anstellen, meldet der Resolver jeden Spoof-Versuch an den syslog-Dämon.
trim
gibt einen Domain-Namen an, den der Resolver wenn möglich vom Host-Namen abschneiden soll, bevor er die einzelnen Dienste befragt. Das kann für die hosts-Datei nützlich sein, wenn Sie dort nur die lokalen Host-Namen ohne Domain eintragen wollen. Übergibt eine Applikation dem Resolver nun einen Host-Namen, der auf den lokalen Domain-Namen endet, wird er »getrimmt«, so daß der Resolver ihn in /etc/hosts finden kann. In einer DNS-Umgebung macht das Trimmen von Domain-Namen allerdings keinen Sinn.

Sie können den trim-Befehl mehrmals angeben, wodurch Sie auch Host-Namen aus mehreren Domains in /etc/hosts mischen können. Spätestens jetzt wird es allerdings unübersichtlich.

Beispiel 6--1 zeigt eine Beispieldatei host.conf für vlager.

Beispiel 6-1. <figure id=X-807-2-host.conf.file>Beispieldatei für host.conf.

# /etc/host.conf
# Wir benutzen named, aber kein NIS. 
order   bind hosts
# Mehrere Adressen sind erlaubt. 
multi   on 
# Wehret den Schwindlern und Betruegern  n
ospoof  on 
# Lokale Trimmdomain (hier nicht wirklich noetig)  
trim    vbrew.com.

Konfiguration der Name-Server-Aufrufe -- resolv.conf

Wenn Ihr Resolver DNS benutzen soll, müssen Sie ihm auch mitteilen, welche Server er benutzen soll. Dafür gibt es eine separate Datei names resolv.conf.

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

Zwei weitere Befehle, domain und search, gaben Domain-Namen an, die der Resolver an einen Namen anhängt, wenn die zugehörige Adresse beim ersten Versuch nicht gefunden wurde. Wenn Sie beispielsweise telnet benutzen, wollen Sie im allgemeinen nicht immer den voll qualifizierten Domain-Namen eintippen, sondern lieber so etwas wie gauss angeben und den Resolver den Domain-Namen mathematics.groucho.edu drankleben lassen.

Genau dafür ist der Befehl domain da. Mit ihm können Sie eine Default-Domain angeben, die immer dann angehängt werden soll, wenn ein Name nicht aufgelöst werden konnte. Im obigen Beispiel würde der Resolver DNS zuerst nach gauss. befragen, was natürlich schiefgeht, da es keine Toplevel-Domain dieses Namens gibt. Mit mathematics.groucho.edu als Default-Domain würde er die Anfrage dann mit dem Namen gauss.mathematics.groucho.edu wiederholen, was diesmal von Erfolg gekrönt wäre.

Prima, werden Sie jetzt vielleicht denken, aber sobald ich die Domain verlasse, bin ich wieder bei den langen Namen und tippe mir die Finger wund. Warum kann ich nicht Namen wie quark.physics benutzen, wo wir doch schon an der Groucho-Marx-Universität sind?

Hier kommt die Suchliste ins Spiel. Eine Suchliste kann mit dem Befehl search angegeben werden und ist eine Verallgemeinerung der Default-Domain. 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 DNS-Eintrag gefunden wird. Die einzelnen Namen der Liste müssen durch Leerzeichen oder TABs 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 Default-Domain aus dem lokalen Host-Namen zu raten. Hat der Host-Name keinen Domain-Teil, wird als Default-Domain die Root-Domain angenommen.

Wenn Sie in resolv.conf eine Suchliste definieren, sollten Sie sich genau überlegen, welche Domains Sie dort eintragen. Die Resolver-Bibliotheken vor BIND-4.9 pflegten aus dem Domain-Namen eine Liste zusammenzubauen, wenn vom Administrator keine angegeben wurde. Diese Default-Liste enthielt die Default-Domain plus alle Ober-Domains. Das konnte zu Problemen führen, da DNS-Anfragen manchmal bei Name-Servern landeten, für die sie nie bestimmt waren.

Nehmen Sie an, Sie sitzen in der Virtuellen Brauerei und wollen sich auf foot.groucho.edu einloggen. Durch einen unglücklichen Ausrutscher Ihrer Finger schreiben Sie aber foo statt foot. Der Name-Server der GMU kennt aber keine Maschine namens foo, was er Ihrem Resolver auch mitteilt. Mit der alten Suchliste würde der Resolver nun fortfahren und in den Domains vbrew.com und com fahnden. Vor allem der letzte Fall ist problematisch, da es durchaus eine Domain namens groucho.edu.com geben kann. Wenn diese Domain dann auch noch einen Host namens foo enthält, landet Ihr login-Programm bei einer ganz anderen Maschine, als von Ihnen beabsichtigt.(3)

Für einige Applikationen 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 Fachbereich Mathematik der Groucho-Marx-Universität würde die Liste beispielsweise nur maths.groucho.edu und groucho.edu enthalten.

Wenn Ihnen all das zu verwirrend vorkommt, werfen Sie einen Blick auf die resolv.conf-Datei der Virtuellen Brauerei:

# /etc/resolv.conf
# Unsere eigene Domain:
domain         vbrew.com
#
# Der zentrale Name-Server
nameserver      172.16.1.1

Wenn Sie in dieser Konfiguration die Adresse von vale suchen, wird der Resolver erst vale nachzuschlagen versuchen, und wenn das fehlschlägt, vale.vbrew.com.

Robustheit des Resolvers

Wenn Sie ein LAN innerhalb eines größeren Netzes betreiben, sollten Sie auf jeden Fall einen zentralen Name-Server benutzen (falls verfügbar). Der Vorteil dieser Methode ist, daß die zentralen Server im Laufe der Zeit einen reichhaltigen Cache entwickeln, da alle DNS-Queries über sie abgewickelt werden. Dieses Schema hat allerdings einen gravierenden Nachteil: als vor einiger Zeit ein Brand das Backbone-Kabel unserer Uni beschädigte, kam alle Arbeit auf dem LAN des Fachbereichs zum Erliegen, da der Resolver keinen der Uni-weiten Name-Server mehr erreichen konnte. Die X-Terminals waren tot, der Drucker war nicht mehr ansprechbar, etc.

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

Eine Möglichkeit ist, einen eigenen Name-Server aufzusetzen, der die lokale Domain bedient und alle Anfragen für andere Host-Namen an den zentralen Server weiterleitet. Natürlich funktioniert das nur, wenn Sie eine eigene Domain administrieren.

Ebensogut können Sie aber auch Ihre lokalen Maschinen zusätzlich in /etc/hosts eintragen und in der Datei /etc/host.conf »order bind hosts« anfügen, damit der Resolver im Notfall auf diese statischen Tabellen zurückfallen kann.

Der Einsatz von named

Das Programm, das auf den meisten UNIX-Maschinen das DNS bedient, heißt named (ausgesprochen name-dee). Dieser Server wurde ursprünglich für BSD entwickelt und ist für Anfragen von Benutzerprozessen und eventuell anderen Name-Servern zuständig. Die derzeit auf Linux-Rechnern noch am häufigsten eingesetzte Version scheint BIND-4.8.3 zu sein. Die neue Version, BIND-4.9.3, ist derzeit noch im Beta-Test; es exisitieren jedoch bereits verschiedene Linux-Portierungen.(4)

Sie hat eine ganze Reihe neuer Features, wie beispielsweise die Möglichkeit, Zonentransfers auf bestimmte Maschinen oder Netze zu beschränken. Details hierzu finden Sie in der Dokumentation, die dem Quellkode beiliegt.

Dieser Abschnitt setzt voraus, daß Sie schon etwas über die Funktionsweise von DNS, dem Domain Name System, wissen. Wenn die folgende Diskussion für Sie wie böhmische Dörfer klingt, können Sie in Kapitel 2 einige zusätzliche Informationen über die Grundlagen von DNS nachlesen.

named wird für gewöhnlich beim Booten des Rechners gestartet und läuft, bis Sie die Maschine wieder herunterfahren. Er liest zunächst die Datei /etc/named.boot, die seine Konfiguration beschreibt, und eine Reihe weiterer Dateien, die die Zuordnung von Domain-Namen zu Adressen und ähnliches festlegen. Letztere werden auch Zonendateien (zone files) genannt. Ihr Format und ihre Bedeutung werden im folgenden Abschnitt erklärt.

Um named zu starten, geben Sie am Prompt einfach folgendes ein:

# /usr/sbin/named

named legt nach dem Start seine Prozeß-ID in der Datei /var/run/named.pid ab und liest anschließend die oben beschriebenen Dateien, und falls nötig, lädt er Zonendateien von anderen Servern. Anschließend wartet er auf Port 53 auf einkommende Anfragen.(5)

Die Datei named.boot

Die Datei named.boot ist im allgemeinen sehr klein und enthält wenig mehr als Verweise auf die Master-Dateien, in denen sich Zonendaten befinden. Kommentare in der Bootdatei beginnen mit einem Semikolon und reichen bis zum Zeilenende. Bevor wir aber das Format von named.boot im Detail angehen, sollten Sie einen Blick auf die Beispieldatei für vlager im folgenden werfen, die in Beispiel 6--2 dargestellt ist.(6) Beispiel 6-2.

;
   ; /etc/named.boot fuer vlager.vbrew.com
   ;
   directory     /var/named
   ;
   ;             domain                   file
   ;-------------------------------------------------------
   cache         .                        named.ca
   primary       vbrew.com                named.hosts
   primary       localhost                named.local
   primary       0.0.127.in-addr.arpa     named.local-rev
   primary       72.191.in-addr.arpa      named.rev

Die im Beispiel gezeigten Befehle cache und primary laden DNS-Daten in named. Diese Informationen werden jeweils der Master-Datei entnommen, die im zweiten Argument angegeben wird. Sie enthalten Listen von DNS-Resource-Records, die wir uns später genauer ansehen werden.

Im diesem Beispiel wurde named als primärer Name-Server für vier Domains konfiguriert, wie die primary-Anweisungen am Ende der Datei zeigen. Die erste Zeile weist named beispielsweise an, als primärer Server für die vbrew.com zu dienen und die Zonendaten aus der Datei named.hostszu lesen. Die directory-Zeile teilt ihm mit, daß sich alle Zonendateien im Verzeichnis /var/named befinden.

Der cache-Eintrag hat eine besondere Aufgabe und sollte auf nahezu allen Maschinen vorhanden sein, die einen Name-Server einsetzen. Er weist named einerseits an, einen Cache aufzubauen, und andererseits, die Adressen der Name-Server für die Root-Domain aus der Datei named.ca zu laden. Diese Adressen heißen im Jargon root name server hints; wir werden im folgenden noch einmal auf sie zurückkommen.

Hier ist eine Liste der wichtigsten Optionen, die Sie in named.boot benutzen können:

directory
Dieser Befehl gibt das Verzeichnis an, in dem sich die Zonendateien befinden. Die Namen der Dateien können relativ zu diesem Verzeichnis angegeben werden. Sie können auch mehrere Verzeichnisse angeben, indem Sie den directory-Befehl mehrfach benutzen.

Dem Linux File System Standard zufolge sollten Zonendaten immer in /var /named abgelegt werden.

primary
Dieser Befehl benötigt einen Domain-Namen und einen Dateinamen als Argumente und erklärt den Server als autoritativ für diese Domain. Als primärer Server lädt named die Zoneninformation aus der angegebenen Master-Datei.

Im allgemeinen wird named.boot mindestens zwei primary-Einträge enhalten, nämlich um dem Namen localhost die Adresse 127.0.0.1 zuzordnen und umgekehrt.

secondary
Dieser Befehl benötigt einen Domain-Namen, eine Adreßliste und einen Dateinamen als Argumente. Er erklärt den Server zum sekundären Server für die angegebene Domain.

Ein sekundärer Server ist ebenfalls autoritativ für die fragliche Domain, liest aber seine Informationen nicht aus Dateien. Statt dessen versucht er, sie vom primären oder einem anderen sekundären Server zu laden. Die Adreßliste muß deshalb die IP-Adresse mindestens eines autoritativen Servers enthalten.(7) Der lokale Server probiert diese Name-Server einen nach dem anderen, bis er die Zonendaten erfolgreich übertragen konnte. Die Daten werden anschließend in der Backup-Datei abgelegt, die im letzten Argument angegeben wurde. Wenn keiner der angegebenen Server erreichbar ist, lädt named die Zoneninformation statt dessen aus der Backup-Datei, sofern vorhanden.

named versucht dann, die Zonendaten in regelmäßigen Abständen aufzufrischen. Dies wird später im Zusammenhang mit dem Resource-Typ SOA erklärt.

cache
Dieses Kommando benötigt eine Domain und einen Dateinamen als Argumente. Die Datei enthält die Adressen der Root-Server. named ignoriert beim Lesen dieser Datei alle Records außer A und NS. Das Domain-Argument sollte der Name der Root-Domain sein, also ein einfacher Punkt (.).

Diese Daten sind für named äußerst wichtig: Wenn die cache-Anweisung nicht in der Boot-Datei auftaucht, wird named überhaupt keinen lokalen Cache bereits gefundener Adressen anlegen. Das kann unter Umständen zu einer schweren Performance-Bremse werden und die Netzbelastung unnötig erhöhen. Außerdem ist named so nicht in der Lage, irgendwelche Root-Server zu erreichen und kann somit nur solche Adressen auflösen, für die er autoritativ ist. Eine Ausnahme von dieser Regel sind sogenannte forwarding servers, die im nächsten Punkt behandelt werden.

forwarders
Dieser Anweisung folgt eine Liste von Adressen von Name-Servern, die named befragen darf, wenn er selbst nicht in der Lage war, eine Adresse aufzulösen. Diese Server werden der Reihe nach ausprobiert, bis einer von ihnen die Anfrage beantwortet.
slave
Dieser Befehle macht Ihren Name-Server zu einem Slave-Server. Das bedeutet, daß er niemals selbst rekursive Anfragen durchführt, sondern immer an die Server weiterleitet, die in der forwarders-Anweisung angegeben sind.
xfrnets
Dieser Befehl wurde in BIND-4.9.3 eingeführt und gibt an, welche Hosts die Zonendaten Ihres Servers vermittels eines Zonentransfers abrufen dürfen. Es soll verhindern, daß Leute ohne weiteres an eine vollständige Liste aller Hosts Ihrer Domain kommen.(8)

xfrnets erwartet eine Liste von IP-Netzadressen, die als dotted quads geschrieben werden müssen. Optional können Sie eine Netzmaske angeben, die von der Adresse durch ein & getrennt wird (z. B. 172.17.5.0&255.255.255.0).

Neben diesen Optionen gibt es noch eine Reihe weiterer, die hier aber nicht beschrieben werden. Dazu gehören sortlist und domain plus einige, die in Version 4.9.3 neu eingeführt wurden. Daneben gibt es die Anweisungen $INCLUDE und $ORIGIN, die in den eigentlichen Zonendateien benutzt werden können. Da sie nur selten gebraucht werden, werde ich sie hier auch nicht beschreiben.

Die Zonendateien

Zu jeder Master-Datei wie named.hosts, die named bearbeitet, gehört ein Domain-Name, der im folgenden als Ursprung (engl. origin) bezeichnet wird. Das ist der Domain-Name, der beim jeweiligen primary- bzw. cache-Kommando angegeben wurde. Eine Name, der in einer Konfigurationsdatei angegeben wird, heißt absolut, wenn er auf einen Punkt endet, andernfalls ist er relativ zum Ursprung. Der Domain-Name »@« bezieht sich auf den Ursprung selbst.

Die Daten, die die Zonendateien enthalten, sind in sogenannte Resource-Records oder kurz RRs aufgeteilt. Sie stellen die kleinste durch das DNS erhältliche Informationseinheit dar. Jeder Resource-Record hat einen Typ. Die A-Records beispielsweise bilden einen Namen auf eine Adresse ab, und ein CNAME-Record definiert einen Alias für einen anderen Domain-Namen. Beispiel 6--4 zeigt die Master-Datei named.hosts für die Virtuelle Brauerei.

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

[domain] [ttl] [class] type rdata

Die einzelnen Felder werden durch Leerzeichen oder Tabs voneinander getrennt. Manche Einträge können über mehrere Zeilen fortgesetzt werden, wenn vor dem ersten Zeilenende eine öffnende Klammer steht und auf das letzte Feld eine schließende Klammer.(9)

Alles zwischen einem Semikolon und dem Zeilenende wird ignoriert.

domain
Dies ist der Domain-Name, für den der Eintrag gilt. Wenn kein Name angegeben ist, bezieht sich der RR auf die Domain des vorigen RR.
ttl
Um andere Name-Server dazu zu veranlassen, nach einiger Zeit gecachte Informationen wegzuwerfen, ist für jeden RR eine bestimmte Lebensdauer (time to live, kurz ttl) festgelegt. 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 8 Ziffern.

Wenn kein ttl-Wert angegeben ist, wird der im SOA-Record angegebene Minimalwert (siehe unten) verwendet.

class
Dies ist eine Adreßklasse, wie IN für IP-Adressen oder HS für Objekte in der Hesiod-Klasse. Für TCP/IP-basierte Rechner müssen die Einträge den Typ IN haben.
type
Dies beschreibt den Typ des RR. Die häufigsten Typen sind A, SOA, PTR und NS. Im folgenden werden die verschiedenen Typen im einzelnen beschrieben.
rdata
Der Rest des Eintrages enthält die Daten, die zu dem RR gehören. Das Format dieses Feldes hängt vom Typ des RR ab.

Das folgende ist eine unvollständige Liste von RRs, die in Zonendateien benutzt werden können. Es gibt noch ein paar mehr, die ich hier aber nicht erklären will. Sie sind experimentell und werden so gut wie nicht benutzt.

SOA
Dieser Record leitet die Daten einer Zone ein (SOA bedeutet Start Of Authority). Jede Datei, die durch den Befehl primary eigebunden wird, muß mit einem solchen RR beginnen. Das Datenfeld enthält die folgenden Felder:
Ursprung
Dies ist der kanonische Host-Name des primären Name-Servers der Domain. Er wird üblicherweise als absoluter Name angegeben.
Kontakt
Dies ist die E-Mail-Adresse der Person, die für diese Zone verantworlich ist, wobei das Zeichen &guilsinglright;@&guilsinglleft; durch einen Punkt ersetzt wurde. Wenn beispielsweise janet die verantworliche Person in der Virtuellen Brauerei ist, enthält dieses Feld janet.vbrew.com.
Seriennummer
Dies ist die Versionsnummer der Zonendatei, geschrieben als einzelne Dezimalzahl. Jedesmal, wenn Daten in der Zone verändert werden, sollte diese Zahl inkrementiert werden.

Die Seriennummer wird von den sekundären Name-Servern verwendet, um festzustellen, ob sich die Zonendaten verändert haben. Um auf dem laufenden zu bleiben, fordert der sekundäre Server den SOA-Record des primären Servers in bestimmten Zeitabständen an und vergleicht die Versionsnummer mit der des gecachten SOA-Records. Wenn sich die Zahl verändert hat, lädt er die gesamten Zonendaten vom primären Server neu.

Refresh
Dies gibt die Zeit in Sekunden an, die ein sekundärer Server warten soll, bevor er den SOA-Record des primären Servers wieder überprüft. Dies ist wieder eine Dezimalzahl mit bis zu 8 Stellen.

Normalerweise ändern sich die Namen in einer Domain nicht allzu häufig, weshalb diese Zahl ungefähr einem Tag im Falle größerer Domains entsprechen sollte, bei kleineren möglicherweise auch mehr.

Retry
Dieser Wert legt die Zeitabstände fest, in denen ein sekundärer Server versuchen soll, den primären zu erreichen, wenn eine Anfrage oder eine Zonenauffrischung fehlschlagen. Der Wert sollte nicht zu klein gewählt werden, da sonst eine vorübergehende Störung des Servers oder ein Netzproblem dazu führen können, daß der sekundäre Server unnötig Netzressourcen verbrät. Eine oder eine halbe Stunde dürften eine gute Wahl sein.
Expire
Dieser Wert gibt die Zeit in Sekunden an, nach denen ein sekundärer Server schließlich alle Zonendaten wegwerfen sollte, falls es ihm nicht gelingt, den primären Server zu erreichen. Sie sollten diesen Wert normalerweise auf mindestens eine Woche setzen (d. h. 604800 Sekunden), aber auch ein Monat kann durchaus sinnvoll sein.
Minimum
Dies ist der ttl-Wert, der als Voreinstellung für RRs gewählt wird, die nicht ausdrücklich einen solchen Wert angeben. Der ttl-Wert gibt die maximale Zeit an, für die andere Name-Server einen RR in Ihrem Cache behalten dürfen. Dieser Wert betrifft nur gewöhnliche DNS-Abfragen und hat nichts mit der Zeit zu tun, nach der ein sekundärer Server versuchen sollte, die Zoneninformation zu aktualisieren.

Wenn sich die Topologie Ihres Netzes nicht allzu häufig ändert, dürfte eine Woche oder mehr ein guter Wert sein. Wenn sich einzelne RRs häufiger ändern, können Sie diesen jeweils kleinere TTLs individuell zuordnen. Wenn sich der Aufbau Ihres Netzes allerdings häufiger ändert, können Sie diesen Wert auch auf einen Tag (86400 Sekunden) setzen.

A
Dieser Record-Typ ordnet einem Host-Namen eine Adresse zu. Das Datenfeld enthält die Adresse in dotted-quad-Schreibweise.

Für jede Adresse sollte es immer nur einen A-Record geben. Der in diesem RR benutzte Host-Name ist der offizielle oder kanonische Host-Name. Alle anderen Namen sind Aliase und müssen mittels eines CNAME-Records auf den kanonischen Host-Namen abgebildet werden.

Allerdings ist es durchaus möglich, daß ein Host-Name mehrere A-Records besitzt.

NS
NS-Records dienen dazu, primäre oder sekundäre Name-Server einer Zone anzugeben. Ein NS-Record zeigt auf einen Name-Server der angegebenen Zone; das Datenfeld enthält den Host-Namen des Servers.

Sie werden NS-Records in zwei Situationen begegnen. Sie werden einmal benutzt, wenn Autorität an eine untergeordnete Zone delegiert wird, andererseits tauchen sie in der untergeordneten Zone selbst auf. Die Liste der Server, die jeweils in der delegierenden und delegierten Zone aufgelistet werden, sollten übereinstimmen.

Um den Host-Namen, auf den der NS-Record verweist, auflösen zu können, wird unter Umständen ein zusätzlicher A-Record benötigt, der sogenannte Glue-Record (glue = Leim), der die IP-Adresse des Servers angibt. Glue-Records werden in der Zonendatei der Eltern-Domain benötigt, wenn der bezeichnete Server in der delegierten Domain selbst liegt.

CNAME
Dieser Record-Typ ordnet einem Alias für einen Host dessen kanonischen Host-Namen zu. Der kanonische Host-Name ist derjenige, für den die Zonendatei einen A-Record enthält. Aliase verweisen über einen CNAME auf diesen Host-Namen und sollten keine weiteren RRs besitzen.
PTR
Dieser Record bildet einen Host-Namen auf einen anderen ab, ähnlich dem CNAME-Record. Er wird verwendet, um Namen in der Domain in-addr.arpa (die IP-Adressen repräsentieren) auf den zugehörigen kanonischen Host-Namen abzubilden. Das Datenfeld dieses RR enthält den kanonischen Host-Namen.
MX
Dieser RR legt einen sogenannten Mail Exchanger für die angegebene Domain fest. Mail Exchanger werden ausführlich in Abschnitt Mail-Routing im Internet in Kapitel 13, Elektronische Post beschrieben. Die Syntax eines MX-Records sieht so aus:

[domain] [ttl] [class] MX preference host

Das weist host als Mail Exchanger für domain aus. Jedem Exchanger ist eine ganzzahlige Präferenz zugeordnet. Ein Mail-Transportprogramm, das ein Nachricht an domain ausliefern möchte, probiert alle als Exchanger eingetragenen Hosts der Reihe nach durch, bis es sie erfolgreich übertragen kann. Dabei beginnt es bei dem MX mit der niedrigsten Präferenz und arbeitet die Liste in aufsteigender Reihenfolge ab.

HINFO
Dieser Record enthält Informationen über die Hard- und Software des Systems. Seine Syntax ist:
[domain] [ttl] [class] HINFO hardware software

Das hardware-Feld beschreibt die Hardware, auf der das System läuft, in einem bestimmten Format. Der RFC »Assigned Numbers« (gegenwärtig ist RFC 1340 die aktuelle Version) enthält eine Liste gültiger Namen, die Sie in diesem Feld eintragen können. Wenn das Feld Leerzeichen enthält, müssen sie in doppelte Anführungszeichen gesetzt werden. Das Feld software bezeichnet das Betriebssystem des Hosts. Auch hier sollten gültige Namen aus RFC 1340 gewählt werden.

Die Master-Dateien

In den Beispielen 6--3 bis 6--6 sehen Sie Beispieldateien für den Name-Server der Virtuellen Brauerei, der auf vlager läuft. Da wir hier nur ein relativ simples Netz (ein einfaches LAN) betrachten, ist das Beispiel auch nicht allzu kompliziert. Wenn Ihre Anforderungen komplexer sind, und es Ihnen partout nicht gelingt, named zum Laufen zu bringen, empfehle ich Ihnen DNS and BIND von Cricket Liu und Paul Albitz.

Die Datei named.ca in Beispiel 6--3 zeigt, wie die Rootserver Hints aussehen könnte. Eine typische Hint-Datei enthält normalerweise ein rundes Dutzend Name-Server. Um eine aktuelle Liste der Root-Server zu bekommen, können Sie das Programm nslookup verwenden, das im nächsten Abschnitt beschrieben wird.(10)

Beispiel 6-3. Die Datei named.ca

  ;
  ; /var/named/named.ca          Root Server Hints fuer die Virtuelle
  ;                              Brauerei. Wir sind nicht im Internet,
  ;                              also brauchen wir keine Root-Server. Um
  ;                              diese Records zu aktivieren, entfernen Sie
  ;                              die Semikolons.
  ;
  ; .                99999999   IN    NS  NS.NIC.DDN.MIL
  ; NS.NIC.DDN.MIL   99999999   IN    A   26.3.0.103
  ; .                99999999   IN    NS  NS.NASA.GOV
  ; NS.NASA.GOV      99999999   IN    A   128.102.16.10

Beispiel 6-4. Die Datei named.hosts

  ;
  ; /var/named/named.hosts       Lokale Hosts in der Brauerei.
  ;                              Ursprung is vbrew.com
  ;  @                IN  SOA   vlager.vbrew.com. janet.vbrew.com. (
                             16         ; serial
                             86400      ; refresh: once per day
                             3600       ; retry:   one hour
                             3600000    ; expire:  42 days
                             604800     ; minimum: 1 week
                             )
                   IN  NS    vlager.vbrew.com.
  ;
  ; Mail an user@vbrew.com wird auf vlager verteilt.
                   IN  MX    10 vlager
  ; Das Ethernet der Brauerei
  vlager           IN  A     172.16.1.1
  vlager-if1       IN  CNAME vlager
  ; vlager ist auch der News-Server
  news             IN  CNAME vlager
  vstout           IN  A     172.16.1.2
  vale             IN  A     172.16.1.3
  ; Das Ethernet der Kellerei
  vlager-if2       IN  A     172.16.2.1
  vbardolino       IN  A     172.16.2.2
  vchianti         IN  A     172.16.2.3
  vbeaujolais      IN  A     172.16.2.4

Beispiel 6-5. Die Datei named.rev

  ;
  ; /var/named/named.rev         Reverse Mapping unserer IP-Addressen
  ;                              Ursprung ist 72.191.in-addr.arpa.
  ;
  @             IN  SOA   vlager.vbrew.com. janet.vbrew.com. (
                            16         ; serial
                            86400      ; refresh: once per day
                            3600       ; retry:   one hour
                            3600000    ; expire:  42 days
                            604800     ; minimum: 1 week
                            )
                IN  NS    vlager.vbrew.com.
  ; Brauerei
  1.1           IN  PTR   vlager.vbrew.com.
  2.1           IN  PTR   vstout.vbrew.com.
  3.1           IN  PTR   vale.vbrew.com.
  ; Kellerei
  1.2           IN  PTR   vlager-if1.vbrew.com.
  2.2           IN  PTR   vbardolino.vbrew.com.
  3.2           IN  PTR   vchianti.vbrew.com.
  4.2           IN  PTR   vbeaujolais.vbrew.com.

Die Beispiele 6--6 und 6--7 enthalten eigentlich nichts weiter als den Eintrag für den Namen localhost, der für die Adresse 127.0.0.1 steht. Neben den eigentlich wichtigen Records (dem A-Record für localhost und dem PTR-Record für 1.0.0.127.in-addr.arpa) enthalten beide Dateien jeweils noch je einen SOA- und NS-Record. Das sieht nach ziemlichem Overkill aus und ist es wohl auch.(11) Es ist auch nicht unbedingt zwingend, localhost in Ihrem DNS zu definieren, Sie können auch genauso gut einen Eintrag in der Datei /etc/hosts machen. Natürlich müssen Sie den Resolver in host.confauch so konfigurieren, daß er außer dem DNS auch die hosts-Datei konsultiert.

Beispiel 6-6. Die Datei named.local

  ;
  ; /var/named/named.local       Der localhost-Eintrag
  ;                              Ursprung ist localhost.
  ;
  @                 IN  SOA   vlager.vbrew.com. janet.vbrew.com. (
                             16         ; serial
                             86400      ; refresh: once per day
                             3600       ; retry:   one hour
                             3600000    ; expire:  42 days
                             604800     ; minimum: 1 week
                             )
                    IN  NS   vlager.vbrew.com.
  ; Und hier der eigentliche Eintrag:
  localhost.        IN  A    127.0.0.1
Beispiel 6-7. Die Datei named.local-rev
  
  ;
  ; /var/named/named.local-rev   Reverse Mapping des Netzes 127.0.0
  ;                              Ursprung ist 0.0.127.in-addr.arpa.
  ;
  @             IN  SOA   vlager.vbrew.com. janet.vbrew.com. (
                          1          ; serial
                          360000     ; refresh: 100 hrs
                          3600       ; retry:   one hour
                          3600000    ; expire:  42 days
                          360000     ; minimum: 100 hrs
                          )
                IN  NS    vlager.vbrew.com.
  1             IN  PTR   localhost.

Test Ihrer DNS-Konfiguration

Es gibt mehrere sehr schöne Tools, um die Konfiguration Ihres Name-Servers zu testen. Zwei davon sind in der BIND-Distribution enthalten: dif und nslookup. Ich werde in diesem Abschnitt nur letzteres beschreiben, da es eine recht bequeme interaktive Benutzerschnittstelle besitzt. Sie können es aber auch von der Shell aus benutzen, indem Sie es einfach so aufrufen:

$ nslookup Host-Name

nslookup befragt dann den in resolv.conf angegebenen Name-Server nach Host-Name. (Wenn Sie in dieser Datei mehr als einen Server angegeben haben, wählt nslookup einen davon per Zufall aus).

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

Wenn Sie es ohne Argumente aufrufen, gibt nslookup den Namen des verwendeten Name-Servers aus und geht in den interaktiven Modus. Hinter dem Prompt > können Sie nun beliebige Domain-Namen angeben. Per Voreinstellung fragt nslookup nach A-Records, d. h. denjenigen, die die zum Domain-Namen gehörige IP-Adresse enthalten.

Sie können den Record-Typ, nach dem DNS-sucht, verändern, indem Sie

> set type=typ
eingeben. Dabei muß typ einer der oben beschriebenen Record-Typen sein oder der String ANY.

Eine Unterhaltung mit nslookup könnte beispielsweise so aussehen:

$ nslookup
Default Name Server:  rs10.hrz.th-darmstadt.de
Address:  130.83.56.60
> sunsite.unc.edu
Name Server:  rs10.hrz.th-darmstadt.de
Address:  130.83.56.60
Non-authoritative answer:
Name:    sunsite.unc.edu
Address:  152.2.22.81
Wenn Sie einen Namen angeben, zu dem es keine A-Records gibt, aber andere Record-Typen gefunden wurden, gibt nslookup die Fehlermeldung No type A records found. Mit dem Kommando set type können Sie es 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:
  > unc.edu
  *** No address (A) records available for unc.edu
  Name Server:  rs10.hrz.th-darmstadt.de
  Address:  130.83.56.60
  > set type=SOA
  > unc.edu
  Name Server:  rs10.hrz.th-darmstadt.de
  Address:  130.83.56.60
  Non-authoritative answer:
  unc.edu
          origin = ns.unc.edu
          mail addr = shava.ns.unc.edu
          serial = 930408
          refresh = 28800 (8 hours)
          retry   = 3600 (1 hour)
          expire  = 1209600 (14 days)
          minimum ttl = 86400 (1 day)
  Authoritative answers can be found from:
  UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
  SAMBA.ACS.UNC.EDU       internet address = 128.109.157.30

Ganz ähnlich geht es, wenn Sie nach MX-Records usw. fragen wollen.

  > set type=MX
  > unc.edu
  Non-authoritative answer:
  unc.edu preference = 10, mail exchanger = lambada.oit.unc.edu
  lambada.oit.unc.edu     internet address = 152.2.22.80
  Authoritative answers can be found from:
  UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
  SAMBA.ACS.UNC.EDU       internet address = 128.109.157.30

Wenn Sie den Suchtyp 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 aber auch noch verwenden, um die aktuelle Liste der Root-Name-Server zu erhalten. Sie können das tun, indem Sie nach allen NS-Records fragen, die für die Root-Domain definiert sind:

  > set type=NS
  > .
  Name Server:  fb0430.mathematik.th-darmstadt.de
  Address:  130.83.2.30
  Non-authoritative answer:
  (root)  nameserver = NS.INTERNIC.NET
  (root)  nameserver = AOS.ARL.ARMY.MIL
  (root)  nameserver = C.NYSER.NET
  (root)  nameserver = TERP.UMD.EDU
  (root)  nameserver = NS.NASA.GOV
  (root)  nameserver = NIC.NORDU.NET
  (root)  nameserver = NS.NIC.DDN.MIL
  Authoritative answers can be found from:
  (root)  nameserver = NS.INTERNIC.NET
  (root)  nameserver = AOS.ARL.ARMY.MIL
  (root)  nameserver = C.NYSER.NET
  (root)  nameserver = TERP.UMD.EDU
  (root)  nameserver = NS.NASA.GOV
  (root)  nameserver = NIC.NORDU.NET
  (root)  nameserver = NS.NIC.DDN.MIL
  NS.INTERNIC.NET internet address = 198.41.0.4
  AOS.ARL.ARMY.MIL        internet address = 128.63.4.82
  AOS.ARL.ARMY.MIL        internet address = 192.5.25.82
  AOS.ARL.ARMY.MIL        internet address = 26.3.0.29
  C.NYSER.NET     internet address = 192.33.4.12
  TERP.UMD.EDU    internet address = 128.8.10.90
  NS.NASA.GOV     internet address = 128.102.16.10
  NS.NASA.GOV     internet address = 192.52.195.10
  NS.NASA.GOV     internet address = 45.13.10.121
  NIC.NORDU.NET   internet address = 192.36.148.17
  NS.NIC.DDN.MIL  internet address = 192.112.36.4

Um eine Übersicht über alle Befehle zu bekommen, die nslookup bietet, geben Sie am Prompt den Befehl help ein. Um das Programm zu verlassen, geben Sie einfach Ctrl-D ein.

Andere Nützliche Dinge

Schließlich gibt es noch einige andere nützliche Tools, die Ihnen das Leben als BIND-Administrator leichter machen sollen. Ich beschreibe zwei von ihnen ganz kurz. Wenn Sie wissen wollen, wie diese Programme bedient werden, lesen Sie bitte die Dokumentation, die dem Source beiliegen sollte.

hostcvt ist ein Programm, das Ihnen bei Ihrer anfänglichen BIND-Konfiguration helfen soll, indem es Ihre hosts-Datei in Master-Dateien für named umsetzt. Es erzeugt sowohl A- als auch PTR-Records und achtet auf Aliase und ähnliches. Natürlich kann es nicht Ihren gesamten Job übernehmen, da Sie vielleicht noch einige der Voreinstellungen im SOA-Record anpassen oder MX-Records eintragen wollen und was dergleichen mehr ist. Trotzdem sparen Sie mit diesem Werkzeug vielleicht ein paar Aspirin. hostcvt ist Teil der BIND-Distribution, ist aber auch als einzelnes Paket auf einigen Linux-FTP-Servern zu finden.

Nachdem Sie Ihren Name-Server aufgesetzt haben, möchten Sie vielleicht Ihre Konfiguration auf Herz und Nieren überprüfen. Das ideale (und meines Wissens auch einzige) Tool ist dnswalk, ein perl-basiertes Paket, das Ihre DNS-Daten durchwandert und nach häufigen Fehlern sucht und sicherstellt, daß die Informationen konsistent sind. dnswalk wurde vor einiger Zeit in comp.sources.misc gepostet und sollte auf allen FTP-Sites verfügbar sein, die diese Gruppe archivieren. Es ist auch in den Quellen zu BIND-4.9.3 enthalten.


Fußnoten

(1)
Die Funktionsweise von DNS wurde in Kapitel 2 beschrieben.
(2)
NIS steht für Network Information System und wird in Kapitel 10 beschrieben.
(3)
Eine detaillierte Diskussion dieses Problems finden Sie in RFC 1535.
(4)
BIND-4.9.3 wird von Paul Vixie (paul@vix.com) entwickelt.
(5)
Auf Linux-FTP-Sites liegen named-Binaries, die sich alle ein wenig in ihrer Konfiguration unterscheiden. Beispielsweise legen einige ihre PID-Datei in /etc ab, andere in /tmp usw.
(6)
Beachten Sie, daß die Domain-Namen in dieser Datei ohne Punkt am Ende angegeben werden müssen. Frühere Versionen von named scheinen nachfolgende Punkte in named.boot als Fehler zu betrachten, und ignorieren die Zeile kommentarlos. Dies ist in BIND-4.9.3 behoben.
(7)
Die aktuelle Implementation beschränkt die Liste auf 10 Einträge.
(8)
Es gibt allerdings andere Methoden, die Namensliste einer Domain herauszubekommen, sie sind aber nicht so simpel wie ein Zonentransfer.
(9)
Obwohl die Dokumentation besagt, daß dies für alle Records gilt, scheint dies nur beim SOA-Record der Fall zu sein und auch hier nur nach einem bestimmten Eintrag.
(10)
Wie haben es hier leider mit einem Henne-und-Ei-Problem zu tun: Sie können Ihren Name-Server nicht nach den Root-Servern fragen, wenn Sie ihm noch keine mitgeteilt haben. Um aus diesem Dilemma herauszukommen, können Sie entweder nslookup dazu bewegen, einen anderen Name-Server zu verwenden, oder die Daten aus diesem Beispiel als Ausgangspunkt nehmen und damit die volle Liste der Root-Server erfragen.
(11)
In älteren Versionen von BIND war es möglich, einen Eintrag für localhost. einfach in eine andere Zone »einzuschmuggeln«, z.B. in die Datei named.hosts. Seit Version 4.9.3 ignoriert named alle Einträge, die nicht zu der Domain gehören, die im SOA-Record angegeben ist.

Inhaltsverzeichnis Kapitel 5 Kapitel 7