Kaum jemand denkt darüber nach, doch wer eine URL im Browser abschickt, setzt eine Maschinerie in Gang, an der sich in derselben Sekunde oft weltweit Rechner beteiligen – allein schon für die Übersetzung des Hostnamens in eine maschinenlesbare Adresse via DNS.

Mehr als 300 vorgelesene Zahlen merken sich Gedächtniskünstler – allen andren aber fällt es leider oft schon schwer, die vier Zahlen einer IP-Adresse im Kopf zu behalten, an Namen erinnern sich die meisten leichter. Nur deshalb gibt es heute eine riesengroße, weltweit verteilte Datenbank, die Computernamen und -adressen kombiniert.

Die Schnittstelle zu dieser Datenbank, häufig als Resolver bezeichnet, (to resolve, auflösen, klären) bilden Funktionen der GNU-C-Library Glibc. Die am meisten benutzten heißen »gethostbyname()« für die Übersetzung eines Namens in eine IP-Adresse und »gethostbyaddr()« für den umgekehrten Weg. Mit ihren Begleitfunktionen wird diese Schnittstelle allerdings zusehends ersetzt durch eine flexiblere Version. Aktuell sind »getaddrinfo()« für die Übersetzung von Hostnamen in Adressen und »getnameinfo()« für die Gegenrichtung die bessere Wahl.

Die meisten Skriptsprachen enthalten ebenfalls entsprechende Funktionen. Perl beispielsweise bietet »gethostbyname()« und »gethostbyaddr()« an. Die neueren Funktionsvarianten sind noch nicht in jeder Implementation verfügbar, bei Perl stecken sie in einem Modul für die Kompatibilität mit IPv6. Auf Shell-Ebene stehen fertige Tools zur Verfügung, die einzelne Resolver-Funktionen anbieten. Dafür in Frage kommen beispielsweise das inzwischen allerdings veraltete »nslookup« oder das neuere »host« sowie »dig«.

Den Umgang mit Namen und Adressen erschwert die Tatsache, dass nicht alle Programme auf die Bibliotheksfunktionen zurückgreifen, sondern manche ihr eigenes Süppchen kochen. Meist möchten die Programmierer so Blockade-Effekte vermeiden, die sich beim Einsatz der Glibc-Funktionen ergeben könnten. Etliche Shell-Tools entstanden als Debugging-Werkzeuge und arbeiten deshalb mit Direktzugriff auf das Netzwerk. Zudem sind viele kleine Programme statisch übersetzt, enthalten also die Resolver-Routinen einer ganz bestimmten (häufig veralteten) Bibliotheksversion.

Einstellungssache

Der Resolver kann verschiedene Datenquellen anzapfen. Die einfachste Datenquelle ist die Datei »/etc/hosts« (siehe Listing 1). Sie enthält lediglich eine Auflistung von numerischen Adressen mit den zugeordneten Namen. Jeder Adresse können ein oder mehrere Namen entsprechen.

Das Listing zeigt noch weitere Arten von Einträgen: Der »localhost« 127.0.0.1 wird immer in »/etc/hosts« definiert, da ihn auch die lokale Interprozess-Kommunikation benötigt. Der zweite Adressblock enthält wichtige IPv6-Adressen. Der dritte Block zeigt, wie Adressen aus einem lokalen Netz ebenfalls in der lokalen Datenbank abzulegen oder Domainnamen außerhalb des eigenen Verantwortungsbereichs unkompliziert zu ergänzen sind.

Auskunft im Netz

Ist ein Hostname in »/etc/hosts« nicht zu finden, fragt der Resolver bei einem netzwerkbasierten Dienst an, dem Domain Name System (DNS). In den meisten Fällen läuft ein solcher Nameserver – die verbreitetste Implementierung ist heute BIND (Berkeley Internet Name Domain) – nicht lokal, sondern auf einem Host des Internet. Die passenden Nameserver-Adressen dafür findet der Client in der Datei »/etc/resolv.conf« (siehe Listing 2), in der sie entweder der Anwender oder ein Dienst wie der DHCP-Client eingetragen hat.

