1.12.4. Resolver

In der BIND-Implementation ist die Resolver-Funktionalität in Bibliotheksfunktionen wie gethostbyname(3) und gethostbyaddr(3) eingebaut und damit in die Anwendungen wie telnet oder ftp selbst eingebunden. Der Resolver ist hier also kein separater Prozeß.

Diese Funktionen senden nur eine Anfrage (query) ab und warten auf eine Antwort. Wenn diese ausbleibt, wiederholen sie die Anfrage, wobei sie sich ggf. auch an einen anderen Nameserver wenden. Es wird also kein Cache aufgebaut. Bei gleicher Anfrage wird wieder der NS befragt. Da die Hauptarbeit den angesprochenen NS überlassen bleibt, spricht man von einem "Stub Resolver".

Die Konfiguration des Resolvers unter Linux ist relativ einfach. In der Datei /etc/host.conf legt man fest, welche Dienste für die Namensauflösung in welcher Reihenfolge zu nutzen sind:

# /etc/host.conf
# Wir benutzen den NS. Falls der nicht laeuft, 
# greifen wir auf die Datei /etc/hosts zurueck.
order   bind,hosts

Nun legt man in der Datei /etc/resolv.conf fest, welche Nameserver zu benutzen sind (häufig auf maximal drei begrenzt). Dabei ist deren IP-Adresse anzugeben, nicht etwa der Name (um den herauszubekommen, brauchen wir ja den NS). Die NS werden genau in dieser Reihenfolge abgefragt, im Normalfall also immer nur der erste. Nur wenn dieser nicht erreichbar ist, wird nach einem Timeout der nächste befragt. Ist kein NS festgelegt oder existiert die Datei /etc/resolv.conf gar nicht, wird versucht, den evtl. auf dem lokalen Rechner laufenden NS abzufragen.

Welche Nameserver man benutzen kann, muß man bei seinem Provider oder Netzadministrator erfragen. Je schneller und zuverlässiger ein Nameserver erreicht werden kann, desto besser ist es.

Zwei weitere Optionen enthalten Domains, die an einen relativen Hostnamen (ohne . am Ende) angehängt werden, wenn die Auflösung des Namens selbst nicht zum Erfolg führt. Die search-Option enthält eine durch Leerzeichen getrennte Liste von Domainnamen, die nacheinander an den abzufragenden Hostnamen angehängt werden, bis der NS einen Eintrag findet.

Fehlt eine search-Angabe, wird die Suchliste aus der eigenen Domain (festgelegt in einer domain-Anweisung) gebildet, indem zuerst der volle Domainname versucht wird, dann die übergeordnete Domain und so weiter. Machen wir uns das an einem Beispiel deutlich:

# /etc/resolv.conf
#
domain  hrz.tu-chemnitz.de
search  hrz.tu-chemnitz.de informatik.tu-chemnitz.de tu-chemnitz.de
nameserver  134.109.132.51
nameserver  134.109.192.18

Zur Auflösung des Namens www startet der Resolver bis zum Erfolg bzw. definitiven Mißerfolg im Standardfall nacheinander folgende Abfragen: www.hrz.tu-chemnitz.de, www.informatik.tu-chemnitz.de, www.tu-chemnitz.de und www.

Wir erkennen, daß hierbei der von uns spezifizierte Name erst ganz am Schluß auftaucht. In den zuvor erfolgten Abfragen wurden an ihn schrittweise alle Elemente der search-Liste angehängt. Enthielte dagegen unser Name www mindestens eine bestimmte (über /etc/resolv.conf einstellbare und mit dem Default-Wert 1 versehene) Anzahl Punkte, so würde er vom Resolver zuerst und nicht wie oben zuletzt abgefragt (vgl. dazu auch das unten folgende Beispiel mit samson.hrz).

Bei anderen Resolvern (z.B. bei Windows 95/NT und Trumpet Winsock) sind im wesentlichen dieselben Informationen wie oben anzugeben, allerdings unterscheiden sich die verschiedenen Implementierungen hinsichtlich der konkreten Art der Spezifikation dieser Parameter mehr oder minder deutlich voneinander. Die Details sind der jeweiligen Dokumentation zu entnehmen.

Tools

Neben dem in Netzprogrammen eingebauten Resolver gibt es aber auch spezielle Programme, mit denen NS abgefragt werden können. Wir wollen hier das Programm nslookup etwas näher untersuchen, was neben anderen Tools, wie z.B. dig oder host, Bestandteil der BIND-Implementation ist. Es erlaubt uns, beliebige NS gezielt abzufragen und das Verhalten von Resolvern auszutesten. Es wird häufig zur Fehlersuche verwendet.

Anhand einer "Beispielsitzung" soll die prinzipielle Verwendung des Programms verdeutlicht werden (eigene Eingaben sind fett geschrieben):

% nslookup
- ohne Argumente -> interaktiver Modus
Default Server: saturn.hrz.tu-chemnitz.de
Address: 134.109.132.51
- wendet sich an den in /etc/resolv.conf eingestellten Nameserver
> samson
- Abfrage eines Domainnamens (voreingestellter RR: A)
Name: samson.hrz.tu-chemnitz.de
Address: 134.109.2.6
set debug
> samson.hrz
- Im Debug-Modus sehen wir, welche Anfragen wirklich an den NS abgesendet werden.
...
;; res_mkquery(0, samson.hrz, 1, 1)
- Zuerst der eingegebene Name ... keine Antwort. Nun wird die Suchliste
(Option search in /etc/resolv.conf wie im obigen Bsp.) probiert.
...
;; res_mkquery(0, samson.hrz.hrz.tu-chemnitz.de, 1, 1)
...
;; res_mkquery(0, samson.hrz.informatik.tu-chemnitz.de, 1, 1)
...
;; res_mkquery(0, samson.hrz.tu-chemnitz.de, 1, 1)
- endlich die Antwort
> set nodebug
- so schön ist Debugging nun auch nicht...
> set q=ns
- Abfrage von anderen RR-Typen, z.B. NS
> dfn.de.
- Punkt am Ende = absolute Domain, keine Suchliste anhängen!
...
Non-authoritative answer:
dfn.de nameserver = names.zrz.tu-berlin.de
dfn.de nameserver = ns.nic.de
dfn.de nameserver = ws-dus.dfn.de
...
- die Antwort vom eigenen NS
> server ws-dus.dfn.de.
- anderen NS abfragen
> ls dfn.de.
- Zonentransfer = Abfrage aller Daten einer Zone
[ws-dus.dfn.de]
dfn.de. server = names.zrz.tu-berlin.de
...
alkor 192.76.176.51
luyten 192.76.176.52
aldebaran 192.76.176.62
...
mizar 192.76.176.50
DFN-TRANS 192.108.72.0

> help

- Kommandoübersicht ... die können Sie sich selbst ansehen.
> exit
- Verlassen des Programms (auch CTRL-D)

Mit etwas Trick kann man auch das Timeout-Verhalten des Resolvers erkunden: Man gibt als NS einen Rechner an, auf dem gar keiner läuft. Mit gesetzter Debug-Option startet man nun eine beliebige Anfrage ...


Vertiefung:
© Frank Richter, Holger Trapp, 27.4.1998