Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG 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.

Wie DNS funktioniert

DNS verwaltet Hostnamen in einer Domain-Hierarchie. Eine Domain ist eine Ansammlung von Sites, die in einer bestimmten Beziehung zueinander stehen, sei es, weil sie ein gemeinsames Netzwerk bilden (z.B. alle Maschinen auf einem Universitätsgelände oder alle Hosts im BITNET), weil sie alle einer bestimmten Organisation angehören (z.B. der US-Regierung) oder weil sie einfach nur geographisch dicht beieinander liegen. So sind beispielsweise amerikanische Universitäten gewöhnlich in der Domain edu zusammengefaßt, wobei jede Uni ihre eigene Subdomain hat, die alle ihre Hosts umfaßt. So hat die Groucho-Marx-Universität die Domain groucho.edu, in der das LAN des mathematischen Instituts die Subdomain maths.groucho.edu besitzt. Diese werden an die Namen aller Rechner dieses Institutsnetzwerkes angehängt, so daß z.B. erdos den voll qualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) erdos.maths. groucho.edu hat. Jeder FQDN ist weltweit eindeutig.

Abbildung 6.1 zeigt einen Ausschnitt des Namensraums. Der Eintrag an der Wurzel des Baums, der durch einen Punkt gekennzeichnet ist, wird dementsprechend als Root-Domain bezeichnet und umfaßt alle anderen Domains. Um zu verdeutlichen, daß ein Hostname ein voll qualifizierter Domainname ist und nicht etwa relativ zu einer (impliziten) lokalen Domain, wird er manchmal mit einem abschließenden Punkt geschrieben. Dieser Punkt zeigt an, daß die letzte Komponente des Namens die Root-Domain ist.

Abbildung 6.1: Ein Ausschnitt des Domain-Namensraums

Je nach ihrer Position in der Namenshierarchie wird eine Domain als Top-Level, Second-Level oder Third-Level bezeichnet. Es gibt noch weitergehende Unterteilungen, sie kommen aber selten vor. Die folgende Liste enthält diverse Top-Level-Domains, die Ihnen öfters begegnen:

Aus historischen Gründen wurden die ersten vier Domains der USA zugeordnet. Änderungen in der Politik führten dazu, daß diese globalen Top-Level-Domains (gTLD) nun von aller Welt genutzt werden können. Zur Zeit laufen Verhandlungen über die Einführung weiterer globaler Top-Level-Domains, die die Auswahlmöglichkeiten an Domainnamen deutlich erhöhen würden.

Außerhalb der USA benutzt jedes Land eine Top-Level-Domain aus zwei Buchstaben, die nach dem Landesnamen benannt und in ISO-3166 beschrieben sind. So nutzt z.B. Finnland die Domain fi, Frankreich fr, Deutschland de und Australien au. Unterhalb dieser Top-Level-Domains kann das NIC jedes Landes die Hostnamen nach Belieben organisieren. Australiens Second-Level-Domains sind denen der internationalen Top-Level-Domains sehr ähnlich, z.B. com.au und edu.au. Andere Länder wie Deutschland benutzen diesen Extra-Level nicht, sondern verwenden dafür ziemlich lange Namen, die direkt auf die Organisation hinweisen, die diese Domains besitzen. So sind z.B. Namen wie ftp.informatik.uni-erlangen.de durchaus gängig. Nennen Sie das deutsche Gründlichkeit, wenn Sie so wollen.

Natürlich bedeuten diese nationalen Domains nicht, daß ein Host innerhalb dieser Domain im zugehörigen Land stationiert ist. Es bedeutet einfach nur, daß die Domain vom NIC des zugehörigen Landes registriert wurde. Zum Beispiel kann ein schwedischer Hersteller eine Filiale in Australien haben, deren Domain mit der Top-Level-Domain se endet.

Die hierarchische Aufteilung des Namensraumes in Domänen löst auf elegante Weise das Problem der Eindeutigkeit von Namen. Mit DNS muß ein Hostname nur innerhalb seiner eigenen Domain eindeutig benannt sein; er ist damit weltweit eindeutig identifiziert. Außerdem lassen sich voll qualifizierte Namen leicht merken. Allein das sind schon sehr gute Gründe dafür, eine große Domänen in mehrere Sub-Domänen aufzuteilen.

