Linux - Wegweiser für Netzwerker

Online-Version

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Der Einsatz von named

Das Programm, das auf den meisten UNIX-Maschinen den DNS-Dienst zur Verfügung stellt, heißt named. Dieser Server wurde ursprünglich für BSD entwickelt und ist für Anfragen von Klienten und eventuell anderen Name-Servern zuständig. Die Version 4 der BIND-Software war ziemlich lange aktuell und wurde in die meisten Linux-Distributionen integriert. Mittlerweile steht für fast alle Linux-Distributionen das neuere BIND Version 8 zur Verfügung. Diese Version wurde im Vergleich zur vorhergehenden stark verändert. Sie bietet eine erweiterte Funktionalität, z.B. Unterstützung für dynamische DNS-Updates und Änderungsmeldungen, ist viel leistungsfähiger und benutzt eine neue Syntax für die Konfigurationsdatei.¹ Details hierzu finden Sie in der Dokumentation, die der Quelldistribution beiliegt.

Dieser Abschnitt setzt voraus, daß Sie schon etwas über die Funktionsweise von DNS, dem Domain Name System, wissen. Wenn die folgende Erläuterung für Sie wie böhmische Dörfer klingt, sollten Sie sich nochmal das Wie DNS funktioniert vornehmen.

named wird für gewöhnlich beim Booten des Rechners gestartet und läuft, bis die Maschine wieder heruntergefahren wird. Die BIND-Implementierungen vor Version 8 lesen zunächst die Datei /etc/named.boot, die ihre Konfiguration beschreibt, und eine Reihe weiterer Dateien, die die Zuordnung von Domainnamen zu Adressen und ähnliches festlegen. Letztere werden auch Zonendateien (zone files) genannt. Ab Version 8 benutzt BIND die Konfigurationsdatei /etc/named.conf anstelle von /etc/named.boot.

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

# /usr/sbin/named

named wird gestartet, liest die Datei named.boot und alle darin angegebenen Zonen-Dateien. Die Prozeß-ID wird im ASCII-Format in der Datei /var/run/named.pid abgelegt und, falls erforderlich, werden die Zonen-Dateien von primären Servern heruntergeladen. Anschließend wartet er auf Port 53 auf einkommende Anfragen.

Die Datei named.boot

Vor Version 8 waren die Konfigurationsdateien von BIND sehr einfach strukturiert. In Version 8 wurde eine völlig neu gestaltete Syntax eingeführt, um den vielen neuen Features gerecht zu werden. Das fängt bereits beim Namen der Konfigurationsdatei an; sie wurde von der alten Bezeichnung /etc/named.boot in die neue Bezeichnung /etc/named.conf geändert. Wir beziehen uns im folgenden noch auf die alte Version, da sie in den Distributionen immer noch am weitesten verbreitet ist, präsentieren dabei immer eine äquivalente named.conf, so daß Sie die Unterschiede leichter erkennen können und wissen, wie Sie das alte Format in das neue konvertieren müssen.

