Kapitel 5 
Kapitel 7
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.
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.
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 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:
bind für DNS, hosts für /etc/hosts und nis für NIS-Abfragen enthalten.
on und off. Dieses Kommando hat keinerlei Auswirkungen auf DNS- und NIS-Anfragen.
nospoof on eingestellt.
alert on anstellen, meldet der Resolver jeden Spoof-Versuch an den syslog-Dämon.
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.
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.
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.
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 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-Befehl mehrfach benutzen.
Dem Linux File System Standard zufolge sollten Zonendaten immer in /var /named abgelegt werden.
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.
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.
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-Anweisung angegeben sind.
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.
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.
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.
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.
primary eigebunden wird, muß mit einem solchen RR beginnen. Das Datenfeld enthält die folgenden Felder:
@&guilsinglleft; durch einen Punkt ersetzt wurde. Wenn beispielsweise janet die verantworliche Person in der Virtuellen Brauerei ist, enthält dieses Feld janet.vbrew.com.
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.
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.
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.
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.
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.
[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.
[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.
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.
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=typeingeben. 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.81Wenn 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.
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.
Kapitel 5 Kapitel 7