DNS kann aber noch viel mehr für Sie tun. Es ermöglicht Ihnen auch, die Verantwortung über eine Subdomain an ihre Administratoren zu delegieren. Beispielsweise könnten die Verwalter des Groucho-Rechenzentrums für jede Abteilung eine Subdomain erzeugen; den Subdomains math und physics sind wir bereits oben begegnet. Wenn sie nun der Auffassung wären, das Netzwerk im Physik-Institut wäre zu groß und chaotisch, um von außerhalb verwaltet werden zu können (schließlich sind Physiker bekanntlich ja besonders widerspenstige Typen), könnten sie die Kontrolle der Domain physics. ­groucho.edu an die Administratoren dieses Netzes abgeben. Diese Administratoren könnten dann innerhalb dieser Domain nach Belieben Hostnamen und IP-Adressen aus ihrem Netzwerk vergeben, ohne sich dabei mit Außenstehenden absprechen zu müssen.

Aus diesem Grund wird der Namensraum immer in einzelne Zonen aufgeteilt, deren Wurzel jeweils eine Domäne ist. Man beachte den feinen Unterschied zwischen einer Zone und einer Domain: Die Domain groucho.edu umfaßt alle Hosts an der Groucho-Marx-Universität, während die Zone groucho.edu nur die Hosts enthält, die direkt vom Rechenzentrum verwaltet werden, z.B. die im Mathematik-Institut. Die Hosts im Physik-Institut gehören dagegen einer anderen Zone an, nämlich physics.groucho.edu. In Abbildung 6.1 ist der Anfang einer Zone mit einem kleinen Kreis rechts neben dem Domainnamen markiert.

Ermittlung von Namen mit DNS

Auf den ersten Blick scheint der ganze Domain- und Zonenkram die Namensauflösung zu einer unnötig komplizierten Angelegenheit zu machen. Schließlich stellt sich ja die Frage: Woher soll eine schlichte Anwendung wissen, welche Namen zu welchen Hosts gehören, wenn es keine zentrale Autorität gibt, die diese Zuordnungen kontrolliert?

Jetzt kommt der wirklich geniale Teil von DNS. Wenn Sie herausfinden wollen, welche IP-Adresse zu erdos gehört, erhalten Sie von DNS die lapidare Antwort: “Fragen Sie diejenigen, die für dessen Verwaltung zuständig sind, die können es Ihnen sagen!”

Tatsächlich ist DNS eine gigantische verteilte Datenbank. Implementiert ist sie mittels sogenannter Name-Server, die Informationen über eine gegebene Domain oder eine ganze Reihe von Domains bereitstellen. Für jede Zone existieren mindestens zwei (bzw. höchstens einige wenige) Name-Server, die alle maßgeblichen Informationen über Hosts in dieser Zone halten. Um die IP-Adresse von erdos zu bekommen, ist dafür lediglich der Name-Server für die Zone groucho.edu zu kontaktieren, der dann die gewünschte Information liefert.

Leichter gesagt als getan, werden Sie jetzt vielleicht denken. Woher soll ich denn wissen, wie ich den Name-Server an der Groucho-Marx-Universität erreiche? Keine Sorge, auch wenn Ihr Computer nicht gerade mit einem adreßauflösenden Orakel ausgestattet ist, hilft Ihnen DNS auch in diesem Punkt aus der Patsche. Wenn Ihre Applikation Informationen über erdos haben möchte, setzt sie sich zunächst mit einem lokalen Name-Server in Verbindung, der dafür eine sogenannte iterative Anfrage startet. Zunächst sendet er eine Anfrage an einen Name-Server für die Root-Domain, in der er nach der Adresse von erdos.maths.groucho.edu fragt. Der angesprochene Root-Name-Server erkennt, daß dieser Name nicht zu den von ihm autorisierten Zonen gehört, dafür aber zu einer unterhalb der Domain edu liegenden Zone. Folglich gibt er Ihrem Name-Server die Empfehlung, sich an einen Name-Server zu wenden, der für die Zone edu zuständig ist, und präsentiert ihm dafür eine Liste aller edu-Name-Server samt ihrer Adressen. Ihr lokaler Name-Server setzt daraufhin seine Arbeit fort und fragt einen der in der Liste enthaltenen Server, z.B. a.isi.edu. Dieser verfährt ähnlich wie der Root-Name-Server; er weiß, daß die Leute von groucho.edu ihre eigene Zone verwalten, und verweist Sie daher an deren Server. Schließlich befragt Ihr lokaler Name-Server einen dieser Server nach erdos und erhält endlich die sehnlichst erwünschte Antwort, da dieser Name zur Zone des befragten Servers gehört und dieser die zugehörige IP-Adresse zurückliefern kann.