Die Datei named.boot ist im allgemeinen sehr klein und enthält wenig mehr als Verweise auf die Master-Dateien, in denen sich Zonendaten und Verweise auf andere Name-Server befinden. Kommentare in der Boot-Datei beginnen mit einem Hashzeichen (#) oder einem Semikolon (;) und reichen bis zum Zeilenende.Bevor wir aber das Format von named.boot im Detail betrachten, werfen wir zunächst einen Blick auf die Beispieldatei für vlager in Tabelle 6.8.

Beispiel 6.8: Datei named.boot für vlager

; ; Datei /etc/named.boot für vlager.vbrew.com ; directory     /var/named ; ;             domain                   file ;-----------------  cache         .                        named.ca primary       vbrew.com                named.hosts primary       0.0.127.in-addr.arpa     named.local primary       16.172.in-addr.arpa      named.rev

Lassen Sie uns einen Blick auf jede einzelne Anweisung werfen. Das Schlüsselwort directory teilt named mit, daß alle nachfolgenden Dateien, z.B. Zonendateien, aus dem angegebenen Verzeichnis /var/named geladen werden sollen. Das spart ein wenig Tipparbeit.

Der im Beispiel gezeigte Befehl primary lädt Informationen in named. Diese Informationen werden jeweils der Master-Datei entnommen, die im letzten Argument angegeben wird. Diese Dateien repräsentieren DNS-Resource-Records, die wir uns später genauer ansehen werden.

Im diesem Beispiel wird named als primärer Name-Server für drei Domains konfiguriert, wie die primary-Anweisungen am Ende der Datei zeigen. Die erste Zeile weist named beispielsweise an, als primärer Server für vbrew.com zu dienen und die Zonendaten der Datei named.hosts zu entnehmen.

Der cache-Eintrag hat eine besondere Aufgabe und sollte auf fast 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 Cache-Datei named.ca zu laden. Diese Adressen heißen in der Fachsprache 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: Diese Option gibt das Verzeichnis an, in dem sich die Zonendateien befinden. Damit können Dateinamen in anderen Optionen 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: Diese Option benötigt einen Domainnamen und einen Dateinamen als Argumente und erklärt den lokalen Server als autoritativ für diese Domain. Als primärer Server lädt named die Zoneninformationen aus der angegebenen Master-Datei.

Es gibt immer wenigstens einen primary-Eintrag in der Konfigurationsdatei, der für das Reverse Mapping (oder der Rückwärtsauflösung) der Netzwerkadresse 127.0.0.0, das Loopback-Netzwerk, zuständig ist.
secondary: Dieser Befehl benötigt einen Domainnamen, eine Adreßliste und einen Dateinamen als Argumente. Er erklärt den lokalen Server zum sekundären Master-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, sondern versucht, sie vom primären Server zu laden. Für named muß die Adreßliste deshalb die IP-Adresse mindestens eines primären Servers enthalten. Der lokale Server probiert diese Name-Server der Reihe nach durch, bis er die Zonendaten erfolgreich übertragen konnte. Die Daten werden anschließend in der Backup-Datei abgelegt, die im dritten Argument angegeben wurde. Wenn keiner der angegebenen Server erreichbar ist, lädt named die Zoneninformationen statt dessen aus der Backup-Datei.

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: Diese Option erwartet eine Domain und einen Dateinamen als Argumente. Die Datei enthält eine Liste von Records mit den 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, wenn der nächste Server nicht im lokalen Netz liegt. 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 (siehe die folgende Option forwarders).
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 mit Hilfe seines Caches aufzulösen. Diese Server werden der Reihe nach ausprobiert, bis einer von ihnen die Anfrage beantwortet. Normalerweise würden Sie hier den Name-Server Ihres Netz-Providers oder einen anderen wohlbekannten Server als Forwarder einsetzen.
slave: Dieser Befehl macht Ihren Name-Server zu einem Slave-Server. Das bedeutet, daß er niemals selbst rekursive Anfragen durchführt, sondern sie immer an die Server weiterleitet, die in der forwarders-Anweisung angegeben sind.

Es gibt zwei Optionen, auf die wir hier nicht näher eingehen: sortlist und domain. In den Datenbankfeldern können noch zwei weitere Direktiven vorkommen: $INCLUDE und $ORIGIN.Sie kommen eher selten vor, weswegen wir darauf auch nicht eingehen.

Die BIND-8-Konfigurationsdatei host.conf

BIND Version 8 führte eine ganze Reihe neuer Features ein, dazu kam eine völlig neu gestaltete Syntax für die Konfigurationsdatei. Die Datei named.boot mit ihren simplen einzeiligen Anweisungen wurde durch die Datei named.conf ersetzt, die Anweisungen in einer Syntax enthält, die mit der von gated und C vergleichbar ist.

Die neue Syntax ist komplexer; glücklicherweise wurde ein Tool bereitgestellt, mit dem die Konvertierung der alten Syntax in die neue automatisch vorgenommen wird. Im Quellpaket von BIND 8 ist ein Perl-Kommando namens named-bootconf.pl enthalten, das Ihre vorhandene named.boot von der Standardeingabe (stdin) einliest, sie in die äquivalente Syntax von named.conf konvertiert und das Resultat an die Standardausgabe (stdout) ausgibt. Um dieses Tool anwenden zu können, muß natürlich ein perl-Interpreter installiert sein.

Sie sollten das Skript etwa wie folgt anwenden:

# cd /etc # named-bootconf.pl <named.boot >named.conf

Das Skript produziert dann eine Datei named.conf, die wie in Tabelle 6.9 aussieht. Wir haben einige der ansonsten hilfreichen Kommentare entfernt, die das Skript generiert, um die direkte Verwandschaft zwischen der alten und der neuen Syntax zu verdeutlichen. Sie die Unterschiede zwischen der alten und neuen Syntax direkt vergleichen können.

Beispiel 6.9: Zur named.conf äquivalente Datei im BIND-8-Format

// // Datei /etc/named.boot für vlager.vbrew.com options {         directory "/var/named"; };  zone "." {         type hint;         file "named.ca"; };  zone "vbrew.com" {         type master;         file "named.hosts"; };  zone "0.0.127.in-addr.arpa" {         type master;         file "named.local"; };  zone "16.172.in-addr.arpa" {         type master;         file "named.rev"; };

Wenn Sie genauer hinsehen, erkennen Sie, daß jede der einzeiligen Anweisungen von named.boot in named.conf in eine C-ähnliche Anweisung konvertiert wurde, die in {}-Klammern steht.

Die Kommentare, die in named.boot mit einem Semikolon (;) eingeleitet wurden, beginnen nun mit zwei Schrägstrichen (//).

Die directory-Anweisung wurde in einen options-Block mit einer directory-Klausel übersetzt.

Die cache- und primary-Anweisungen wurden in zone-Blöcke mit type-Klauseln vom Typ hint bzw. master konvertiert.

Die Zonendateien brauchen überhaupt nicht verändert zu werden, da sich ihre Syntax nicht geändert hat.

Die neue Konfigurationssyntax ermöglicht viele neue Optionen, die wir bisher noch nicht behandelt haben. Die beste Informationsquelle für diese Optionen ist die im neuen BIND-8-Quellpaket enthaltene Dokumentation.

Die Zonendateien

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

Die Daten in einer Master-Datei sind in sogenannte Resource-Records (RRs) aufgeteilt. Sie stellen die kleinste durch das DNS erhältliche Informationseinheit dar. Jeder Resource-Record hat einen bestimmten Typ. Die A-Records beispielsweise bilden einen Namen auf eine Adresse ab, und ein CNAME-Record definiert einen Alias für einen anderen Domainnamen. Beispiel Tabelle 6.11 zeigt die Master-Datei named.hosts für die virtuelle Brauerei.

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

[domain] [ttl] [class] type rdata

Die einzelnen Felder werden durch Leerzeichen oder Tabulatorzeichen 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:

domain: Dies ist der Domainname, 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 vorhergehenden SOA-Record angegebene Minimalwert 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-Netzwerke müssen die Einträge den Typ IN haben.

Wenn keine Klasse angegeben ist, wird dafür die Klasse des vorausgehenden RR genommen.
type: Dies beschreibt den Typ des RR. Die häufigsten Typen sind A, SOA, PTR und NS. Im folgenden werden die verschiedenen RR-Typen im einzelnen beschrieben.
rdata: Dieses Feld enthält die Daten, die zum RR gehören. Das Format dieses Feldes hängt vom Typ des RR ab und wird im folgenden für jeden RR separat beschrieben.

Das folgende ist eine unvollständige Liste von RRs, die in DNS-Master-Dateien benutzt werden können. Es gibt noch ein paar mehr, aber auf die gehen wir hier nicht ein. Sie sind experimentell und allgemein nicht besonders nützlich.

SOA

Dieser RR beschreibt eine Zone innerhalb des Verantwortungsbereiches dieses Servers (SOA bedeutet Start Of Authority). Er macht deutlich, daß die Records, die dem SOA-RR folgen, autoritative Informationen für die Domain enthalten. Jede Datei, die durch den Befehl primary eingebunden wird, muß mit einem solchen RR beginnen. Das Datenfeld enthält die folgenden Felder:

origin: Dies ist der kanonische Hostname des primären Name-Servers der Domain. Er wird üblicherweise als absoluter Name angegeben.
contact: Dies ist die E-Mail-Adresse der Person, die für diese Zone verantwortlich ist, wobei das Zeichen @ durch einen Punkt ersetzt wurde. Wenn beispielsweise janet die verantwortliche Person in der virtuellen Brauerei ist, enthält dieses Feld janet.vbrew.com.
serial: Dies ist die Versionsnummer der Zonendatei, geschrieben als eine einzige Dezimalzahl. Jedesmal, wenn Daten in der Zone verändert werden, sollte diese Zahl inkrementiert werden. Es ist allgemein üblich, eine Zahl zu benutzen, die das Datum der letzten Änderung mit einer daran angehängten Versionsnummer enthält; auf diese Weise werden auch mehrere Änderungen pro Tag erfaßt. Zum Beispiel weist die Zahl 2000012601 auf Update 01 am 26. Januar 2000 hin.

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, fordern die sekundären Server den SOA-Record des primären Servers in bestimmten Zeitabständen an und vergleichen die Versionsnummer mit der des “gecachten” SOA-Records. Wenn sich die Zahl verändert hat, laden sie 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 ändert sich die Netztopologie nicht allzu häufig, weshalb diese Zahl im Falle größerer Domains ungefähr einem Tag 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 Server zu erreichen, wenn eine Anfrage oder eine Aktualisierung der Zonendaten fehlschlägt. 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 verbraucht. 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 in dieser Zeit nicht gelingt, den primären Server zu erreichen. Sie sollten diesen Wert normalerweise auf mindestens eine Woche setzen (d.h. 604.800 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 halten 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 Zoneninformationen 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 (86.400 Sekunden) setzen.

A

Dieser Record-Typ ordnet einem Hostnamen eine Adresse zu. 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 RR benutzte Hostname ist der offizielle oder kanonische Hostname. Alle anderen Namen sind Aliase und müssen mittels eines CNAME-Records auf den kanonischen Hostnamen abgebildet werden. Wenn der kanonische Name unseres Hosts vlager lautete, hätten wir einen A-Record, der diesen Hostnamen mit seiner IP-Adresse assoziiert. Angenommen, wir wollten einen zweiten Namen mit dieser IP-Adresse haben, sagen wir mal news. Dann müßten wir einen CNAME-Record erzeugen, der diesen alternativen Namen mit dem kanonischen Namen assoziiert. Über CNAME-Records reden wir noch in Kürze.

NS

NS-Records dienen dazu, den primären und alle sekundären Name-Server einer Zone anzugeben. Ein NS-Record zeigt auf einen Master-Name-Server der angegebenen Zone; das Resource-Datenfeld enthält den Hostnamen 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 den Master-Zonendateien der untergeordneten Zone selbst auf. Die Listen der Server, die jeweils in der delegierenden und delegierten Zone aufgeführt werden, sollten übereinstimmen.

Der NS-Record legt den Namen des primären Name-Servers sowie die Namen der sekundären Name-Server 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 Name-Server erreichbar ist, und wir können auch nicht den Name-Server erreichen, bevor wir seine Adresse kennen. Um uns aus diesem Dilemma zu befreien, können wir direkt in den Name-Server der übergeordneten Zone spezielle A-Records eintragen, die es den Name-Servern der übergeordneten Zone ermöglichen, die IP-Adressen der Name-Server der delegierten Zone zu ermitteln. Diese Records werden für gewöhnlich Glue Records (glue = Leim) genannt, da sie gewissermaßen als “Kleber” die delegierte Zone an ihre übergeordnete Zone binden.

CNAME

Dieser Record-Typ ordnet einem Alias für einen Host dessen kanonischen Hostnamen zu. Er stellt einen alternativen Namen zur Verfügung, mit dem sich die Anwender 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 RRs.

PTR

Dieser Record wird verwendet, um Namen in der Domain in-addr.arpa (die IP-Adressen repräsentieren) auf den zugehörigen kanonischen Hostnamen abzubilden. Das Datenfeld dieses RR enthält den kanonischen Hostnamen.

MX

Dieser RR legt einen sogenannten Mail Exchanger für die angegebene Domain fest. Mail Exchanger werden ausführlich in Mail-Routing im Internet 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 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 übertragen kann. Dabei beginnt es bei dem Mail Exchanger (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 (RFC-1700) enthält eine Liste gültiger “Maschinennamen”, die Sie in diesem Feld eintragen können. Wenn das Feld Leerzeichen enthält, muß es in doppelte Anführungszeichen gesetzt werden. Das Feld software bezeichnet das Betriebssystem des Hosts. Auch hier sollten gültige Namen aus RFC-1700 gewählt werden.

Ein HINFO-Record zur Beschreibung einer Intel-basierten Linux-Maschine hat etwa die Form:

tao         36500  IN  HINFO  IBM-PC  LINUX2.2

HINFO-Records für Linux auf Motorola 68000-basierten Maschinen sollten etwa wie folgt aussehen:

cevad 36500 IN  HINFO  ATARI-104ST LINUX2.0 jedd  36500 IN  HINFO  AMIGA-3000  LINUX2.0

Caching-Only-Konfigurationen für named

Bevor wir uns auf die Konfiguration eines vollständigen Name-Servers stürzen, sollten wir kurz noch ü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-Anfragen, die auf Ihrem Host produziert werden. Der Vorteil dieses Schemas liegt darin, daß damit ein Cache aufgebaut wird, so daß nur noch die erste Anfrage nach einem bestimmten Host tatsächlich zum Name-Server im Internet gesendet wird. Jede nachfolgende gleichlautende Anfrage wird dann direkt aus dem Cache Ihres lokalen Name-Servers heraus beantwortet. Das mag vielleich jetzt noch nicht besonders nützlich sein, macht sich aber beim Einwählen ins Internet bezahlt, wie es in Kapitel 7 Serial Line IP, und Kapitel 8 Das Point-to-Point-Protokoll, beschrieben wird.

Eine named.boot-Datei für einen Caching-only-Server sieht etwa folgendermaßen aus:

; named.boot-Datei für Caching-only-Server directory                            /var/named primary       0.0.127.in-addr.arpa   named.local ; localhost network cache         .                      named.ca    ; root servers

Zusätzlich zu dieser named.boot-Datei müssen Sie auch die Datei named.ca mit einer gültigen Liste von Root-Name-Servern ausstatten. Zu diesem Zweck können Sie eine Kopie von Tabelle 6.10 benutzen. Es werden keine weiteren Dateien zur Konfiguration eines Caching-only-Servers benötigt.

Die Master-Dateien

Tabelle 6.10, Tabelle 6.11, Tabelle 6.12 und Tabelle 6.13 enthalten Beispieldateien für den Name-Server der virtuellen Brauerei, der auf vlager läuft. Da wir hier nur ein relativ einfaches LAN betrachten, ist das Beispiel nicht allzu kompliziert.

Die Datei named.ca in Beispiel Tabelle 6.10 zeigt, wie die Hints für einen Root-Name-Server aussehen könnten. Eine typische Cache-Datei enthält normalerweise ein rundes Dutzend Name-Server. Um eine aktuelle Liste der Name-Server zu bekommen, können Sie das Programm nslookup verwenden, das im nächsten Abschnitt beschrieben wird.³

Beispiel 6.10: Die Datei named.ca

; ; /var/named/named.ca          Cache-Datei der virtuellen Brauerei. ;                Wir sind nicht im Internet und brauchen daher ;                keine Root-Server. Um diese Records zu aktivieren, sind ;                die Semikolons zu entfernen. ; ;.                        3600000  IN  NS    A.ROOT-SERVERS.NET. ;A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4 ;.                        3600000      NS    B.ROOT-SERVERS.NET. ;B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107 ;.                        3600000      NS    C.ROOT-SERVERS.NET. ;C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12 ;.                        3600000      NS    D.ROOT-SERVERS.NET. ;D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90 ;.                        3600000      NS    E.ROOT-SERVERS.NET. ;E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10 ;.                        3600000      NS    F.ROOT-SERVERS.NET. ;F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241 ;.                        3600000      NS    G.ROOT-SERVERS.NET. ;G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4 ;.                        3600000      NS    H.ROOT-SERVERS.NET. ;H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53 ;.                        3600000      NS    I.ROOT-SERVERS.NET. ;I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17 ;.                        3600000      NS    J.ROOT-SERVERS.NET. ;J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10 ;.                        3600000      NS    K.ROOT-SERVERS.NET. ;K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129 ;.                        3600000      NS    L.ROOT-SERVERS.NET. ;L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12 ;.                        3600000      NS    M.ROOT-SERVERS.NET. ;M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33 ;

Beispiel 6.11: Die Datei named.hosts

; ; /var/named/named.hosts       Lokale Hosts in der virtuellen Brauerei ;                              Ursprung ist vbrew.com ; @                IN  SOA   vlager.vbrew.com. janet.vbrew.com. (                            2000012601 ; serial                            86400      ; refresh: once per day                            3600       ; retry:   one hour                            3600000    ; expire:  42 days                            604800     ; minimum: 1 week                            )                  IN  NS    vlager.vbrew.com. ; ; lokale Mail wird in vlager verteilt                  IN  MX    10 vlager ; ; Loopback-Adresse localhost.       IN  A     127.0.0.1 ; ; Ethernet der virtuellen Brauerei vlager           IN  A     172.16.1.1 vlager-if1       IN  CNAME vlager ; vlager ist auch News-Server news             IN  CNAME vlager vstout           IN  A     172.16.1.2 vale             IN  A     172.16.1.3 ; ; Ethernet der virtuellen Weinkellerei 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 ; ; Ethernet der Tochtergesellschaft Virtuelle Spirituosen vbourbon         IN  A     172.16.3.1 vbourbon-if1     IN  CNAME vbourbon

Beispiel 6.12: Die Datei named.local

; ; /var/named/named.local       Reverse Mapping von 127.0.0 ;                              Ursprung ist 0.0.127.in-addr.arpa. ; @             IN  SOA   vlager.vbrew.com. joe.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.

Beispiel 6.13: Die Datei named.rev

; ; /var/named/named.rev         Reverse Mapping unserer IP-Adressen ;                              Ursprung ist 16.172.in-addr.arpa. ; @             IN  SOA   vlager.vbrew.com. joe.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. ; Weinkellerei 1.2           IN  PTR   vlager-if2.vbrew.com. 2.2           IN  PTR   vbardolino.vbrew.com. 3.2           IN  PTR   vchianti.vbrew.com. 4.2           IN  PTR   vbeaujolais.vbrew.com.

Test Ihrer DNS-Konfiguration

nslookup ist ein großartiges Tool zum Funktionstest Ihrer Name-Server-Konfiguration. Es kann sowohl interaktiv als auch als einfaches Kommando verwendet werden. Als Kommando rufen Sie es wie folgt auf:

$ nslookup hostname

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

Der interaktive Modus ist allerdings wesentlich spannender. Sie können in diesem Modus nicht nur einzelne Hostnamen 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 Domainnamen angeben. Per Voreinstellung fragt nslookup nach A-Records, die die zum Domainnamen gehörende IP-Adresse enthalten.

Sie können sich bestimmte Record-Typen mit

> set type=type

ansehen, wobei type einer der oben beschriebenen Record-Typen oder der String ANY ist.

Ein Dialog mit nslookup könnte beispielsweise so aussehen:

$ nslookup Default Server:  tao.linux.org.au Address:  203.41.101.121  > metalab.unc.edu Server:  tao.linux.org.au Address:  203.41.101.121  Name:    metalab.unc.edu Address:  152.2.254.81  >

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 A-Records gibt, aber andere Record-Typen gefunden wurden, gibt nslookup die Fehlermeldung No type A records found zurück. 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 Server:  tao.linux.org.au Address:  203.41.101.121  *** No address (A) records available for unc.edu > set type=SOA > unc.edu Server:  tao.linux.org.au Address:  203.41.101.121  unc.edu         origin = ns.unc.edu         mail addr = host-reg.ns.unc.edu         serial = 1998111011         refresh = 14400 (4H)         retry   = 3600 (1H)         expire  = 1209600 (2W)         minimum ttl = 86400 (1D) unc.edu name server = ns2.unc.edu unc.edu name server = ncnoc.ncren.net unc.edu name server = ns.unc.edu ns2.unc.edu     internet address = 152.2.253.100 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1 ns.unc.edu      internet address = 152.2.21.1

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

> set type=MX > unc.edu Server:  tao.linux.org.au Address:  203.41.101.121  unc.edu preference = 0, mail exchanger = conga.oit.unc.edu unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu unc.edu name server = ns.unc.edu unc.edu name server = ns2.unc.edu unc.edu name server = ncnoc.ncren.net conga.oit.unc.edu       internet address = 152.2.22.21 imsety.oit.unc.edu      internet address = 152.2.21.99 ns.unc.edu      internet address = 152.2.21.1 ns2.unc.edu     internet address = 152.2.253.100 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1

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 > . Server:  tao.linux.org.au Address:  203.41.101.121  Non-authoritative answer: (root)  name server = A.ROOT-SERVERS.NET (root)  name server = H.ROOT-SERVERS.NET (root)  name server = B.ROOT-SERVERS.NET (root)  name server = C.ROOT-SERVERS.NET (root)  name server = D.ROOT-SERVERS.NET (root)  name server = E.ROOT-SERVERS.NET (root)  name server = I.ROOT-SERVERS.NET (root)  name server = F.ROOT-SERVERS.NET (root)  name server = G.ROOT-SERVERS.NET (root)  name server = J.ROOT-SERVERS.NET (root)  name server = K.ROOT-SERVERS.NET (root)  name server = L.ROOT-SERVERS.NET (root)  name server = M.ROOT-SERVERS.NET  Authoritative answers can be found from: A.ROOT-SERVERS.NET      internet address = 198.41.0.4 H.ROOT-SERVERS.NET      internet address = 128.63.2.53 B.ROOT-SERVERS.NET      internet address = 128.9.0.107 C.ROOT-SERVERS.NET      internet address = 192.33.4.12 D.ROOT-SERVERS.NET      internet address = 128.8.10.90 E.ROOT-SERVERS.NET      internet address = 192.203.230.10 I.ROOT-SERVERS.NET      internet address = 192.36.148.17 F.ROOT-SERVERS.NET      internet address = 192.5.5.241 G.ROOT-SERVERS.NET      internet address = 192.112.36.4 J.ROOT-SERVERS.NET      internet address = 198.41.0.10 K.ROOT-SERVERS.NET      internet address = 193.0.14.129 L.ROOT-SERVERS.NET      internet address = 198.32.64.12 M.ROOT-SERVERS.NET      internet address = 202.12.27.33

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

Andere nützliche Dinge

Schließlich gibt es noch einige andere nützliche Tools, die Ihnen das Leben als BIND-Administrator leichter machen. Wir beschreiben hier zwei von ihnen ganz kurz. Wenn Sie wissen wollen, wie diese Programme bedient werden, lesen Sie bitte die Dokumentation, die den Tools beiliegt.

hostcvt ist ein Programm, das Ihnen bei Ihrer anfänglichen BIND-Konfiguration behilflich ist, indem es Ihre hosts-Datei 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 und ähnliches. 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 auf einigen Linux-FTP-Servern zu finden.

Nachdem Sie Ihren Name-Server aufgesetzt haben, werden Sie wahrscheinlich Ihre Konfiguration auf Herz und Nieren überprüfen wollen. Dafür stehen Ihnen einige gute Tools zur Verfügung. Dazu gehören dnswalk, ein Perl-basiertes Paket, sowie nslint. Beide durchwandern Ihre DNS-Daten, suchen nach häufigen Fehlern und stellen sicher, daß die Informationen konsistent sind. Zwei weitere nützliche Tools sind host und dig, beides universell verwendbare Abfrage-Tools für DNS-Daten. Damit können Sie die DNS-Datenbankeinträge manuell inspizieren und diagnostizieren.

Diese Tools erhält man üblicherweise in Form vorgefertigter Softwarepakete. dnswalk und nslint sind im Quellcode erhältlich von http://www.visi.com/~barr/dnswalk/ und ftp://ftp.ee.lbl.gov/nslint.tar.Z. Der Quellcode von host und dig kann von ftp://ftp.nikhef.nl/pub/network/ und ftp://ftp.is.co.za/networking/ip/dns/dig/ heruntergeladen werden.

^1.	BIND 4.9 wurde von Paul Vixie (paul@vix.com) entwickelt. Jetzt ist das Internet Software Consortium (bind-bugs@isc.org) für die Weiterentwicklung von BIND zuständig.
^2.	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.
^3.	Wie haben es hier wieder 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, müssen Sie entweder nslookup dazu bewegen, einen anderen Name-Server zu verwenden, oder Sie können die Daten aus Tabelle 6.10 als Ausgangspunkt nehmen und damit die ganze Liste der Root-Server erfragen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen
Kontakt|Über O'Reilly|Datenschutz