Normalerweise sind drei Nameserver-Einträge erlaubt, wobei der Resolver die Alternativen an zweiter und dritter Stelle nur benutzt, wenn der als Erster eingetragene Server nicht erreichbar ist. Die Zeile »options rotate« in Listing 2 ändert dieses Verhalten in einem LAN, sodass die Clients die einzelnen Server abwechselnd in Anspruch nehmen und sich die Last zwischen ihnen verteilt.

Der Resolver muss wissen, welche Datenquellen dem jeweiligen Linux-System zur Verfügung stehen und in welcher Reihenfolge er sie benutzen soll. Diese Information ist gleich in mehreren Konfigurationsdateien verzeichnet. Die ursprüngliche Datei für diesen Zweck heißt »/etc/host.conf«. Ein Beispiel könnte so aussehen:

order hosts,bind
multi on

Wichtigstes Schlüsselwort ist »order« gefolgt von der oder den gewünschten Methoden. Dabei stehen »hosts« für das lokale Adressenverzeichnis in »/etc/hosts« und »bind« für den Netzwerkzugriff auf das DNS-System. Das hier eingetragene »multi on« bewirkt nur, dass in »/etc/hosts« Mehrfachnennungen eines Namens erlaubt sind.

Wie das DNS entstand und bis heute funktioniert

So ging es nicht mehr weiter. Die Verfahren, die im Internet-Vorläufer Arpa-Net in den 70er Jahren noch gut funktionierten, drohten nun, da die Teilnehmerzahlen sprunghaft wuchsen, zu versagen. Zum Beispiel die Zuordnung von Namen zu Adressen: Bisher verwalteten die Netzwerk-Admins dafür eine einzige große Datei. Jeder Teilnehmer im Netz besorgte sich regelmäßig eine Kopie per FTP. Wollte jemand einen neuen Computer ans Netz anschließen, meldete er die Änderung per E-Mail dem Network Information Center (NIC), das die zentrale Hosts-Datei entsprechend aktualisierte und allen zum Download anbot. Immer mehr Rechner generierten auf diese Weise nun aber nicht nur immer mehr Traffic allein durch das massenhafte Kopieren dieses File, sie stellten die Netzverwalter auch vor unlösbare Aufgaben: So konnten sie zwar für eindeutige Adressen sorgen, aber Namenskonflikte nicht ausschließen. Ein doppelter Name löste jedoch ebenfalls ernste Störungen aus, weil er seinen unfreiwilligen, doch möglicherweise wichtigen Namensvetter verdeckte. Außerdem veralteten die Informationen bereits auf dem Weg von der Zentrale bis in den hintersten Winkel des Netzes und ließen sich nicht mehr konsistent halten. Die Suche nach einem Ausweg führte schließlich zu einem System, das – mit einigen Korrekturen und Verbesserungen – dem ungebremsten Wachstum bis heute standgehalten hat, dem Domain Name System (DNS). Sein Erfolgsrezept heißt Dezentralisierung. An die Stelle einer einzigen Instanz für die unüberschaubare Menge vernetzter Computer treten Gruppenverantwortliche. Sie managen Rechner-Kollektive oder Domains, die ihrerseits unterteilt sind und dabei so genannte Subdomains bilden. Die grafische Darstellung des Gebildes aus Gruppen und selbst wieder teilbaren Untergruppen ergibt eine Baumstruktur (Abbildung 1), ähnlich der Verzeichnishierarchie in einem Filesystem. Abbildung 1: Zonen sind logische Abschnitte einer Domäne. Hier sind beispielhaft Zonen der Toplevel-Domäne »edu« dargestellt, die jeweils durch eine Universität verwaltet werden. Waldarbeit Die Hosts sind die Blätter des Baums. So wie kein Filesystem gleichnamige Dateien in einem Verzeichnis zulässt, müssen auch die Hostnamen unterhalb des letzten Knotens eindeutig sein. In verschiedenen Domänen kann es aber genauso Rechner gleichen Namens geben wie gleichnamige Dateien in verschiedenen Verzeichnissen zulässig sind. Wer einen bestimmten Host ansprechen und eine Verwechslung ausschließen will, gibt dessen Namen, seine Domäne und alle übergeordneten Domänen bis zum Wurzelknoten an. Man spricht in diesem Fall von einem vollqualifizierten Domainnamen (FQDN). Sein Pendant im Filesystem wäre der absolute Pfad, aber mit einem wichtigen Unterschied: Pfad-Notationen beginnen mit dem Wurzelknoten (also etwa »/usr/local/bin/mozilla«), die von Internet-Namen beginnen genau andersrum mit dem Blatt, zum Beispiel »www.chips.ibm.com.«. Den Slash als Verzeichnistrenner vertreten hier Punkte. Der Wurzelknoten, die so genannte Root-Domain, hat als Namen einen leeren String. Deshalb endet der FQDN mit einem Punkt, dem letzten Trenner, auf den der Name der Wurzel folgt, der sich als Leerstring allerdings nirgends zeigt. Die Liste der Namen und der zugehörigen Adressen jeder Domäne verwaltet ein Nameserver. Die Verantwortung für die Subdomänen – die Unterverzeichnisse in der Dateisystem-Analogie – gibt er an Kollegen ab. Falls die Rechnergruppe auf der untersten Ebene des Baums immer noch zu groß erscheint, kann sie unter mehrere Nameserver aufgeteilt werden. Deren Verantwortungsbereich bezeichnet man in diesem Fall als Zonen. Die Gegenspieler der Nameserver sind die Clients, die in diesem Zusammenhang auch als Resolver bezeichnet werden. Interessiert sich ein Client für die Adresse zu einem Namen, wendet er sich an den Nameserver seiner Domäne. Findet der die Antwort weder in seiner Datenbank noch in seinem Cache, befragt er den Kollegen, der aus seiner Perspektive dem Ziel am nächsten liegt, oder gibt zumindest dessen Adresse an den Client weiter. So wandert die Anfrage zielgerichtet durch die Domänen-Hierarchie bis sie einen Nameserver erreicht, der die Antwort in seinem Cache oder seiner Adressliste findet und den Client oder einen fragenden Nameserverkollegen zufrieden stellen kann. (Jens-Christoph Brendel)