Das Ganze erweckt den Eindruck, daß ziemlich viel Datenverkehr in Gang gesetzt werden muß, nur um so eine klitzekleine IP-Adresse herauszufinden. In Wirklichkeit macht dies aber nur einen winzigen Bruchteil dessen aus, was sonst über die Leitungen fließen würde, wenn wir immer noch mit HOSTS.TXT arbeiten müßten. Daß es hierbei immer noch Möglichkeiten zur Optimierung gibt, versteht sich natürlich von selbst.

Um die Antwortzeiten für zukünftige Anfragen zu verringern, speichert Ihr Name-Server die ermittelten Informationen in seinem lokalen Speicher (Cache). Wenn das nächste Mal jemand in Ihrem lokalen Netz eine Hostadresse der Domain groucho.edu benötigt, schaut Ihr Name-Server in seinem Cache nach und leitet die Anfrage ohne weitere Nachforschungen sofort an den Name-Server der groucho.edu-Domain weiter.¹

Natürlich behält der Name-Server diese Informationen nicht für immer und ewig; er löscht sie nach einer gewissen Zeit. Diese Zeit bis zur Löschung wird Lebensdauer (Time To Live, TTL) genannt. Der Administrator der betroffenen Zone teilt jedem Datensatz in der DNS-Datenbank eine solche TTL zu.

Typen von Name-Servern

Name-Server, die sämtliche Informationen über die Hosts einer Zone verwalten, sind für diese Zone verantwortlich (authoritative) und werden manchmal auch als Master-Name-Server bezeichnet. Jede Anfrage über einen Host in dieser Zone endet schließlich bei einem solchen Master-Name-Server.

Master-Name-Server müssen immer ziemlich gut synchronisiert werden. Daher macht der Netzwerkadministrator einer Zone einen der Master-Server zum primären Server und die anderen zu sekundären Servern. Der primäre Server lädt alle seine Zonen-Informationen aus Datendateien; die sekundären Server kopieren diese Informationen in regelmäßigen Abständen vom Master-Server.

Wenn man mehrere Name-Server zur Verfügung hat, kann das Arbeitspensum auf sie verteilt werden; außerdem bieten sie die Möglichkeit zur redundanten Datenhaltung. Fällt einer der Name-Server mal aus, z.B. durch Crash oder Verlust der Netzwerkverbindung, werden alle Anfragen an diesen Server an die anderen weitergeleitet. Allerdings schützt Sie dieses Verfahren nicht vor Fehlfunktionen der Server, die sich in falschen DNS-Antworten bemerkbar machen. Ursachen solcher Fehler können Bugs in der Serversoftware sein.

Sie können auch einen Name-Server betreiben, der für gar keine Domäne verantwortlich ist.² Das ist durchaus nützlich, da der Name-Server weiterhin DNS-Antworten für die Applikationen im lokalen Netzwerk cachen kann. Ein solcher Server wird daher als Caching-only-Server bezeichnet.

Die DNS-Datenbank

Wir haben gesehen, daß DNS nicht nur mit IP-Adressen von Hosts arbeitet, sondern auch Informationen über Name-Server austauscht. DNS-Datenbanken können in der Tat viele verschiedene Arten von Einträgen aufweisen.

Jede Einzelinformation in einer DNS-Datenbank wird als Resource-Record (RR) bezeichnet. Jeder Record enthält einen Typ, der Auskunft über die Art der Information liefert, sowie eine Klasse, die Auskunft über den Netzwerktyp gibt, für den die Information bestimmt ist. Die Klassen werden für die verschiedenen Adreß-Schemata benötigt, wie IP-Adressen (die IN-Klasse), Hesiod-Adressen (von MITs Kerberos-System benutzt) und einige mehr. Der Prototyp eines solchen Resource-Record-Typs ist der A-Record; er assoziiert einen voll qualifizierten Domainnamen mit einer IP-Adresse.

