![[Top Bar]](../../common/images/Topbar-en.gif){kind=small}
![[Bottom Bar]](../../common/images/Bottombar-en.gif){kind=small}
Zusammenfassung:
Dieser Artikel richtet sich an all
jene, die sich für weltweite Netzwerke wie dem Internet und dem
World Wide Web (WWW) interessieren. Vor allem aber an solche die
etwas mehr über die unsichtbaren Abläufe erfahren wollen.
Sollten Sie sich bereits desöfteren gefragt haben welche
Prozesse hinter Ihrem Browser ablaufen, nachdem Sie die Adresse
eines Servers gesetzt haben, können Ihnen die folgenden
Ausfuehrungen auf einfache Weise Aufschluß darüber geben.
Dieser Artikel erschien zuerst im
Linux Magazine.
Abgedruckt mit der Erlaubnis des Authors.
Der Artikel in fünf Teile untergliedert:
Der Erste beschreibt
in wenigen Worten wie sich das Internet entwickelte. Der Zweite soll
einige Grundsätzliche Begriffe erkären. Der Dritte beschäftigt sich mit
den wichtigsten Protokollen des Internet: Dem TCP und dem IP. Der Vierte
soll helfen die Funktionsweise des DNS zu verstehen. Im Fünften Teil wird
an einem Beispiel die Installation eines Domain Name Systems unter Linux
für ein kleines LAN mit Gateway erklärt. Auf diese Weise soll dieses
Dokument sowohl eine Einführung für Interessierte sein, als auch eine
Kurzreferenz für Fortgeschrittene.
(1)Das ARPANET, der Ursprung des World Wide Web
Als "Internet" werden alle weltweit miteinander verknüpften Netzwerke bezeichnet, welche sich aus dem ARPANET entwickelten. Das ARPANET entstand im Jahre 1969 durch ein Forschungsprojekt der amerikanischen DARPA (Defense Advance Research Project Agency). Als das ARPANET aus dem Experimentalstadium entwuchs, entwickelten sich die Grundprotokolle des TCP/IP, welche alsbald zum Militärstandard ernannt wurden. Um den partizipierenden Instititionen,welche sich an die neuen Protokolle anpassen mussten, diese Änderungen zu erleichtern, wurde die Firma Bolt, Barnek & Newman (BBN) beauftragt das TCP/IP in das System Berkeley-Unix zu integrieren. So enstand die Fusion zwischen dem Betriebssystem UNIX und den Protokollen TCP/IP.
Im Jahre 1983 wurde das ARPANET aufgeteilt in das MILNET als Teil des Defense Data Network (DDN) und einem kleineren Arpanet. Diese beiden Netze nannten sich alsdann INTERNET. Bis zum Jahr 1990 verschwand das ARPANET und wurde komplett durch das Internet abgelöst, welches eine Vielzahl an Netzwerken in der ganzen Welt umfasst.
(2) Ein paar technische Ausdrücke zum Verständnis
Stellen sie sich vor, sie sitzen vor einem Computer del Teil des Local Area Networks (LAN) des Mathematikinstituts Ihrer Universität ist (Abb. 1).
Das LAN des Mathematikinstituts ist über einen backbone (= Rückgard: ich würde es mal Hauptdatenleitung bezeichnen) mit dem LAN des Physikinstituts verbunden. Sie beabsichtigen nun einem Freund, welcher im Physikinstitut arbeitet, Daten zu schicken. Es ist grundsätzlich sehr wichtig zu wissen, daß ihr Computer wie auch der Rechner ihres Freundes unverwechselbare Namen im Netz der gesamten Universität besitzen (gleichermassen verhält es sich bei allen an das Internet angeschlossenen Computer). Damit die beiden physisch voneinder getrennten Netze miteinander kommunizieren können, benötigen sie einen Gateway. Ein Gateway ist ein Rechner, der physisch unabhängige Netze miteinader verbindet. In diesem Falle benötigen wir zwei Gateways - eines für das Netz der Mathematiker und eines für die Physiker. Desweiteren nenne ich den Gatway des Mathematikinstituts "mats" und den Gate für das Physiker-LAN "phys".
Abbildung 1: Der Weg der Daten von Einstein nach Edison
Da die auf Einstein installierte Software (rlogin, telnet, ftp, etc.) Datenpakete nicht direkt an Edison senden kann - der Rechner befindet sich schliesslich in einem physisch getrennten Netz - wird ein Gateway benötigt um die Daten oder besser Datenpakete an die entsprechende Stelle zu leiten. Dies bedeutet nun, daß der Gateway "mats" die Datenpakete an den Gateway "phys" leitet, welcher wiederum die Zuteilung der Daten an Edison übernimmt. Dieses Schema des Datentransfers an einen entfernten Computer (host) wird Routing genannt und die Daten bzw. einzelnen Datenpakete bezeichnet man als Datagramme (engl: datagram).
Die Datagramme als kleinste Einheit der Datenübertragung werden über ein Protokoll ausgetauscht - dem Internet Protocol (das IP), welches absolut hardwareunabhängig ist. Auf diesem Wege kommen wir zu dem Hauptvorteil des Internet Protocols, welcher darin besteht, physisch getrennte Netze zu einem scheinbar homogenen zu vereinen.
Die Hauptfunktionen des IP:
Bedauerlicherweise fehlen dem IP Kontrollinformationen der Datenübertragung (handshake), was soviel bedeutet, daß das IP zwar Pakete von einem Ort zum anderen befördert, jedoch ohne Kontrolle darüber ob alle Pakete in der richtigen Reihenfolge angekommen sind. Dieses Problem behandeln wir etwas später.
Nun haben wir eine gewisse Vorstellung über den Softwareteil der Datenübertragung (Routing). Sie erinnern sich, daß sie vor einem Computer namens Einstein sitzen. Rechner in Netzwerken erhalten Namen da sie für den Menschen leichter zu merken sind als Sequenzen von Zahlen.
Das Internetprotokoll besitzt ein hardwareunabhängiges Adressschema. Dies wird erreicht durch die Zuordnung einer 32 bit-langen Zahl zu einem Hostrechner; die IP-Adresse (die IP). Die IP-Adresse wird durch vier Dezimalzahlen (Oktette) dargestellt, welche durch Punkte getrennt sind. Einstein könnte die Hardwareadresse 0x952C0C02 haben, welche dann beispielsweise in der Form 149.176.12.7 erschiene.
An dieser Stelle haben sie erkannt, daß wir über drei verschiedene Adressierungen verfügen:
Die Adresse der Ethernetkarte belegt einen Port im Betriebssystem, welcher unter LinuX üblicherweise eth0-n ist. Serielle Ports beispielsweise werden unter cua0-n oder ttyS0-n spezifiziert. Um ganz genau zu sein, ist unrichtig zu sagen, daß ein Computer oder host einen Namen wie Einstein besitzt, da sich letztendlich die Adressierung auf das entsprechende Hardwareinterface bezieht!
Sie wissen jetzt, daß das Internetprotokoll (das IP) Daten in Form von mehreren Datagrammen zwischen Rechnern überträgt. Datagramme werden an die Adresse ins Internet oder ein anderes LAN geschickt, welche in der Kopfzeile eines jeden Datagrams steht. Die Adresse des Empfängers ist eine 32 bit-lange Standardadresse (die IP), welche ausreichende Information enthält um einen Computer in einem entfernten Netz unverwechselbar zu identifizieren.
Eine IP-Adresse besteht aus zwei Teilen:
Abhängig von der Größe des Netzwerkes resultiert die Anzahl der Hostadressen. Um diese unterschiedlichen Anforderungen zu erfüllen, wurde mehrere Netzwerkklassen gebildet, welche die Unterteilung der IP-Adressen definieren.
| Klasse A: | umfasst die Netze 1.0.0.0 bis 127.0.0.0 . Die Ziffer dieses Netztyps befindet sich im ersten Oktett. Auf diese Weise stehen 24 bits zur Definition von Rechnern zur Verfügung, was für ca 1,6 Millonen host ausreicht. | |
| Klasse B: | umfasst die Netze128.0.0.0 bis 191.255.0.0 . Die Ziffer dieses Netztyps befindet sich in den beiden ersten Oktetten. Dies emöglicht 16.320 Netze mit je 65.024 Rechnern. | |
| Klasse C: | umfasst die Netze192.0.0.0 bis 223.255.255.0 . Die Ziffer dieses Netztyps befindet sich in den ersten drei Oktetten. Dies ermöglicht fast 2 Millionen Netzte mit 254 hosts. | |
| Klasse D, E & F: | Adressen, die sich im Berich 224.0.0.0 bis 225.0.0.0 befinden, dienen experimentellen Zwecken oder sind reserviert für zukünftigen Gebrauch. Jedenfalls definieren sie keine Netzwerke. |
Um zu unserem Beispiel zurückzukehren, können
sie sehen, daß Einstein mit der IP 149.176.12.7 einem Netz der
Klasse B: 149.176.0.0 angehört und einen Rechner mit der Adresse
12.7 definiert.
Es ist desweiteren sehr wichtig zu wissen, daß die Adresse eines
Rechners weder 0 noch 225 sein darf, da diese für spezielle
Zwecke reserviert sind. Eine Rechneradresse die nur aus Nullen
besteht (149.176.0.0) definiert ja lediglich das Netz selbst.
Wenn die Hostadresse ledglich mit den Ziffern 255 beschrieben ist
(149.176.255.255) spricht man von der Broadcast-Adresse (Radio),
da Daten die an diese Adresse gesandt werden, an alle Rechner
dieses Netzes gerichtet sind.
Darüberhinaus existieren zwei weitere
reservierte Adressen: 0.0.0.0, welche als default
route bezeichnet wird und 127.0.0.0 als
loopback-Adresse. Die default route-Adresse hat
mit einem speziellen Fall von Routing durch ein Gateway zu tun
und soll uns hier nicht weiter beschäftigen. (Thema:
Masquerading)
Weitaus wichtiger ist das "Netz" 127.0.0.0, welches
füer den Teil des IP-Verkehrs reserviert ist, der nur im Rechner
selbst abläuft. Die IP 127.0.0.1 ist gewöhnlich an ein
Interface im Rechner selbst gerichtet, welches auch loopback-Interface
genannt wird und wie ein geschlossener Kreis funktioniert. Jedes
an diese Adresse gesandte Paket wird sofort zurückgegeben. Auf
diese Weise dient das loopback um Netzsoftware zu testen ohne ein
echtes Netz installiert zu haben. "Ping localhost" oder
"ping 127.0.0.1" ist ein geläufiger Test um zu
überprüfen ob TCP/IP richtig konfiguriert ist.
Die IP-Adresse, die sie schliesslich ihrem Rechner oder Netz zuweisen können, wird von einer zentralen Institution namens NIC (Network Information Center) entschieden. Die einfachste Lösung ist, ihren Provider mit der Reservierung der Adresse zu beauftragen. Wenn sie sicher sind, daß ihr Netz niemals ans Internet angeschlossen wird, können sie eigentlich jedwede IP wählen. Um allerdings ganz sicher zu sein daß kein Paket ins Internet entkommt, ist es angebracht IPs zu wählen, die nur innerhalb Ihres Netzes funktionieren und nicht im Internet geroutet werden können.
Diese Adressen sind:
Ungeachtet dessen ist es noch möglich einen Gateway für das Internet zu konfigurieren, was bedeutet, daß die externe Adresse des Gates im Internet bekannt ist, die Rechner innerhalb Ihres Netzes aber nicht angefahren werden können, da Ihre IPs im Internet nicht gehandelt werden. Die Rechner ihres Netzes hätten allerdings Zutritt zum WWW (nochmal Stichwort: IP-Masquerading).
(3.2) Das TCP(Transmission Control Protocol)
Wie weiter oben bereits erwähnt, verfügt das Internet Protocol über keine Übertragungskontrollfunktion. Dem nimmt sich das Transmission Control Protocol (TCP) an. Das TCP wird als zuverlässiges, verbindungsorientiertes Datenstrom (bytestream)-Protokoll bezeichnet.
Aus diesem Grunde kontrolliert das TCP die richtige Reihenfolge der Datenpakete.
(4) Das Domain Name System (DNS)
(4.1) Ein Überblick des Systems
Das Domain Name System ist grundsätzlich eine weiträumig verteilte Datenbank über Namen von Hostrechnern die an einem Netz angeschlossen sind. Dies ermöglicht eine lokale Kontrolle der Gesamtheit von Segmenten der Datenbank, was desweiteren durch ein Client-Server Schema den Zugriff auf jedes Segment des gesamten Netzes erlaubt.
Der Nameserver ist ein Programm das den Serverteil des client-server Machanismus des DNS darstellt. Nameserver enthalten Informationen über bestimmte Segmente der Datenbank, welche selbige für Clients, sogenannte Resolver zur Verfügung stellen. Resolver bestehen häufig lediglich aus ein paar Libraryroutinen, welche Anfragen erstellen und diese durch das Netz an den Nameserver schicken.
Die Datenbankstruktur des DNS zeigt Abbildung 2. Die Gesamtheit der Datenbank stellt sich in Form eines umgedrehten Baumgebildes dar, wobei die Wurzel (root) an der Spitze sitzt. Der Name der "root" ist die Etikette NULL, die lediglich in Form eines Punktes (".") geschrieben wird. Jeder Knoten des Baums ist sowohl eine Partition der gesamten Datenbank, als auch eine Domain des Domain Name Systems. Darüberhinaus kann nun jede Domain wieder in Partitionen, sogenannte Subdomains unterteilt werden, die sich wie Sprösslinge von den elterlichen Knoten ableiten.
Abbildung 2: Die Datenbank des DNS
Jede Domain ist derart dargestellt, daß sie eine Etikette aufweist, welche sie relativ zur elterlichen Domain identifiziert. Eine Domain besitzt desweiteren einen Domainnamen, der die Position in der Datenbank definiert. Dies ist zu vergleichen mit dem absoluten Pfad eines Directories, welches auf die Stelle im Dateisystem ihres Computers hindeutet.
Im Domain Name System besteht der komplette Domainname aus einer Reihe von Etiketten, welche bei der Domain beginnt und an der Wurzel (root) endet, wobei die einzelnen Etiketten durch Punkte getrennt sind (z.B. einstein.matematik.ac.edu). Unter der Bedingung, daß jede Domain von unterschiedlichen Institutionen verwaltet werden kann, besteht die Möglichkeit eine Domain in mehrere Subdomains zu zerlegen, deren Administration von anderen Institutionen übernommen wird.
Das Network Information Center verwaltet beispielsweise die
Domain "edu" (educational) und hat die Authorisierung
über die Subdomain "ac.edu" (academic) an die
Universität abgegeben, welche wiederum die Verwaltung der Domain
"matematik.ac.edu" dem Mathematikinstitut überlässt
(Abb. 3).
Abbildung 3: Die Verwaltung von Subdomains
Nun bleibt noch zu erwähnen, daß jede Domain so viele Subdomains wie Rechner enthalten kann. Jeder Rechner in einem Netzwerk besitzt einen Domainnamen, der Informationen wie die IP-Adresse oder wie das Routing von mails beinhaltet. Ein host kann darüberhinaus einen oder mehrere Aliasnamen haben, der nichts anderes als ein Verwies von einem Domainnamen zu dem ofiziellen oder kanonischen Hostnamen (canonical name) ist. Wenn ihre Freundin beispielsweise den Namen Elisabeth trägt, werden sie sie mal Schnucki, Schaetzchen, Süße etc. nennen und es sollte sich dann nur auf die eine "offizielle" Elisabeth beziehen.
Die für eine Domain authorisierte Organisation hat völlig freie Wahl in der Auswahl der Hostnamen innerhalb der Domain. Egal welcher Name auch benützt wird, es kann nie zu Konflikten kommen, da ja die einzigartige Domain des Netzes am Namen dranhängt. So können z. B. zwei Rechner mit dem Namen Einstein am Netz der Universität hängen; die Datagramme von einstein.matematik.ac.edu werden immer ihren Weg nach einstein.physik.ac.edu finden, da beide Rechner verschiedenen elterlichen Domains angehören.
(4.2) Wofür benötigt man nun das DNS?
Um Domainnamen und IP-Adressen aufzulösen bzw. Rechner in
entfernten Netzen ausfindig zu machen. Wie bereits weiter oben
erwähnt wurde, fällt es dem Menschen leichter sich an Namen zu
erinnern als an Zahlen. Insbesondere wenn es sich um eine derart
große Anzahl an Adressnamen handelt wie im Internet.
Computer arbeiten andererseits perfekt mit Zahlen wie den
IP-Adressen. Was passiert nun, wenn sie eine Adresse wie z. B.
http://www.altavista.com aufrufen. Ihr Browser stellt eine
Anfrage an den Domain Server ihres Providers und dieser versucht
wiederum den Doaminnamen mit der dazugehörigen IP-Adresse
aufzulösen. Für den Fall daß ihr Provider nicht authorisiert
ist für diese Zone, richtet er die Anfrage an den authorisierten
Server weiter, bis die entsprechende Domain erreicht ist.
Abbildung 4 stellt eine Domainsuche nach
"einstein.matematik.ac.edu" schematisch dar.
Figura 4: Das Auffinden von
"einstein.matematik.ac.edu" im Internet
Dies bedeutet, daß jeder Nameserver die komplette Information über die Zone beinhaltet für die er authorisiert ist, darüberhinaus verfügt er noch über Basisinformationen anderer Zonen. Wenn sich eine Anfrage auf eine Zone richtet die ausserhalb der authorisierten Zone liegt, weiß ihr Name Server wenigstens wo er suchen muss. Dies kann bedeuten, daß eine Anfrage über mehere Name Server laufen muss bis Sie Kontakt zu dem gewünschen Ziel haben.
Für den Fall, daß sie sogar die IP-Adresse ihres Zieles wüßten, ist es unvermeidlich andere Name Server zu konsultieren, wenn sich das Ziel nicht im selben Netz befindet. Auf diese Weise ist es leicht vorstellbar, warum das Domain Name System nicht aus einer zentralen Datenbank bestehen kann. Erstens würde es zu lange dauern eine Domain unter Millionen anderer auszulesen und zweitens gäbe es ziemlich lange Wartezeiten bei weltweit tausender simultaner Anfragen an einen Server. Überdies hätte es wenig Sinn eine Anfrage an einen entfernten Server zu stellen um mit einem host der eigenen Zone zu kommunizieren.
Bis jetzt haben wir Andeutungen über die Auflösung von Domainnamen zu IP-Adressen gemacht. Was passiert aber wenn sie nur die IP-Adresse haben und den entsprechenden Domainnamen herausfinden wollen. Zur Lösung dieses Problems wurde die Domain "in-addr.arpa" gebildet. (Abb. 5)
Diese Domain wird inverse Domain genannt und die Auflösung von IP-Adressen nach Domainnamen bezeichnet man als reverse mapping oder reverse lookup. Die inverse Domain wird in der Form dargestellt, daß die Ziffern der IP-Adresse in umgekehrter Reighenfolge geschrieben werden und die Domain in-addr.arpa angehängt wird.
Ein Beispiel: Wir erinnern uns, daß die IP von Einstein "149.176.12.7" lautet und den Domainnamen "einstein.matematik.ac.edu" trägt. Die Domain "matematik.ac.edu" hätte dann die inverse Domain: 12.176.149.in-addr.arpa" und der Rechner "einstein.matematik.ac.edu" würde entsprechend "7.12.176.149.in-addr.arpa" geschrieben.
Figura 5: Das reverse mapping
(5) Die Instalation eines Domain Name Servers unter LinuX am Beispiel eines Local Area Networks mit Gateway unter Verwendung von BIND (Berkeley Internet Name Daemon)
Das Folgende setzt voraus, daß sie bereits Netztwerkkarten in ihrem Netzt installiert haben bzw. wissen wie selbige unter LinuX zu konfigurieren sind. Die Befehle "ifconfig" und "ping localhost" können ihnen Aufschluß über eine korrekte Konfiguration geben. Nun wenden wir uns also endlich dem praktischen Teil zu, in dem wir ihre Rechner durch DNS verbinden und BIND konfigurieren. Weitere Voraussetzung ist, daß sie das Paket BIND, welches den Server-Dämon named (näimdii) enthält auf dem Rechner installiert haben, welcher als Nameserver eingesetzt werden soll.
In diesem Kapitel werden wir eine fiktive Domain konfigurieren. Dies soll Ihnen ermöglichen durch einfaches ersetzen der IP-Adressen und Computernamen ihren eigenen Name Server zum Laufen zu bringen. Sie werden Details entdecken, welche aus platz- und zeitgründen nicht behandelt sind. Wenn sie sich allerdings genau an die Syntax halten, sollte eigentlich nichts schiefgehen ,-)
Figura 6: Das Netz der Fa. Distribution Alcomato
Bei der Firma unsrer fiktiven Domain handelt es sich um einen Getränkegroßhandel. Die Fa. "Distribution Alcomato", welche auf exotische Biersorten und Hochprozentiges spezialisiert ist, hat vom NIC die Domain "alcomat.com" genehmigt bekommen. Distribution Alcomat verfügt über zwei Ethertnets mit den Netzziffern 192.249.249 und 192.253.253. (Abb. 6)
Einen Teil der ehemaligen Hosttabelle (gewöhnlich in /etc/hosts) zeigt die folgende Darstellung:
| /etc/hosts |
127.0.0.1 localhost # das sind die Schnappsrechner 192.249.249.2 whisky.alcomat.com whisky 192.249.249.3 brandy.alcomat.com brandy 192.249.249.4 vodka.alcomat.com vodka ......... # das sind die Bierrechner 192.253.253.2 mahou.alcomat.com mahou 192.253.253.3 augustiner.alcomat.com augustiner 192.253.253.4 polar.alcomat.com polar .......... # Diese Adressen definieren den Gateway der beiden Ethernets. 192.249.249.1 tubo.alcomat.com tubo tu tub249 192.253.253.1 tubo.alcomat.com tubo tu tub253 |
(5.1) Die Dateien der Datenbank des DNS (database files)
Der erste Schritt ist nun die Hosttabelle in entsprechnde
Dateien des DNS zu übersetzen.
Die Datenbank des DNS besteht aus mehreren Dateien: Eine Datei
projiziert alle Hostnamen auf die dazugehörigen IP-Adressen.
Andere Dateien machen genau das Gegenteil und projizieren
IP-Adressen auf die entsprechenden Hostnamen. Diese Dateien
werden für das bereits erwähnte reverse mapping benötigt und
für jedes Netz (hier, die beiden Ethernets) muss eine eigene
spezifische Datei für das Auslesen von Hostnamen durch
IP-Adressen estellt werden.
Ich habe die Datei, welche Hostnamen auf IP-Adressen projiziert named.hosts genannt. Die Dateien, welche IPs auf Hostnamen projizieren (reverse mapping) habe ich in Anlehnung an die beiden Netzziffern named.249 und named.253 getauft. Es steht ihnen natürlich völlig frei welche Dateinamen sie verwenden.
Neben diesen existieren noch zwei weitere Datenbankdateien, die für jeden Name Server mehr oder weniger identisch sind. Ich habe mich dabei für die Dateien named.cache und named.local entschieden.
Um schließlich die Datenbankdateien in ein Zusammenspiel zu bringen, benötigt der Same Server eine Startdatei. Im Falle von BIND sucht der Server diese Datei für in /etc/named.boot. (Durch die Installation des Paketes BIND wird die Datei dort automatisch abgelegt). Es sei noch erwähnt, daß außer BIND noch andere Implementierungen des DNS existieren.
Die mesiten Komponten der Datenbankdateien heissen ressource records. Gemäß der Referenz über DNS weisen die ressource records folgende Reihenfolge auf:
Die nachstehenden records verweisen auf Hostdaten der Domain (des Netzes).
Kommentare: Der Inhalt der Datenbankdateien des DNS ist unter Verwendung von Komentaren und leeren Zeilen leichter zu lesen. Kommentare beginnen mit einem Strichpunkt ";" und enden am Ende der Zeile. Name Server ignorieren Komentare sowie leere Zeilen.
SOA record:
Jede Datenbankdatei des DNS beginnt mit dem ressource record SOA
(start of authority: sie erinnern sich an die Sache mit der
Authorisierung für eine Domain). Der SOA record deutet auf den
Name Server hin, der als beste Informationsquelle für die
Rechner in dieser Domain dient. Unser Name Server - augustiner-
ist demnach für die Domain "alcomat.com" authorisiert.
Wir benötigen SOA records für die Dateien named.hosts,
named.249 und named.253. Den folgenden SOA record benützen wir
beispielsweise für named.hosts.
| SOA record |
alcomat.com. IN SOA augustiner.alcomat.com. juan.mahou.alcomat.com. ( 1 ; Serial for updates 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hours 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 week |
Der Name der Domain muß in der ersten Spalte stehen. Sie dürfen niemals vergessen einen Punkt an das Ende der Namen zu setzen ! Sollten sie das übersehen, wird automatisch die Domain "alcomat.com" an den Namen gehängt, was zum Teil zu Fehlern führt. Die Erklärung dafür finden sie im Kapitel Abkürzungen.
"IN" steht für Internet. Es existieren noch weitere Klassen, die allerdings nicht weiter von Bedeutung sind.
Der erste Name nach dem SOA record, augustiner.alcomat.com, ist der Name des Name Servers für die Domain (erste Spalte). Der zweite Name, juan.mahou.alcomat.com ist die Postadresse der für diese Domain zuständigen Person. (wenn sie den ersten Punkt mit einem @ ersetzen). BIND liefert noch einen andere Typen von ressource record für diesen Zweck: RP (responsible person).
Die in Klammern gesetzten Ausdrücke können sich über mehrere Zeilen erstrecken. Fast alle Zeilen innerhalb der Klammern dienen zur Information von Name Servern untergeordeneten Ranges. Diese Server werden sekundäre Name Server genannt und sind in unserem Beispiel nicht weiter erwähnt. Möglicherweise gehe ich darauf in einer späteren Ausgabe ein.
Ähnliche SOA records weden in den Dateien named.249 y named.253 eingesetzt. Allerdings wird in diesen Dateien die Domain "alcomat.com" durch die Domain des reverse mapping (249.249.192.in-addr.arpa und 253.253.192.in-addr.arpa) ersetzt.
NS record:
Die nächste Zeile, die in fast jede Datei der DNS-Datenbank
eingesetzt wird, ist der NS (name server) record, welcher auf den
oder die Name Server-Namen verweist.:
| NS record |
alcomat.com. IN NS augustiner.alcomat.com. alcomat.com. IN NS tubo.alcomat.com. |
Diese records weisen daraufhin, daß zwei Name Server für die Domain "alcomat.com" eingesetzt werden. Die Nameserver sind auf den hosts "augustiner" und "tubo" installiert. Rechner wie "tubo", die wegen ihrer Funktion als gateway mehr als ein Netzwerkinterface besitzen (miltihomed hosts), in unserem Falle zwei Ethernetkarten, sind empfehlenswerte Beispiele für einen Name Server, da diese unter dauernder Benützung stehen: Erstens werden sie von Rechnern aus mehr als einem Netz angefahren und wenn sie dann noch als Router dienen, werden sie selten runtergefahren da sie eine besondere Wartung erfahren.
Genau so wie wir mit den SOA records verfahren sind, fügen wir NS records in die Dateien named.249 y named.253.
Adressen und Alias records:
Der nächste Schritt besteht darin Verweise von Hostname auf
IP-Adressen zu bilden. Die folgenden records fügen wir in die
Datei named.hosts.
| A record |
; ;Die Hostadressen ; localhost.alcomat.com. IN A 127.0.0.1 mahou.alcomat.com. IN A 192.253.253.2 augustiner.alcomat.com. IN A 192.253.253.3 polar.alcomat.com. IN A 192.253.253.4 ; ; Hosts mit zwei Ethernetkarten (multihomed) ; tubo.alcomat.com. IN A 192.253.253.1 tubo.alcomat.com. IN A 192.249.249.1 ; ; Aliase ; edel.alcomat.com. IN CNAME augustiner.alcomat.com. pol.alcomat.com. IN CNAME polar.alcomat.com. tu.alcomat.com. IN CNAME tubo.alcomat.com. tub249.alcomat.com. IN A 192.249.249.1 tub253.alcomat.com. IN A 192.253.253.1 |
Die ersten beiden Blöcke werden sie jetzt kaum mehr überraschen. Das "A" steht für Adresse (address) und jeder record weist von einem Hostnamen auf die dazugehörige IP-Adresse. Tubo soll sowohl als Router als auch als Gate agieren. Deshalb weist er zwei Adressen und zwei ressource records auf.
Der dritte Block beinhaltet die Aliastabelle. Für die ersten Aliase benutzen wir den CNAME record (canonical hostname). Darüberhinaus bilden wir noch Adressrecords für die restlichen beiden Aliase.
Wenn ein Name Server einen Namen sucht und dabei auf einen CNAME record stößt, ersetzt er den Alias durch den kanonischen Hostnamen und setzt seine Suche nach der entsprechenden IP-Adresse fort. Wird nun beispielsweise ein Name wie "tu" gesucht, wird der Name Server auf den Namen "tubo" verwiesen, worauf er dann die beiden IP Adressen 192.249.249.1 und 192.253.253.1 zurückerhält.
Die zwei letzten Zeilen beschreiben einen speziellen Fall. Wir gehen davon aus daß ein Gateway wie "tubo" im Netz installiert ist und sie möchten testen ob die beiden Interfaces funktionieren. Hierfür wird ein "ping" an das Interface gesandt um zu überprüfen ob es antwortet. Wenn sie nun ein "ping tubo" abschicken, wird der Name Server beide IPs zurückgeben. In unserer Tabelle haben wir keine Aliasnamen für tub249 und tub253 gesetzt, damit wir beide Interfaces getrennt anspechen können. Um also eine multiple Antwort zu vermeiden bzw getrennte Namen zum Test der Interfaces zu haben, wurden nur A records auf die Namen gesetzt. Um schließlich die Funtion des Interfaces 192.249.249.1 von "tubo" zu testen, senden sie ein "ping tub249", da sich dies nur auf ein Interface bezieht. das ganze funktioniert entsprechend mit "tub153".
Hierfür eine allgemeine Regel:
| Besitzt ein Rechner mehr als ein Netzwerkinterface (multihomed host), wird ein Adress-record "A" mit einem Alias gebildet, der eindeutig ist für diese Adresse. |
Nebenbei sei noch erwähnt, daß die Benützer des Systems von der Existens der Adressen tub249 und tub253 nichts zu wissen brauchen, da diese lediglich dem Administrator zu Prüfzwecken dienen.
PTR Records
Dieser Recordtyp beschreibt den Verweis von IP-Adressen auf
Hostnamen. Die Datei "named.249" bildet Verweise von
IP-Adressen auf Hostnamen für das Netz 192.249.249. Für diesen
Verweis wird der ressource record PTR (pointer) verwendet. Es
wird ein record für jeden host des Netzes gesetzt. (Erinnern sie
sich daß das DNS Namen für Adressen sucht). Die Adresse wird in
umgekehrter Reihenfolge dargestellt und die domain in-addr.arpa
angehängt.
Die folgende Darstellung zeigt die PTR records für das Netz 192.249.249.
| PTR record |
1.249.249.192.in-addr.arpa. IN PTR tubo.alcomat.com. 2.249.249.192.in-addr.arpa. IN PTR whisky.alcomat.com. 3.249.249.192.in-addr.arpa. IN PTR brandy.alcomat.com. 4.249.249.192.in-addr.arpa. IN PTR vodka.alcomat.com. |
Erinnern wir uns daran, daß tubo zwei Adressen hat, da er ja
über zwei Netzwerkkarten verfügt. Trotzdem erschein tubo hier
nur einmal, da diese Datei lediglich Verbindungen zum Netz
192.249.249 darstellt und tubo eben nur mit der Adresse
192.249.249.1 dort erscheint. Entsprechendes gilt für Netz
192.253.253.
(5.3) Die kompletten Datenbankdateien für unsere fiktive Domain
Die Datei für die Hosttabelle der Domain alcomat.com
| named.hosts |
alcomat.com. IN SOA augustiner.alcomat.com. juan.mahou.alcomat.com. ( 1 ; Serial for updates 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hours 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 week ; ; Unsere nameserver ; alcomat.com. IN NS augustiner.alcomat.com. alcomat.com. IN NS tubo.alcomat.com. ; ; Hostadressen ; localhost.alcomat.com. IN A 127.0.0.1 mahou.alcomat.com. IN A 192.253.253.2 augustiner.alcomat.com. IN A 192.253.253.3 polar.alcomat.com. IN A 192.253.253.4 whisky.alcomat.com. IN A 192.249.249.2 brandy.alcomat.com. IN A 192.249.249.3 vodka.alcomat.com. IN A 192.249.249.4 ; ; multihomed hosts ; tubo.alcomat.com. IN A 192.253.253.1 tubo.alcomat.com. IN A 192.249.249.1 ; ; Aliase ; edel.alcomat.com. IN CNAME augustiner.alcomat.com. pol.alcomat.com. IN CNAME polar.alcomat.com. tu.alcomat.com. IN CNAME tubo.alcomat.com. tub249.alcomat.com. IN A 192.249.249.1 tub253.alcomat.com. IN A 192.253.253.1 |
Die Dateien named.249 und named.253 für den Verweis von IP-Adressen nach Domainnamen
| named.249 |
249.249.192.in-addr.arpa. IN SOA augustiner.alcomat.com. juan.mahou.alcomat.com. ( 1 ; Serial for updates 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hours 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 week ; ; Nameserver ; 249.249.192.in-addr.arpa. IN NS augustiner.alcomat.com. 249.249.192.in-addr.arpa. IN NS tubo.alcomat.com. ; ; Verweise von Adressen zu Namen ; 1.249.249.192.in-addr.arpa. IN PTR tubo.alcomat.com. 2.249.249.192.in-addr.arpa. IN PTR whisky.alcomat.com. 3.249.249.192.in-addr.arpa. IN PTR brandy.alcomat.com. 4.249.249.192.in-addr.arpa. IN PTR vodka.alcomat.com. |
| named.253 |
253.253.192.in-addr.arpa. IN SOA augustiner.alcomat.com. juan.mahou.alcomat.com. ( 1 ; Serial for updates 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hours 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 week ; ; Nameserver ; 253.253.192.in-addr.arpa. IN NS augustiner.alcomat.com. 253.253.192.in-addr.arpa. IN NS tubo.alcomat.com. ; ; Verweise von Adressen nach Namen ; 1.253.253.192.in-addr.arpa. IN PTR tubo.alcomat.com. 2.253.253.192.in-addr.arpa. IN PTR mahou.alcomat.com. 3.253.253.192.in-addr.arpa. IN PTR augustiner.alcomat.com. 4.253.253.192.in-addr.arpa. IN PTR polar.alcomat.com. |
Die Loopback Adresse
Ein Nameserver benötigt eine zusätzliche Datei für das
Loopback-Netz: named.local. Es handelt sich
hierbei um die Adresse die nur für den Host selbst von Bedeutung
ist. Die Netzadresse des Loopback ist (fast) immer 127.0.0 und
die des hosts 127.0.0.1.
| named.local |
0.0.127.in-addr.arpa. IN SOA augustiner.alcomat.com. juan.mahou.alcomat.com. ( 1 ; Serial for updates 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hours 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 week ; ; Nameserver ; 0.0.127.in-addr.arpa. IN NS augustiner.alcomat.com. 0.0.127.in-addr.arpa. IN NS tubo.alcomat.com. ; ; Die inverse Adressierung für den Loopback ; 0.0.127.in-addr.arpa. IN PTR localhost. |
Diese Datei enthält die Namen und Adressen von allen
Root-Nameservern des Internet. Wenn sie nicht vorhaben ihr Netz
ans Internet anzuschleissen, ist diese Datei für ihr DNS-Setup
ohne Belang.
Obwohl das Softwarepaket BIND normalerweise diese Datei
(named.root oder named.cache) liefert, ist es empfehlenswert die
aktuelle Datei via anonymous ftp von der Adresse: ftp.ts.internic.net(198.41.0.5)
zu beziehen. Da es sich um eine Tabelle handelt, die für (fast)
jeden Name Server gleich ist und automatisch mit dem BIND-Paket
installiert wird, möchte ich nicht weiter darauf eingehen. Das
einzige was sie wissen sollten ist der tasächliche Name dieser
Datei um den entsprechenden Verweis in die Startdatei von named
(named.boot) setzen zu können.
Was uns schließlich noch fehlt ist eine Datei, die unsere Datenbankdateien zusammenführen, oder besser gesagt erwartet der Name Server eine Datei die angibt wo sich die einzelnen Datenbankdateien des DNS befinden.
BIND sucht by default die Datei /etc/named.boot. Die Datenbankdateien unseres Beispiels befinden sich in dem Verzeichnis /usr/local/named. Es steht ihnen natürlich wieder frei andere Verzeichnisse zu wählen, dennoch sollten die Dateien aus Paltzgründen nicht gerade im Rootverzeichnissystem liegen.
| named.boot |
directory /usr/local/named primary alcomat.com named.hosts primary 249.249.192.in-addr.arpa named.249 primary 253.253.192-in-addr.arpa named.253 primary 0.0.127.in-addr.arpa named.local cache . named.cache |
Wenn sie nun alle Verzeichnisse estellt haben, sollten sie den Dämon "named" in ihrer Systeminitialisierungsdatei aktivieren, sodaß er automatisch beim Hochfahren des Systems gestartet wird.
Bisher haben wir sehr ausführliche Dateien gebildet um die Erklärung zu erleichtern. Normalerweise werden die Dateien mit einer Reihe von Abkürzungen verfasst.
Der Ursprung (origin)
Die zweite Spalte der Startdatei "named.boot" verweist
immer auf eine Domain. Diese Domain ist der Schlüssel für die
gebräuchlichste Abkürzung, da es den Ursprung
für alle Daten innerhalb der jeweiligen Datenbankdatei
darstellt.
!! Der Ursprung wird automatisch an alle
Namen angehängt, die nicht mit einem Punkt enden !!
("mahou.alcomat.com" würde dann als
"mahou.alcomat.com.alcomat.com" gelesen werden.
Desweiteren hat jede Datenbankdatei einen eigenen Ursprung.
Die Adresse von "mahou" in der Datei named.hosts: mahou.alcomat.com. IN A 192.253.253.2 kann man dann wie folgt schreiben: mahou IN A 192.253.253.2
Wir definierten die folgende Adresse in der Datei named.249: 2.249.249.192.in-addr.arpa. IN PTR whisky.alcomat.com.Da 249.249.192.in-addr.arpa der Ursprung für diese Datei ist können wir uns einige schreibarbeit sparen.
2 IN PTR whisky.alcomat.com.
Die Notation @
Ist der Domainname gleich dem Ursprung, kann er auch mit
einem @ abgebildet werden. Dies erscheint recht häufig mit den
SOA record:
@ IN SOA augustiner.alcomat.com. juan.mahou.alcomat.com. ( 1 ; Serial for updates 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hours 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 week
Wiederholung von Namen
Ist die ersten Spalte eines ressource records ohne Eintrag,
wird automatisch der Name des vorherigen ressource records
gelesen. Dies erleichtert die Arbeit wenn man mehrere records
für einen Namen darstellt.
tubo IN A 192.253.253.1 IN A 192.249.249.1
Abschließend presentiere ich ihnen die abgekürzte Datei named.hosts. Es ist eine recht gute Übung die Änderungen für die übrigen Dateien vorzunehmen ;-))
| named.hosts (mit Abkürzungen) |
@ IN SOA augustiner juan.mahou ( 1 ; Serial for updates 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hours 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 week ;
; Die Nameserver (der Name @ ist bereits enthalten )
;
IN NS augustiner.alcomat.com
IN NS tubo.alcomat.com.
; Nur in dieser Datei kann der Domainname(alcomat.com)für die Nameserver
; weggelassen werden, da named.host den gleichen Ursprung hat!
;
; Die Hostadressen
;
localhost IN A 127.0.0.1
mahou IN A 192.253.253.2
augustiner IN A 192.253.253.3
polar IN A 192.253.253.4
whisky IN A 192.249.249.2
brandy IN A 192.249.249.3
vodka IN A 192.249.249.4
tubo IN A 192.253.253.1
IN A 192.249.249.1
;
; Unser multihomed host
;
tub249 IN A 192.249.249.1
tub253 IN A 192.253.253.1
;
; Aliase
;
edel IN CNAME augustiner
pol IN CNAME polar
tu IN CNAME tubo
|
Das Gegenstück zum Nameserver ist die Resolverbibliothek, welche aus einer Gruppe von Funktionen besteht, die der Standard C-Bibliothek unter LinuX angehören. Die wichtigsten Resolverroutinen sind folgende:
Die wichtigste Datei ist host.conf, welche die die Funktionen des Resolvers steuert. Sie bestimmt welche Dienste von dem Resolver in Anspruch genommen werden und in welcher Reihenfolge. Für unser Netz benötigen wir nur die Optionen: order und multi.
Die Datei /etc/host.conf unseres Beispiel weist den Resolver an, zuerst DNS, und danach die Tabelle /etc/hosts zu konsultieren.
| /etc/host.conf |
# /etc/host.conf # Wir benützen named und die Hosttabelle:/etc/hosts order bind hosts # mehrfache IPs erlaubt (nur für /etc/hosts) multi on |
Da unser Resolver nun DNS benützt, müssen wir ihm noch
mitteilen welchen Nameserver er konsultieren soll. Dafür
existiert die Datei: resolv.conf.
Die wichtigste Option in resolv.conf ist nameserver,
welche den entsprechenden Nameserver angibt. Es können bis zu
drei Nameservereintrage vorgenommen werden. Es ist generell zu
empfehlen den verlässlichsten Nameserver zuerst zu setzen, da
die Server der Reihe nach angefahren werden.
Desweiteren existieren noch zwei zusätzliche Optionen - domain
und search - welche auf Domainnamen zeigen, die dann
automatisch an Hostnamen gehängt werden, wenn der Resolver die
komplette Adresse nicht kennt. Für unser Beispiel bedeutet dies
wieder, daß im Falle des Befehls "ftp mahou",
automatisch die Domain "alcomat.com" abgehängt wird.
Somit sind sie nicht immer gezwungen den kompletten Namen zu
schreiben. Der Unterschied zwischen den genannten Optionen liegt
darin, daß domain nur eine Domainangabe erlaubt,
wohingegen search mehrere Einträge zuläßt. Der
Nachteil einer ganzen Liste von Domains zeigt sich allerdings in
längeren Wartezeiten.
| /etc/resolv.conf |
# /etc/resolv.conf # Die Domain von Distribution Alcomato domain alcomat.com # # Der Nameserver # Als zweite IP könnten sie nun die IP ihres Internet Providers setzen. nameserver 192.253.253.1 |
Bevor wir das Tool nslookup einstzen, welches im Paket BIND enthalten ist, wollen wir das System auf syslog-Fehler überprüfen. Wenn sie "named" bereits in ihrer Systeminitialisierungsdatei aktiviert haben und "named" automatisch beim Systemstart gemountet wird, sollten sie beim booten einen Hinweis entdecken daß "named" aktiv ist. Sollten sie allerdings bevorzugen den Dämon manuell zu starten, geben sie folgendes am rootprompt ein:
# /etc/named -b /etc/named.boot (nur root kann das ausführen!)
Für den Fall, daß ein Fehler vorliegt, könne dann etwa
folgendes erscheinen:
Feb 12 21:16:48 tubo named [3221]: named
hosts Line 15: database format error
(192.249.249.3), was ihnen die Datei und die Zeile
angibt, wo sich der Fehler befindet.
Nachdem alle Fehler behoben sind schicken Sie ein
# kill -HUP 'cat /etc/named.pid'
ab, damit der Nameserver seine Datenbankdateien erneut liest.
(Vielleicht lassen sie sich vorsichtshalber die Syslogeinträge
noch einmal auflisten)
Die Tests mit nslookup
Mit nslookup kann jeder ressource record und Nameserver ausgetestet werden. Wir wollen hier nur die elementaren Tests aufführen.
Suche im lokalen Netz:
|
|
Wenn diese Tests auf die dargestellte Weise fuktioniert haben, arbeitet ihr Nameserver korrekt für ihre Domain.
Suche nach entfernten Rechnern:
Für den Fall, daß ihr Netz über eine Internetanbindung
verfügt, ist es angebracht nslookup auch dort zu testen. Es ist
wirklich erstaunlich was man mit dem Tool so alles machen kann
;-)
|
|
Wenn nun diese beiden Tests noch gelingen, weiß ihr Nameserver wo sich die Rootnameserver des Internet befinden (Datei: named.cache) und wie er selbige zu kontaktieren hat um Informationen über entfernte Netze zu beziehen.
Literatur:
Über den Author
Andreas J Gundacker ist Diplom Kaufmann mit starker Neigung zur
Informationstechnologie.
LinuX hat ihm dabei geholfen seine privaten
Studien der Netzwerktechnik zu realisieren.
Als dieser Artikel
geschrieben wurde, arbeitete er als Assistent der Geschäftsleitung bei
Klöckner Moeller-Somerinca in Carcas/Venezuela. Dieser Artikel wurde
ursprünglich in spanischer Sprache verfaß.
| Webpages maintained
by Miguel Ángel Sepúlveda
© Andreas J Gundacker 1998 Übersetzt von:Andreas J Gundacker LinuxFocus 1998 |