Quellenangaben

Die Einträge im Beispiel führen dazu, dass der Resolver zunächst in »/etc/hosts« nachsieht, ob er dort den gesuchten Namen beziehungsweise die gesuchte Adresse findet. Nur wenn die Suche ergebnislos bleibt, wird als Nächster der DNS-Dienst benutzt, wie er in »/etc/resolv.conf« konfiguriert ist. »host.conf« entstammt noch der Zeit vor Glibc 2.x, entspricht also Libc.so.5 und früher. Neuere Versionen der Glibc haben den Name Service Switch von Solaris 2 übernommen und erlauben eine flexible Konfiguration beliebiger Lookup-Dienste in freier Reihenfolge.

Der Name Service Switch wird über die »/etc/nsswitch.conf« konfiguriert (Listing 3). Die Datei enthält eine Auflistung von Diensten und Datenquellen sowie jeweils eine Beschreibung des gewünschten Vorgehens. Für die Auflösung von Hostnamen ist der Dienst »hosts« relevant, wobei die hier vorgegebene Strategie »files dns« der Voreinstellung entspricht. Damit ist festgelegt, dass der Resolver zunächst in der Datei »/etc/hosts« nachschlägt und erst anschließend eine Anfrage ans DNS stellt.

Es gibt noch weitere Konfigurationsdateien. Sendmail ist beispielsweise eines der Programme mit eigener Resolver-Bibliothek. Der Admin konfiguriert sie ähnlich, aber nicht identisch zum Service Switch von Glibc. Die zugehörige private Konfigurationsdatei heißt »/etc/mail/service.switch«. Sie kümmert sich nur um die Dienste »passwd«, »hosts« und »aliases«, wobei für Sendmail kein Doppelpunkt nach dem Dienstnamen steht. Sonst funktioniert »/etc/mail/service.switch« ganz analog zu »/etc/nsswitch.conf«.