Ein Host kann unter mehreren Namen bekannt sein. Zum Beispiel könnten Sie einen Server besitzen, der sowohl FTP- als auch WWW-Dienste anbietet und unter den Namen ftp.machine.org und www.machine.org erreichbar ist. Einer dieser Namen muß als offizieller bzw. kanonischer Hostname eingetragen sein; die anderen Namen sind einfach nur Aliasnamen, die auf den offiziellen Hostnamen verweisen. Der Unterschied liegt darin, daß ein kanonischer Hostname immer mit einem A-Record assoziiert ist, während die Aliasnamen einen Record vom Typ CNAME besitzen, der auf den kanonischen Hostnamen zeigt.

Wir werden hier nicht alle Record-Typen behandeln, stellen dafür aber ein kurzes Beispiel vor. Tabelle 6.4 zeigt einen Ausschnitt der Domain-Datenbank, die in die Name-Server für die Zone physics.groucho.edu geladen wird.

Beispiel 6.4: Auszug aus der Datei named.hosts für das physikalische Institut

; Autoritative Informationen über physics.groucho.edu. @  IN  SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {                   1999090200       ; serial no                   360000           ; refresh                   3600             ; retry                   3600000          ; expire                   3600             ; default ttl                 } ; ; Name-Server               IN    NS       niels               IN    NS       gauss.maths.groucho.edu. gauss.maths.groucho.edu. IN A 149.76.4.23 ; ; Theoretische Physik (Subnetz 12) niels         IN    A        149.76.12.1               IN    A        149.76.1.12 nameserver    IN    CNAME    niels otto          IN    A        149.76.12.2 quark         IN    A        149.76.12.4 down          IN    A        149.76.12.5 strange       IN    A        149.76.12.6 ... ; Teilchenbeschleuniger-Labor (Subnetz 14) boson         IN    A        149.76.14.1 muon          IN    A        149.76.14.7 bogon         IN    A        149.76.14.12 ...

Außer den A- und CNAME-Records sehen Sie am Anfang der Datei einen speziellen Record, der sich über mehrere Zeilen erstreckt. Das ist der SOA-Resource-Record (Start of Authority); er enthält allgemeine Informationen über die Zone, für die der Server zuständig ist, so zum Beispiel über die Lebensdauer aller Records.

Beachten Sie, daß alle Namen in der Beispieldatei, die nicht mit einem Punkt enden, als relativ zur Domain physics.groucho.edu aufzufassen sind. Der spezielle Name (@) im SOA-Record verweist auf den Domainnamen an sich.

Wir haben bereits früher gesehen, daß die Name-Server für die Domain groucho.edu irgend etwas über die Zone physics wissen müssen, um Anfragen an deren Name-Server stellen zu können. Diese Informationen stellt üblicherweise ein Paar von Records bereit, bestehend aus dem NS-Record, der den FQDN des Servers ergibt, und einem A-Record, der eine IP-Adresse mit dem Namen assoziiert. Da diese Records sozusagen der “Kleber” sind, der den Namensraum zusammenhält, werden sie oft als glue records bezeichnet. Sie sind die einzigen Arten von Records, in denen eine Oberzone tatsächlich Informationen über Hosts der untergeordneten Zonen enthält. Die Glue Records, die auf die Name-Server für physics.groucho.edu verweisen, zeigt Tabelle 6.5.

Beispiel 6.5: Auszug aus der Datei named.hosts für GMU

 ; Zonendaten für die Zone groucho.edu  @  IN  SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {                       1999070100       ; serial no                       360000           ; refresh                       3600             ; retry                       3600000          ; expire                       3600             ; default ttl                }  ....  ;  ; Glue Records für die Zone physics.groucho.edu  physics        IN     NS        niels.physics.groucho.edu.                 IN     NS        gauss.maths.groucho.edu.  niels.physics  IN     A         149.76.12.1  gauss.maths    IN     A         149.76.4.23  ...

Reverse Lookups

