![[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 |