In bestimmten Fällen sind Anfragen übers Netzwerk unerwünscht. Wenn beispielsweise die Einwahl über Modem oder DSL mit Zeittarif erfolgt, spart es bares Geld, unnötige DNS-Abfragen zu vermeiden. Auch aus Sicherheitsgründen können Netzwerkkontakte nicht erwünscht sein.

01 127.0.0.1       localhost.localdomain localhost ishi
02 
03 # The following lines are desirable for IPv6 capable hosts
04 ::1             localhost.localdomain localhost ip6-localhost ip6-loopback
05 fe00::0         ip6-localnet
06 ff00::0         ip6-mcastprefix
07 ff02::1         ip6-allnodes
08 ff02::2         ip6-allrouters
09 ff02::3         ip6-allhosts
10 
11 172.16.45.1     natrouter
12 216.92.94.3     sedacon.pair.com

01 nameserver 172.16.45.2
02 nameserver 172.16.45.3
03 options rotate

01 passwd:         compat
02 group:          compat
03 shadow:         compat
04 
05 hosts:          files dns
06 networks:       files

Ohne Netz

Löscht der Admin »bind« aus »/etc/host.conf« und »dns« aus »/etc/nsswitch.conf«, unterbindet er die Netzwerkzugriffe des Glibc-Resolvers. Ein Nameserver im LAN ließe sich dann allerdings auch nicht mehr erreichen.

Sollen vertrauliche Arbeiten durch einen Tunnel – etwa ein VPN -, so müssen DNS-Abfragen vermieden oder ebenfalls über den Tunnel geleitet werden. Hier reicht es oft aus, den Empfang und Versand von E-Mail über IP-Adressen zu konfigurieren oder die entsprechenden Domainnamen einfach in »/etc/hosts« aufzunehmen. Es bleibt dann nur der Browser als häufigste Quelle von DNS-Anfragen.

Ein Socks-4a-Proxy wie beispielsweise Privoxy leistet dann gute Dienste, weil er den DNS-Lookup auf die andere Tunnelseite umzulenken vermag. Wenn keine DNS-Abfragen ins Internet erwünscht sind, ist es angesichts der Vielfalt der verwendeten Resolver am sichersten, durch zusätzliche Firewall-Regeln solche DNS-Abfragen zu unterbinden.

Im Gleichschritt

Auf die sinngemäße Übereinstimmung der einzelnen Konfigurationsdateien muss der Admin selber achten. Wenn beispielsweise »host.conf« nur auf »/etc/hosts« verweist, »nsswitch.conf« aber auch das DNS referenziert, hätten ältere Programme mit eigenem Resolver sowie alte statisch übersetzte Programme Probleme damit, einzelne Adressen zu finden. Modernere Software funktioniert dagegen anstandslos. Fehlt »nsswitch.conf«, verwendet die Glibc übrigens Defaultwerte für die Abfragereihenfolge der Datenquellen.

Abbildung 2: So funktioniert die Namensauflösung in einem Beispiel: 1 Der Resolver-Client richtet sich mit der Anfrage nach einer Adresse an den Nameserver A, der jedoch für die betroffene Domäne weder zuständig ist noch das Ergebnis gecacht hat. Trotzdem übernimmt er die weiteren Schritte (rekursive Abfrage) und wendet sich an Nameserver B 2, der seinerseits mit einem Verweis auf den Server-Kollegen C antwortet 3. A befragt C 4, der verweist auf D 5. Eine Anfrage dort 6 ergibt schließlich die gesuchte Adresse 7 , die Nameserver A nun an den Client zurückgebe

Unterschiede im Detail

Alle hier gezeigten Mechanismen sind mehr oder weniger implementationsspezifisch. Zwar enthält grundsätzlich jedes Unix Resolver der hier vorgesellten Art, die Details der Implementierung unterscheiden sich aber: Beispielsweise benutzt BSD ein anderes Format für »host.conf«, die Servicenamen in »nsswitch.conf« unterscheiden sich von Unix zu Unix und Solaris enthält mit »/etc/netconfig« eine Methode, den Service Switch durch eine private Bibliothek zu ersetzen. (jcb)