Die Ermittlung der IP-Adressen von Hosts ist sicherlich die häufigste Anwendung des Domain Name Systems. Manchmal möchten Sie jedoch den umgekehrten Weg gehen und den kanonischen Hostnamen zu einer gegebenen IP-Adresse wissen. Ein solches Verfahren wird Reverse Mapping genannt und von vielen Netzwerkdiensten dazu verwendet, die Identität eines Clients zu überprüfen. Bei Verwendung einer einzelnen hosts-Datei gestaltet sich die Sache recht einfach; für Reverse Lookups muß die Datei nur nach der zum Hostnamen eingetragenen IP-Adresse durchsucht werden. Bei DNS kommt eine erschöpfende Suche im gesamten Namensraum natürlich nicht in Frage. Für diesen Zweck wurde die spezielle Domain in-addr.arpa eingerichtet. Sie enthält die IP-Adressen sämtlicher Hosts in umgekehrter Dotted Quad Notation. Zum Beispiel hat sie für die IP-Adresse 149.76.12.4 einen Eintrag, der 4.12.76.149.in-addr.arpa lautet. Der Resource-Record-Typ, der diese Namen mit ihren kanonischen Hostnamen verbindet, wird PTR genannt.

Eine autoritative Zone zu erzeugen bedeutet, daß ihre Administratoren volle Kontrolle darüber besitzen, wie sie Adressen und Namen zuordnen. Da sie für gewöhnlich ein oder mehrere IP-Netzwerke oder -Subnetze verwalten, existiert eine 1-zu-n-Beziehung zwischen DNS-Zonen und IP-Netzwerken. Das physikalische Institut zum Beispiel umfaßt die Subnetze 149.76.8.0, 149.76.12.0 und 149.76.14.0.

Daher müssen zusätzlich zur physics-Zone auch neue Einträge in der in-addr.arpa-Domäne erzeugt und an die Netzwerkadministratoren des Instituts delegiert werden: 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa und 14.76.149.in-addr.arpa. Ansonsten müßten sie für die Installation eines neuen Hosts im Collider Lab die Oberdomain bitten, die neue Adresse in ihre in-addr.arpa-Zonendatei einzutragen.

Die Zonen-Datenbank für das Subnetz 12 wird in Tabelle 6.6 gezeigt. Die zugehörigen Glue Records in der Datenbank ihrer Oberzone werden in Tabelle 6.7 gezeigt.

Beispiel 6.6: Auszug aus der Datei named.rev für Subnetz 12

 ; die Domain 12.76.149.in-addr.arpa  @  IN  SOA  niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {                       1999090200 360000 3600 3600000 3600             }  2        IN     PTR       otto.physics.groucho.edu.  4        IN     PTR       quark.physics.groucho.edu.  5        IN     PTR       down.physics.groucho.edu.  6        IN     PTR       strange.physics.groucho.edu.

Beispiel 6.7: Auszug aus der Datei named.rev für Netzwerk 149.76

 ; die Domain 76.149.in-addr.arpa  @  IN  SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {                       1999070100 360000 3600 3600000 3600                   }  ...  ; Subnetz 4: Mathematik-Institut  1.4        IN     PTR      sophus.maths.groucho.edu.  17.4       IN     PTR      erdos.maths.groucho.edu.  23.4       IN     PTR      gauss.maths.groucho.edu.  ...  ; Subnetz 12: Physik-Institut, separate Zone  12         IN     NS       niels.physics.groucho.edu.             IN     NS       gauss.maths.groucho.edu.  niels.physics.groucho.edu. IN  A 149.76.12.1  gauss.maths.groucho.edu. IN  A   149.76.4.23  ...

in-addr.arpa-Systemzonen können nur als Obermengen von IP-Netzwerken erzeugt werden. Eine noch schwerwiegendere Einschränkung ist die Bedingung, daß die Netzmasken dieser Netzwerke immer an Bytegrenzen liegen müssen. Alle Subnetze der Groucho-Marx-Universität haben eine Netzmaske von 255.255.255.0, so daß für jedes Subnetz eine in-addr.arpa-Zone erzeugt werden kann. Bei einer Netzmaske von 255.255.255.128 wäre jedoch die Erzeugung von Zonen für das Subnetz 149.76. 12.128 unmöglich, da es nun aber keine Möglichkeit gibt, DNS mitzuteilen, daß die Domain 12.76.149.in-addr.arpa in zwei Autoritätszonen aufgeteilt wurde, mit Hostnamen von 1 bis 127 sowie von 128 bis 255.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

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