Domain Name Service - Der Client

Vermutlich haben Sie auf die Dienste des Domain Name Service bereits zugegriffen, ohne seine Existenz wahrzunehmen. Surfen Sie im Internet? Dann verwenden Sie sicher Angaben wie www.linuxfibel.de? Aber hinter dieser Angabe verbirgt sich nichts anderes als ein symbolischer Name für eine IP-Adresse. Und wer ermittelt die Adresse zum Namen? Der Domain Name Service.

Und elektronische Post ist ohne den DNS undenkbar. Denn nur ein DNS-Server weiß, wer der zuständige Mailserver für einen Empfänger ist.

Der Domain Name Service arbeitet transparent. Sie als Anwender werden von seiner Existenz, ist er erst einmal korrekt administriert, nichts bemerken, es sei denn, er verweigert einmal seinen Dienst... Einen Rechner zu einem DNS-Client zu ernennen, ist unter Linux ein einfaches Unterfangen, da die Standard-C-Bibliothek, ohne die kein Linuxsystem laufen könnte, alle notwendigen Routinen in Form des so genannten Resolvers bereits in sich birgt. Wenige Handgriffe genügen und der Resolver wird die Funktionalität des DNS gewährleisten.

Neben der Anpassung des Resolvers werden wir Ihnen die wichtigsten Werkzeuge rund um den Domain Name Service, die Bind-Utils, vorstellen. DNS arbeitet auch ohne sie, aber hin und wieder möchten Sie vielleicht doch konkrete Informationen zu einem gegebenen Rechnernamen oder einer IP-Adresse erfahren.

Der Vollständigkeit halber muss erwähnt werden, dass auf die Konfiguration eines DNS-Clients auch komplett verzichtet werden kann, falls der Rechner mindestens als so genannter Caching-Only-DNS-Server konfiguriert wird. Ein solcher recherchiert jeden Namen nur einmalig und hält die Informationen in einem Cache (»Zwischenspeicher«) vor. Wie lange die dortigen Daten ihre Gültigkeit behalten, ist konfigurierbar. Ein solches Vorgehen ist i.d.R. effizienter als ein DNS-Client, der zu jeder Namensauflösung einen externen Server kontaktiert. Der lokale Nameserver wird bspw. verwendet, wenn die Konfigurationsdatei des Resolvers fehlt oder keinen Nameserver-Eintrag enthält. Interessieren Sie sich für eine derartige Konfiguration, so finden Sie im Abschnitt zum DNS-Server die notwendigen Hinweise.

Beim Resolver handelt es sich nicht um einen eigenen Prozess sondern um eine Bibliothek von Routinen, die von Prozessen der Netzwerkprogramme gerufen werden. Die relevante Konfigurationsdatei für den Resolver selbst ist /etc/resolv.conf.

Bezieht der Client die Daten seiner Netzwerkkonfiguration inklusive der Nameserver-Optionen via DHCP oder über das Point-To-Point-Protocol (dies ist bei Verbindungen über ein Modem der Fall), so wird die Datei »resolv.conf« i.d.R. vom entsprechenden Client-Prozess selbst erzeugt. Sie sind damit aus dem Schneider und müssen gar nichts konfigurieren (außer die Einwahl via PPP an sich bzw. den DCHP-Client).

Starten wir wiederum mit einer einfachen Beispielkonfiguration einer Datei »resolv.conf«:

search
	Aus reiner Bequemlichkeit bevorzugt der Anwender oft die Angabe eines Rechnernamens ohne angehängten Domainnamen (»erde« anstatt »erde.galaxis.de«). Ein solcher »Kurzname« ist im DNS-Namensraum kaum eindeutig, weshalb der Resolver versucht, diesen zu einem vollständigen Namen zu expandieren. Hierzu erweitert er jeden Rechnernamen, der keinen Punkt enthält, der Reihe nach um die unter search konfigurierten Suffixe. Kann ein resultierender Rechnername aufgelöst werden, endet die Suche erfolgreich. In der Beispielkonfiguration würde ein Rechnername »erde« zuerst zu »erde.saxsys.de«, dann zu »erde.linuxfibel.de« und zuletzt zu »erde.galaxis.de« erweitert werden. Erst letzterer Rechnername ergibt einen gültigen, d.h. im DNS-Namensraum existenten, Namen. Baechten Sie, dass die search-Liste auf maximal 6 Domains mit zusammen 256 Zeichen beschränkt ist. Der search-Mechanismus arbeitet vor allem bei Zugriff auf entfernte DNS-Server extrem langsam. Eine gesetzte Umgebungsvariable LOCALDOMAIN, die eine kommaspearierte Liste von Domainnamen enthält, überschreibt die Angaben einer search-Liste. Vergleichen Sie auch die Anmerkungen zum unten beschriebenem domain-Eintrag.
nameserver
	Für jeden zu befragenden Nameserver bedarf es eines eigenen nameserver-Eintrags in der Datei »/etc/resolv.conf«. Entsprechend der Reihenfolge der Einträge werden die Nameserver nacheinander kontaktiert, bis der erste erfolgreich eine Anfrage beantwortet. In den gängigen Implementierungen sind maximal drei Nameserver-Angaben zulässig. Fehlt ein nameserver-Eintrag, so wird die Anfrage an den lokalen Rechner gerichtet. Dieser muss zumindest als Caching-only-Nameserver konfiguriert sein (sonst schlägt jede Anfrage fehl).

Die beiden »gängigen« Einträge der Datei »/etc/resolv.conf« sind damit benannt; die weiteren Möglichkeiten beschreibt folgende Zusammenstellung:

