HomeMapIndexSearchNewsArchivesLinksAbout LF
[Top Bar]
[Bottom Bar]

von:Andreas J Gundacker

Inhalt:
1)Das ARPANET, der Ursprung des World Wide Web
2)Ein paar technische Ausdrücke zum Verständnis
3)Das TCP/IP
3.1)Das IP oder die IP ?
3.2)Das TCP (Transmission Control Protocol)
4)Das Domain Name System (DNS)
4.1)Ein Überblick des Systems
4.2)Wofür benötigt man nun das DNS?
5)Die Instalation eines Domain Name Servers
5.1)Die Dateien der Datenbank des DNS
5.2)Ressource records
5.3)Die kompletten Datenbankdateien für unsere fiktive Domain
5.4)Abkürzungen
5.5)Die Resolverbibliothek
5.6)Der Test mit nslookup

Einführung in DNS unter LinuX

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.


Worst seen with Explorer. Try Netscape instead. 

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).

(3) Das TCP/IP

(3.1) Das IP oder die IP ?

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.

(5.2) Ressource records

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.

 

Die Datei named.cache

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.

 

Die Startdatei: named.boot

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.

(5.4) Abkürzungen

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

 

(5.5) Die Resolverbibliothek

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

 

(5.6) Der Test mit nslookup

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:

  • Die Suche nach einem lokalen Hostnamen:

    # nslookup vodka
    Server: tubo.alcomat.com
    Address: 192.253.253.1

    Name: vodka.alcomat.com
    Address: 192.245.245.4
 
  • Die Suche nach einer lokalen IP-Adresse:

    #
    nslookup 192.245.245.2
    Server: tubo.alcomat.com
    Address: 192.253.253.1

    Name: whisky.alcomat.com
    Address; 192.245.245.2

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 ;-)

 

  • Die Suche nach einem entfernten Hostnamen:

    # nslookup ftp.uu.net
    Server: tubo.alcomat.com
    Address: 192.253.253.1

    Name: ftp.uu.net
    Address: 192.48.96.9
 
  • Die Suche nach einer entfernten IP-Adresse::

    # nslookup 192.48.96.9
    Server: tubo.alcomat.com
    Address: 192.253.253.1

    Name: ftp.uu.net
    Address: 192.48.96.9

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