Das Prinzip der Hostnamen statt IP-Adressen findet im lokalen Netz eine brauchbare Implementierung durch die Datei /etc/hosts. Im WAN oder gar im Internet ist diese Form denkbar ungeeignet.
In den Anfangszeiten des Internets gab es tatsächlich eine solche Datei, sie hieß hosts.txt und enthielt alle Hostnamen des Internets samt IP-Adressen. Jeder Systemverwalter am Netz musste diese Datei regelmäßig downloaden um so auf alle Rechnernamen zugreifen zu können. Durch das Wachstum des Internet war diese Möglichkeit bald überholt. (Bei einer geschätzten Anzahl von 10 Mill. Rechnern am Internet, durchschnittlich etwa 8 Zeichen pro Namen und 15 Zeichen pro IP-Adresse käme allein die Dateigröße von hosts.txt auf 25 Byte * 10 Mill = 25 Mill Byte = ca 25 MByte) Zudem mussten alle Rechnernamen eindeutig sein, das ist bei 10 Millionen Rechnern nicht einfach…
Um diesem Problem Herr zu werden, wurde das Domain Name System eingeführt. Es beruht auf der Idee von Domains (Domänen), also unterteilten Bereichen, die organisatorisch für die Verwaltung der Hostnamen zuständig sind.
ACHTUNG: Dieses System hat nichts mit routing zu tun, es besagt nicht das geringste, wo ein Rechner steht, bzw. in welchem Netz er sich befindet. Es geht ausschließlich um die Verwaltung von Namen und dazugehörigen IP-Adressen!
Die Idee, die dem DNS zugrundeliegt ist einfach. Da das Internet zu groß ist, um seine Namen/IP-Adressen zentral zu verwalten, muß für eine Aufteilung in dezentrale Verantwortungsbereiche gesorgt werden. Diese Verantwortungsbereiche nennen sich domains.
Ursprünglich gab es nicht besonders viele Top Levels Domains (kurz TLD), als das Internet noch eine rein US-amerikanische Sache war wurden folgende Top-Levels Domains aufgestellt:
- com Kommerzielle Organisationen
- org Nicht-kommerzielle Organisationen
- edu Erziehungseinrichtungen (education) Schulen, Unis, …
- mil Militärische Netze
- gov Regierungsnetze Seit das Internet wirklich international ist, haben alle angeschlossenen Länder außer den USA noch eine eigene Domain bekommen, jeweils durch ihre ISO-Landeskenner dargestellt. Also hat Deutschland beispielsweise de, Österreich at und die Schweiz ch.
Es werden zwischen den generischen Top-Level-Domains ( gTLD ) – zum Beispiel .org, .info, .com – und den länderbezogenen Top Level Domains (ccTLDs – country code ) – zum Beispiel .de, .nl, .pl, .uk, .at. unterschieden.
All diese Domains werden Toplevel domains genannt, weil sie noch weiter in Subdomains aufgeteilt werden können. So enthält beispielsweise die Topleveldomain edu Subdomains für jede amerikanische Universität. So hat etwa die Universität von North-Carolina die Subdomain unc. Ein Rechner mit Namen sunsite in der Subdomain unc der Topleveldomain edu kann jetzt angesprochen werden als sunsite.unc.edu
Jede Domain (auch die Subdomains) ist verpflichtet, mindestens zwei Nameserver zur Verfügung zu stellen. Dabei handelt es sich um Rechner, die Datenbanken über Namen und dazugehörigen IP-Adressen ihrer Domain verwalten.
Jeder dieser Nameserver hat immer die Informationen aller seiner Subdomains samt deren Nameserver, er hält ferner die Adresse seines Toplevel-Nameservers bereit und verwaltet zusätzlich alle Namen und IP-Adressen seiner (und nur seiner) Domain.
Ist der Nameserver ein Toplevel-Domain-Server, so hat er alle Adressen aller anderen Toplevel-Nameserver vorrätig.
Wenn ein Rechner jetzt ein Paket an einen anderen Rechner im WAN schicken will, so muß zuerst herausgefunden werden, welche IP-Adresse dieser andere Rechner hat. Erst dann kann das eigentliche routing beginnen, denn unsere routing-tables sind ja IP-Adressen orientiert.
Den Vorgang, einen Nameserver abzufragen nennt man Nameserver-Lookup, es ist nicht uninteressant sich diesen Vorgang genauer anzusehen.
Ein Beispiel
Ein Rechner hal der Domain mydomain.de ist permanent (wie auch immer) mit dem Internet verbunden. Ein Benutzer dieses Rechners tippt jetzt folgenden Befehl:
# ping sunsite.unc.edu
Er will also mittels ping erfahren, ob der Rechner sunsite ansprechbar ist. Nur steht leider in der Datei /etc/hosts keine Adresse des Rechners sunsite.unc.edu. Was passiert?
Zunächst frägt der Rechner hal seinen zuständigen Domain-Nameserver nach der IP-Adresse von sunsite. Es handelt sich hier um den Nameserver der Domain mydomain.de. Doch dieser Nameserver hat die IP-Adresse von sunsite nicht gespeichert. Er gibt stattdessen die Frage an seinen übergeordneten Nameserver weiter. Hier handelt es sich also schon um den Nameserver der Topleveldomain de.
Auch dieser Nameserver kennt die Adresse von sunsite nicht. Immerhin kennt er – als Toplevel-Nameserver – die Adressen alle anderen Toplevel-Nameserver. Die Frage wird also an den Nameserver der Topleveldomain edu weitergegeben.
Auch dieser Nameserver weiß nichts von sunsite, aber er kennt den Nameserver der Domain unc und reicht die Frage an ihn weiter. Dieser Nameserver kennt schließlich die Adresse von sunsite und antwortet direkt an hal, dessen Adresse in der Nachfrage jeweils enthalten war. Jetzt hat hal die IP-Adresse von sunsite.unc.edu und kann mit dem routing beginnen.
Erst jetzt wird der Ping-Befehl ausgeführt, mit der IP-Adresse statt des Namens. Dieser ganze Vorgang dauert etwa 2 Sekunden, selbst bei langsammen Internetzugängen ist das einer der schnellsten Services. Der Benutzer bekommt überhaupt nichts davon mit, es sei denn er hat einen falschen Namen eingegeben, dann erscheint eine entsprechende Fehlermeldung nach dem Lookup.
Dieser Vorgang wird intern als bind bezeichet, nach dem Berkley Internet Nameserver Daemon.
Damit diese ganze Mechanik funktioniert, muß dem System natürlich zumindest mitgeteilt werden, welche Adresse der nächste erreichbare Nameserver hat. Außerdem ist die Reihenfolge festlegbar, ob der Rechner zuerst über Nameserver und dann über /etc/hosts sucht (selten) oder umgekehrt.
Die Dateien, die hier wichtig sind sind /etc/host.conf zum Festlegen der Reihenfolge der Namenssuche. Sie sollte folgende Zeilen enthalten:
order hosts bind multi on
Die Zeile order hosts bind legt die Reihenfolge (order) zwischen hosts (lokale Suche in /etc/hosts) und bind (Nameserver) fest. Hier wird also zuerst in der Datei hosts gesucht bevor ein Nameserver herangezogen wird. Die Zeile multi on hat mit Nameservern nichts zu tun, sie legt fest, dass ein Host mehrere Namen haben darf.
Welcher Nameserver nun als erster benutzt wird, ist einstellbar in der Datei /etc/resolv.conf – Hier ein Beispiel:
search mydomain.de nameserver 149.174.211.5 nameserver 194.25.2.129
Hier sind zwei Nameserver angegeben, der erste wird immer auch zuerst abgefragt, nur wenn er nicht ansprechbar ist wird auf den zweiten ausgewichen. Die Zeile search mydomain.de weist das System an, Rechnernamen, die ohne Domain angegeben wurden zuerstmal mit der angegebenen zu versuchen. Würde in unserem Fall jemand also rlogin hal tippen, so würde das System zunächst den Rechner hal.mydomain.de suchen, falls kein hal in der Datei /etc/hosts steht.
Achtung: Die Einträge der Nameserver werden sinnvollerweise als IP-Adressen und NICHT als symbolische Namen gemacht.