domain
	domain besitzt eine ähnliche Aufgabe wie search. Tatsächlich sollten nicht beide Einträge in einer »/etc/resolv.conf« Verwendung finden. Ist dem dennoch so, gilt der zuletzt gefundene Eintrag aus der Datei. Im Unterschied zu search enthält domain nur den Namen der lokalen Domain. Der Resolver wird jeden Rechnernamen, der keinen Punkt enthält, um diesen Domainnamen erweitern. Fehlen sowohl ein domain- als auch ein search-Eintrag, so wird der durch gethostbyname() gelieferte Name verwendet.
sortlist
	Verfügt ein Rechner über mehrere IP-Adressen, so kann eine Anfrage beim Resolver zu einer Liste von mehreren Adressen führen, deren interne Reihenfolge unspezifiziert ist. Um die Bevorzugung bestimmter Adressen zu erzwingen, können im sortlist-Eintrag die Adressen der Netzwerke angegeben werden, aus deren Bereich Adressen zuvorderst in der Ergebnisliste zu platzieren sind. Betrachten Sie als Beispiel ein umfangreiches lokales Netz, in dem mehrere Rechner über Schnittstellen zu anderen Netzen verfügen. Hier wäre es sicher effizient, wenn die Suche nach Adressen der lokalen Rechner die »interne« Adresse liefern würde, um umfangreiches »Routen« zu «äßren Adressen zu unterbinden.
options
	Derzeit kann das Verhalten des Resolvers über zwei Optionen beeinflusst werden. debug aktiviert erweiterte Statusmeldungen des Resolvers, die eventuell zur Fehlersuche nützlich sein können. Mit ndots:n wird die Regel manipuliert, wie viele Punkte ein Rechnernamen enthalten muss, um das Anfügen der Standarddomain zu unterbinden. Die Voreinstellung lautet »ndots:1«, was letztlich dazu führt, dass die Standarddomain einzig angefügt wird, wenn der Rechnername keinen Punkt enthält oder - anders ausgedrückt - enthält der Rechnername mindestens einen Punkt, so wird er nicht um die Standarddomain erweitert.

Und nochmals möchten wir unterstreichen, dass eine nicht existente oder eine leere Datei »resolv.conf« dazu führt, dass implizit als Nameserver der lokale Rechner angenommen wird und als Standarddomain die lokale Domain (die hoffentlich gethostbyname() liefert). Diese Konfiguration entspricht genau der client-seitigen Konfiguration eines Caching-Only-Nameservers.

Nslookup ist traditioneller Bestanddteil der BIND-Software und dient einzig als Debugging-Werkzeug bei der Fehlersuche. Es erlaubt die direkte Abfrage eines Nameservers und Zugriff auf nahezu jede Information. Ab BIND Version 9 ist Nslookup nur noch aus Kompatibilitätsgründen enthalten, da dessen Funktionalität komplett vom neueren dig übernommen wurde.

Kommandozeilenmodus

Nslookup kennt Abfragen im interaktiven Modus und direkt über die Befehlszeile. Letztere Verfahrensweise zeigt folgendes Beispiel:

Wie in diesem kleinen Beispiel gut zu sehen ist, wird die Anfrage nach dem Internetnamen www.linuxfibel.de von einem Nameserver (10.0.0.2) auf dem DNS-Port (53) beantwortet. Dieser Nameserver hat fr den gesuchten Namen einen Alias (Decknamen) gefunden und ist nun dieser Spur gefolgt. Als Ergebnis dieser Suche stieﾟ er wieder auf einen Alias und hat letztendlich die 194.180.239.13 als offizielle IP-Adresse herausgefunden, mit der nun eine Verbindung, bspw. zu einer Internet-Seite oder eine Remote-Verbindung etabliert werden kann. Sollte die Suchabfrage kein Ergebnis hervorbringen, so kann dieses System auch nicht angesprochen werden und existiert daher nicht. Natrlich kann auch ein reverse lookup durchgefhrt werden, dass dann einen Internetnamen als Ergebnis hat. Eine sehr interessante Option ist type. Mit dieser Option lassen sich beispielsweise alle Mail- oder Nameserver anzeigen. (nslookup type=mx www.google.de).

Bei der Ausfhrung gibt es zwei Modi der interactive und der non-interactiv Mode. Normalerweise wird das Programm im non-interactive Mode ausgefhrt (siehe Beispiel) und gibt als Ergebnis eine Adresse/Namen oder Fehlermeldung zurck. Beim interactive Mode hat der User nun die Mlichkeit eine Reihe von Systemen in Folge abzufragen. ﾄhnlich einer Shell, wird der User gebeten, bei Rckmeldung eine erneute Abfrage einzugeben.

Dieses Tool ist sehr betagt und wird, wie im Beispiel zu sehen ist, langsam aber sicher aus dem Support und den n臘hsten Releases entfernt werden.

Interaktiver Modus

Dig (Domain Information Groper) ist das Nachfolgetool von nslookup. Wie im Beispiel zu sehen ist, bekommt der User einiges mehr an Informationen heraus, als beim alten Auflevorgang. Hierbei wird auch angezeigt, welcher Autorit舩 die Zone untersteht, sowie eine gleichzeitige zus舩zliche Auflung aller Nameserver.

Ein weiteres Diagnose-Werkzeug ist host, das per Voreinstellung lediglich eine verkrzte Ausgabe der vorherigen Tools darstellt, sich jedoch mit diversen Schaltern und Parametern zu einem sehr m臘htigen Werkzeug verwandeln kann.