Aspekte der Netzwerkarbeit mit TCP/IP

  • Aspekte der Netzwerkarbeit mit TCP/IP

    Wir wenden uns nun den Details zu, mit denen Sie es beim Anschluss Ihrer Linux-Maschine an ein TCP/IP-Netzwerk zu tun bekommen, darunter auch der Umgang mit IP-Adressen, Hostnamen und manchmal auch Routing-Aufgaben. Dieses Kapitel gibt Ihnen das erforderliche Hintergrundwissen an die Hand, das Sie benötigen, um die Anforderungen Ihres Setups zu verstehen. Die nächsten Kapitel behandeln die Tools, die Sie dabei verwenden werden.

    Wenn Sie mehr über TCP/IP und dessen Hintergründe erfahren wollen, sollten Sie sich das aus drei Bänden bestehende Internetworking with TCP/IP von Douglas R. Comer ansehen. Eine Anleitung zur Verwaltung eines TCP/IP-Netzwerks finden Sie in TCP/IP Netzwerk Administration von Craig Hunt.

    Netzwerk-Schnittstellen

    Um die ganze Vielfalt an Ausrüstung zu verstecken, die in einem Netzwerk eingesetzt werden kann, definiert TCP/IP eine abstrakte Schnittstelle, über die auf die Hardware zugegriffen wird. Dieses Interface bietet eine Reihe von Operationen an, die für jede Hardware gleich sind und sich im wesentlichen mit dem Senden und Empfangen von Paketen beschäftigen.

    Für jedes periphere Gerät, das Sie für das Netzwerk verwenden wollen, muss ein entsprechendes Interface im Kernel präsent sein. Zum Beispiel werden Ethernet-Interfaces unter Linux eth0 und eth1 genannt; SLIP-Schnittstellen heißen sl0, sl1 etc. Die Namen dieser Schnittstellen werden zu Konfigurationszwecken verwendet, wenn Sie eine bestimmte physikalische Einheit für den Kernel benennen wollen. Darüber hinaus besitzen sie keine Bedeutung.

    Um in einem TCP/IP-Netzwerk eingesetzt werden zu können, muss dem Interface eine IP-Adresse zugewiesen werden, die als Identifizierung dient, wenn mit dem Rest der Welt kommuniziert wird. Diese Adresse ist nicht mit dem oben erwähnten Interface-Namen identisch. Vergleichen Sie ein solches Interface mit einer Tür, dann gleicht die Adresse dem an ihr befestigten Namensschild.

    Natürlich können noch weitere Parameter des Geräts eingestellt werden. Einer dieser Parameter ist die maximale Größe von Datagrammen, die von der Hardware verarbeitet werden können. Diese Größe wird auch als Maximum Transfer Unit oder MTU bezeichnet. Andere Attribute werden später eingeführt.

    IP-Adressen

    Wie bereits im vorhergehenden Kapitel erwähnt, bestehen die vom IP-Netzwerk-Protokoll verstandenen Adressen aus 32-Bit-Zahlen. Jeder Maschine muss eine für die Netzwerkumgebung eindeutige Adresse zugewiesen werden. Wenn Sie ein lokales Netzwerk betreiben, das keine Verbindung zu anderen Netzwerken unterhält, dann können Sie diese Adressen nach Ihren Wünschen frei vergeben. Für Sites im Internet werden Nummern dagegen von einer zentralen Stelle, dem Network Information Center, oder kurz NIC, vergeben.(1)

    Zur einfacheren Lesbarkeit werden IP-Adressen in vier 8-Bit-Zahlen aufgeteilt, die man Oktette nennt. Beispielsweise hat quark.physics.groucho.edu die IP-Adresse 0x954C0C04, was als 149.76.12.4 geschrieben wird. Diese Schreibweise wird häufig als Dotted Quad Notation bezeichnet.

    Ein weiterer Grund für diese Notation ist, dass sich IP-Adressen aus einer Netzwerknummer in den führenden Oktetts und aus einer Hostnummer dahinter zusammensetzen. Wenn Sie beim NIC IP-Adressen beantragen, wird Ihnen nicht einfach eine bestimmte Adresse für jeden einzelnen Host zugewiesen, den Sie einbinden wollen, sondern Sie erhalten eine Netzwerknummer und dürfen innerhalb dieser Grenzen jede gültige IP-Adresse verwenden.

    Abhängig von der Größe des Netzwerks muss der Adressenanteil des Host mal größer oder kleiner sein. Um diesen unterschiedlichen Bedürfnissen entgegen zukommen, gibt es unterschiedliche Netzwerk-Klassen, die unterschiedliche Aufteilungen von IP-Adressen definieren.

    Klasse AKlasse A umfasst Netzwerke von 1.0.0.0 bis 127.0.0.0. Die Netzwerknummer ist im ersten Oktett enthalten. Es steht also ein 24 Bit langer Hostanteil zur Verfügung, was für ca. 1,6 Millionen Hosts ausreicht.Klasse BKlasse B umfasst die Netzwerke 128.0.0.0 bis 191.255.0.0. Die Netzwerknummer ist in den ersten beiden Oktetts enthalten. Das erlaubt 16.320 Netze mit jeweils 65.024 Hosts.Klasse CKlasse C umfaßt die Netzwerke 192.0.0.0 bis 223.255.255.0. Die Netzwerknummer steht in den ersten drei Oktetts. Das gestattet fast 2 Millionen Netzwerke mit bis zu 254 Hosts.Klassen D, E und FAdressen, die im Bereich von 224.0.0.0 bis 254.0.0.0 liegen, sind entweder experimenteller Natur oder für zukünftige Verwendungen reserviert und spezifizieren kein Netzwerk.


    Wenn Sie zu unserem Beispiel im vorigen Kapitel zurückkehren, sehen Sie, daß 149.76.12.4, die Adresse von quark, auf den Hostrechner 12.4 im Klasse-B-Netzwerk 149.76.0.0 zeigt.

    Sie werden bemerkt haben, daß in der obigen Liste nicht alle möglichen Werte für jedes Oktett des Hostanteils verwendet werden dürfen. Der Grund dafür liegt darin, dass Hostnummern, bei denen alle Oktets 0 oder 255 lauten, für spezielle Zwecke reserviert sind. Eine Adresse, bei der der Hostanteil nur aus Nullen besteht, steht für das Netzwerk. Sind alle Bits des Hostanteils auf 1 gesetzt, spricht man von einer Broadcast-Adresse. Daten, die an diese Adresse geschickt werden, werden gleichzeitig von allen Hosts in dem spezifizierten Netzwerk empfangen. 149.76.255.255 ist also keine gültige Host-Adresse, sondern steht für alle Hosts im Netzwerk 149.76.0.0.

    Es existieren auch zwei reservierte Netzwerk-Adressen: 0.0.0.0 und 127.0.0.0. Die erste ist die sogenannte Default Route, die zweite ist die Loopback-Adresse. Die Default Route hat etwas damit zu tun, wie IP Datagramme routet. Dieses Thema wird im nächsten Abschnitt behandelt.

    Das Netzwerk 127.0.0.0 ist für den IP-Verkehr reserviert, der lokal auf Ihrem Host stattfindet. Üblicherweise wird die Adresse 127.0.0.1 einem speziellen Interface auf Ihrem Host, dem sogenannten Loopback-Interface, zugewiesen, das wie ein geschlossener Kreis funktioniert. Jedes von TCP oder UDP dorthin übergebene Paket wird direkt von dort zurückgegeben, als wäre es gerade von einem anderen Netzwerk angekommen. Auf diese Weise können Sie Netzwerk-Software entwickeln und austesten, ohne jemals ein »echtes« Netzwerk verwenden zu müssen. Eine andere sinnvolle Anwendung ergibt sich beim Einsatz von Netzwerk-Software auf einem Host, der nicht vernetzt ist. Das ist gar nicht so ungewöhnlich, wie es klingt. Beispielsweise verfügen viele UUCP-Sites gar nicht über IP-Connectivity, wollen aber trotzdem das INN-News-System einsetzen. Für den korrekten Betrieb unter Linux benötigt INN das Loopback-Interface.

    Auflösung von IP-Adressen

    Nachdem Sie nun gesehen haben, wie IP-Adressen aufgebaut sind, werden Sie sich vielleicht fragen, wie diese Adressen in einem Ethernet benutzt werden, um unterschiedliche Hosts anzusprechen. Schließlich verwendet das Ethernet-Protokoll ja eine 6-Byte-Zahl, um einen Host zu identifizieren, die absolut nichts mit der IP-Adresse gemeinsam hat, nicht wahr?

    Richtig. Darum benötigen wir auch einen Mechanismus, der IP-Adressen auf Ethernet-Adressen abbildet. Diesen Mechanismus stellt das sogenannte Address Resolution Protocol, kurz ARP. Tatsächlich ist ARP nicht allein auf Ethernets beschränkt, sondern wird auch bei anderen Netzwerkkarten wie Ham-Radio verwendet. Die ARP zugrunde liegende Idee entspricht genau dem, was die meisten Leute tun, wenn sie einen ihnen unbekannten Menschen, nennen wir ihn einfach mal Karl Kiwi, in einer Gruppe von 150 Menschen herausfinden müssen: Sie gehen herum und rufen den Namen aus, in der Hoffnung, dass er sich meldet.

    Wenn ARP die Ethernet-Adresse ermitteln möchte, die zu einer IP-Adresse gehört, verwendet es eine Ethernet-Eigenschaft, die als »Broadcasting,« bekannt ist. Dabei wird ein Datagramm gleichzeitig an alle Stationen im Netzwerk geschickt. Das von ARP gesendete Broadcast-Datagramm enthält eine Anfrage zur IP-Adresse. Jeder empfangende Host überprüft daraufhin seine eigene Adresse. Stimmt diese mit der empfangenen Adresse überein, wird eine ARP-Antwort an den anfragenden Host zurückgeschickt. Der empfangende Host kann nun aus dieser Antwort die Ethernet-Adresse des Senders extrahieren.

    Sie werden sich nun vielleicht wundern, wie ein Host eine Internet-Adresse ansprechen kann, die sich in einem anderen Ethernet am Ende der Welt befindet bzw. woher der Host überhaupt weiß, dass die Adresse in einem Ethernet liegt. All diese Fragen führen uns zum sogenannten Routing, also dem Ermitteln des physikalischen Standorts eines Host im Netzwerk. Das ist das Thema des folgenden Abschnitts.

    Lassen Sie uns aber zuvor noch etwas mehr über ARP reden. Hat ein Host erst einmal eine Ethernet-Adresse herausgefunden, speichert er diese im ARP-Cache. Auf diese Weise muss keine erneute Anfrage gestartet werden, wenn beim nächsten Mal ein Datagramm an den fraglichen Host geschickt werden soll. Nun wäre es aber nicht besonders klug, diese Information für immer zu speichern. Zum Beispiel könnte die Ethernet-Karte des anderen Host aufgrund technischer Probleme ausgetauscht werden müssen, und somit wäre der ARP-Eintrag ungültig. Darum werden die Einträge im ARP-Cache nach einiger Zeit gelöscht, um eine erneute Anfrage nach der IP-Adresse zu erzwingen.

    Manchmal ist es auch notwendig, die IP-Adresse zu einer bestimmten Ethernet-Adresse zu ermitteln. Das passiert beispielsweise, wenn ein Rechner ohne eigene Festplatte von einem Server über das Netzwerk gebootet werden soll, eine sehr häufige Situation in lokalen Netzwerken. Ein solcher Client verfügt über nahezu keine Informationen über sich selbst -- mit Ausnahme seiner Ethernet-Adresse! Also sendet er eine Broadcast-Nachricht mit der Bitte an alle Boot-Server, ihm seine IP-Adresse mitzuteilen. Dazu existiert ein weiteres Protokoll namens Reverse Address Resolution Protocol, kurz RARP. Zusammen mit dem BOOTP-Protokoll dient es dem Booten von Clients ohne Laufwerk über das Netz.

    IP-Routing

    Wir greifen nun noch einmal die Frage auf, wie der Host, an den Pakete geschickt werden sollen, anhand der IP-Adresse gefunden wird. Verschiedene Teile der Adresse werden auf unterschiedliche Weise gehandhabt; es ist Ihre Aufgabe, entsprechende Dateien einzurichten, die angeben, wie die unterschiedlichen Teile zu handhaben sind.

    IP-Netzwerke

    Wenn Sie einen Brief an jemanden schreiben, versehen Sie den Briefumschlag üblicherweise mit der kompletten Adresse (Land, Postleitzahl, Straße etc.). Dann werfen Sie ihn in den Briefkasten, und die Post liefert ihn ans Ziel, d. h. er wird in das angegebene Land geschickt, wo die nationale Post ihn an die angegebene Adresse liefert. Der Vorteil dieses hierarchischen Schemas ist offensichtlich: An welchem Ort auch immer Sie den Brief aufgeben, der lokale Postangestellte weiß ungefähr, in welche Richtung er den Brief weiterleiten soll, muss sich aber nicht darum kümmern, welchen Weg der Brief nimmt, wenn dieser erstmal das Zielland erreicht hat.

    IP-Netzwerke sind auf dieselbe Art und Weise strukturiert. Das gesamte Internet besteht aus einer Reihe von Netzwerken, die als autonome Systeme bezeichnet werden. Jedes System führt das Routing zwischen den teilnehmenden Hosts intern durch, d. h. die Aufgabe des Ausliefern eines Datagramms wird auf die Suche nach einem Pfad zum Netzwerk des Zielhost reduziert. Das bedeutet, dass, sobald ein Datagramm an einen beliebigen Host innerhalb eines Netzwerks übergeben wird, die weitere Verarbeitung ausschließlich von diesem Netz übernommen wird.

    Subnetze

    Diese Struktur spiegelt sich darin wieder, dass IP-Adressen in einen Host- und einen Netzwerkteil aufgeteilt werden. Per Standardeinstellung wird das Zielnetzwerk aus dem Netzwerkteil der IP-Adresse gewonnen. Hosts mit identischen IP-Netzwerknummern sollten innerhalb desselben Netzwerks zu finden sein, und alle Hosts innerhalb eines Netzwerks sollten dieselbe Netzwerknummer besitzen.(2)

    Es macht Sinn, innerhalb des Netzwerks dasselbe Schema zu verwenden, weil es selbst wieder aus Hunderten kleinerer Netzwerke bestehen kann, bei denen die kleinsten Einheiten physikalische Netzwerke wie Ethernets sind. Aus diesem Grund erlaubt IP die Unterteilung eines IP-Netzwerks in mehrere Unter- oder Subnetze.

    Ein Subnetz übernimmt die Verantwortung für die Übertragung von Datagrammen innerhalb eines bestimmten Bereichs von IP-Adressen des IP-Netzes, dem es angehört. Genau wie bei den Klassen A, B und C wird es über den Netzwerkteil der IP-Adressen identifiziert. Allerdings wird der Netzwerkteil etwas erweitert und enthält nun einige Bits aus dem Host-Teil. Die Anzahl der Bits, die als Subnetznummer interpretiert werden, wird durch die sogenannte Subnetzmaske, oder kurz Netmask, bestimmt. Diese ist ebenfalls eine 32-Bit-Zahl, die die Bitmaske für den Netzwerkteil der IP-Adresse festlegt.

    Das Netzwerk an der Groucho-Marx-Universität ist ein Beispiel für ein solches Netzwerk. Es verwendet die Klasse-B-Netzwerknummer 149.76.0.0, und die Netmask lautet entsprechend 255.255.0.0.

    Intern besteht das Universitätsnetz aus verschiedenen kleineren Netzwerken, wie beispielsweise den LANs der verschiedenen Institute. Also werden die IP-Adressen noch einmal in 254 Subnetze, von 149.76.1.0 bis 149.76.254.0, unterteilt. Dem Institut für theoretische Physik wurde beispielsweise die Nummer 149.76.12.0 zugeteilt. Der Universitäts-Backbone ist ein eigenständiges Netzwerk und besitzt die Nummer 149.76.1.0. Diese Subnetze verwenden dieselbe IP-Netzwerknummer, während gleichzeitig das dritte Oktett verwendet wird, um sie unterscheiden zu können. Sie verwenden also die Subnetzmaske 255.255.255.0.

    Abbildung 2--1 zeigt, wie 149.76.12.4, die Adresse von quark, verschieden interpretiert wird, wenn ein normales Klasse-B-Netzwerk vorliegt bzw. Subnetze verwendet werden.

    Abbildung 2-1. Subnetz bei Klasse-B-Netzwerk

    Es ist wichtig, festzuhalten, dass »Subnetting« (so wird die Technik des Aufbaus von Subnetzen genannt) nur eine interne Aufteilung des Netzwerks ist. Subnetze werden vom Besitzer (oder Administrator) des Netzwerks aufgebaut. Häufig werden Subnetze aufgebaut, um bestehende Grenzen widerzuspiegeln. Diese Grenzen können physikalischer (zwei Ethernets), administrativer (zwei Institute) oder geographischer Natur sein. Die Verantwortung für ein Subnetz wird an eine Kontaktperson delegiert. Diese Struktur wirkt sich allerdings nur auf das interne Verhalten des Netzwerks aus und ist nach außen hin völlig unsichtbar.

    Gateways

    Subnetting ist nicht nur organisatorisch von Vorteil, es ist häufig auch die natürliche Konsequenz aus bestehenden Hardwaregrenzen. Die Sichtweise eines Hosts in einem bestehenden Netzwerk, beispielsweise einem Ethernet, ist sehr beschränkt: Die einzigen Hosts, mit denen er sich unterhalten kann, sind die Hosts, die sich in dem gleichen Netz befinden wie er selbst. Alle anderen Hosts können nur über sogenannte Gateways erreicht werden. Ein Gateway ist ein Host, der an zwei oder mehr physikalische Netze gleichzeitig angeschlossen ist. Er ist so konfiguriert, dass er Pakete zwischen diesen Netzen hin und her übertragen kann.

    Damit IP einfach unterscheiden kann, ob ein Host in einem lokalen physikalischen Netzwerk präsent ist, müssen verschiedene physikalische Netzwerke verschiedenen IP-Netzwerken angehören. Beispielsweise ist die Netzwerknummer 149.76.4.0 für die Hosts des LANs des mathematischen Instituts reserviert. Wird ein Datagramm an quark geschickt, erkennt die Netzwerk-Software auf erdos sofort anhand der IP-Adresse 149.76.12.4, dass der Zielhost sich in einem anderen physikalischen Netzwerk befindet und daher nur durch ein Gateway erreicht werden kann (sophus per Standardeinstellung).

    sophus selbst ist mit zwei verschiedenen Subnetzen verbunden: dem des mathematischen Instituts und dem des Universitäts-Backbones. Jedes wird über ein eigenes Interface (eth0 bzw. fddi0) erreicht. Nun, welche IP-Adresse sollen wir ihm zuweisen? Sollen wir ihm eine auf dem Subnetz 149.76.1.0 oder auf 149.76.4.0 zuweisen?

    Die Antwort lautet: auf beiden. Wird ein Host im Mathe-LAN angesprochen, soll sophus die IP-Adresse 149.76.4.1 verwenden, wird ein Host auf dem Backbone angesprochen, soll 149.76.1.4 verwendet werden.

    Einem Gateway wird also auf jedem Netzwerk, an dem es hängt, eine IP-Adresse zugewiesen. Diese Adressen -- zusammen mit der entsprechenden Netmask -- ergeben gemeinsam die Schnittstelle, über die auf das Subnetz zugegriffen wird. Die Abbildung von Schnittstellen auf Adressen für sophus würde also wie in der Tabelle auf der folgenden Seite aussehen.

    Code
    1. ------------------------------------
    2. Interface Adresse Netmask ------------------------------------
    3. eth0 149.76.4.1 255.255.255.0
    4. fddi0 149.76.1.4 255.255.255.0
    5. lo 127.0.0.1 255.0.0.0
    6. ------------------------------------

    Der letzte Eintrag beschreibt das Loopback-Interface lo, das bereits vorgestellt wurde.

    Abbildung 2--2 zeigt einen Ausschnitt der Netzwerk-Topologie an der Groucho-Marx-Universität (GMU). Hosts, die auf zwei Subnetzen zur gleichen Zeit präsent sind, sind mit beiden Adressen aufgeführt.

    Abbildung 2-2. Ein Ausschnitt der Netzwerk-Topologie an der Groucho-Marx-Universität

    Im allgemeinen können Sie den feinen Unterschied zwischen der Zuweisung einer Adresse an einen Host oder an sein Interface ignorieren. Bei Hosts wie erdos, die nur zu einem Netz gehören, spricht man im allgemeinen immer von dem Host mit dieser oder jener IP-Adresse, obwohl es genaugenommen die Ethernet-Schnittstelle ist, der diese IP-Adresse zugewiesen wurde. Andererseits ist diese Unterscheidung nur bei Gateways wirklich von Bedeutung.

    Die Routing-Tabelle

    Wir richten nun unsere Aufmerksamkeit darauf, wie IP ein Gateway auswählt, wenn es ein Datagramm an ein entferntes Netzwerk ausliefert.

    Wir haben bereits gesehen, dass erdos, wenn es ein Datagramm für quark erhält, die Zieladresse überprüft und entdeckt, dass sich diese nicht im lokalen Netz befindet. Aus diesem Grund sendet erdos das Datagramm an das Default-Gateway (sophus), das sich nun vor die gleiche Aufgabe gestellt sieht. sophus erkennt, dass sich quark nicht in einem der Netzwerke befindet, mit denen es direkt verbunden ist. Es muss also ein weiteres Gateway finden, an das es das Datagramm weiterleiten kann. Die richtige Wahl wäre niels, das Gateway des physikalischen Instituts. Daher benötigt sophus einige Informationen, um zu wissen, welche Zielnetze über welche Gateways zu erreichen sind.

    Die Routing-Informationen, die IP dabei verwendet, sind in einer Tabelle zu finden, die Netzwerke mit Gateways verbindet, über die sie zu erreichen sind. Ein sog. Catch-All-Eintrag (die Default Route) muss ebenfalls vorhanden sein. Dieses Gateway wird mit dem Netzwerk 0.0.0.0 assoziiert. Alle Pakete, die an ein unbekanntes Netzwerk gehen, werden über dieses Gateway verschickt. Auf sophus würde die Tabelle also wie folgt aussehen:

    Code
    1. ---------------------------------
    2. Netzwerk Gateway Interface
    3. ---------------------------------
    4. 149.76.1.0 - fddi0 149.76.2.0 149.76.1.2 fddi0 149.76.3.0 149.76.1.3 fddi0 149.76.4.0 - eth0 149.76.5.0 149.76.1.5 fddi0 … … … 0.0.0.0 149.76.1.2 fddi0 ---------------------------------

    Routen zu einem Netzwerk, mit dem sophus direkt verbunden ist, benötigen kein Gateway. In der Gateway-Spalte steht an dieser Stelle ein Bindestrich.

    Routing-Tabellen können auf unterschiedliche Weise aufgebaut werden. Bei kleineren LANs ist es wahrscheinlich am effektivsten, die Tabelle von Hand zu erstellen und sie dann während der Boot-Phase mit Hilfe des route-Befehls (siehe Die ARP-Tabelle) an IP zu übergeben. Bei größeren Netzwerken werden sie zur Laufzeit von sog. Routing-Dämonen erzeugt und eingerichtet. Diese Dämonen laufen auf zentralen Hosts des Netzwerks und tauschen untereinander Routing-Informationen aus, um die »optimalen« Routen zwischen den teilnehmenden Netzwerken zu berechnen.

    Abhängig von der Größe des Netzwerks werden verschiedene Routing-Protokolle verwendet. Für das Routing innerhalb autonomer Systeme (wie der Groucho-Marx-Universität) werden die internen Routing-Protokolle verwendet. Das bekannteste dieser Protokolle ist RIP, oder Routing Information Protocol, das im BSD routed-Daemon implementiert ist. Das Routing zwischen autonomen Systemen muss durch externe Routing-Protokolle wie EGP (External Gateway Protocol) oder BGP (Border Gateway Protocol) erledigt werden. Diese wurden (ebenso wie RIP) im gated-Daemon(3) der University of Cornell implementiert.

    Metrische Werte

    Beim auf RIP basierenden dynamischen Routing wird der beste Weg zu einem Zielhost oder -Netzwerk anhand der Anzahl der »Hops,« gewählt, d. h. anhand der Zahl von Gateways, die ein Datagramm passieren muss, bevor es sein Ziel erreicht hat. Je kürzer die Route ist, desto besser wird sie von RIP bewertet. Sehr lange Routen von 16 oder mehr Hops werden als unbrauchbar betrachtet und verworfen.

    Soll RIP verwendet werden, um die für Ihr lokales Netzwerk anfallenden Routing-Informationen zu verwalten, muss auf allen Hosts gated laufen. Während des Bootens prüft gated alle aktiven Netzwerk-Interfaces. Existiert mehr als eine aktive Schnittstelle (das Loopback-Interface nicht mitgezählt), nimmt es an, dass der Host als Gateway fungiert, und gated verteilt aktiv Routing-Informationen. Anderenfalls verhält es sich passiv und empfängt nur eingehende RIP-Updates, um die lokale Routing-Tabelle zu aktualisieren.

    Wenn gated die Daten aus der lokalen Routing-Tabelle verteilt, berechnet es die Länge der Route anhand einer sogenannten Metrik, die Teil des Eintrags in der Routing-Tabelle ist. Dieser Wert wird vom Systemadministrator während der Konfiguration der Route eingetragen und sollte die Kosten bezüglich der Verwendung dieser Route wiederspiegeln. Die Metrik einer Route zu einem Subnetz, mit dem der Host direkt verbunden ist, sollte also immer null sein, während ein Weg, der über zwei Gateways führt, einen Wert von zwei haben sollte. Andererseits müssen Sie sich um diese Werte keine Gedanken machen, wenn Sie RIP oder gated nicht verwenden.

    Das Internet Control Message Protocol

    IP hat noch ein verwandtes Protokoll, über das wir bisher noch nicht gesprochen haben. Dieses Internet Control Message Protocol (ICMP) genannte Protokoll wird vom Netzwerk-Kode des Kernel verwendet, um Fehlermeldungen und ähnliches an andere Hosts weiterzugeben. Nehmen wir beispielsweise an, dass Sie mal wieder vor erdos sitzen und über telnet auf Port 12345 auf quark zugreifen wollen. Leider existiert dort kein Prozess, der an diesem Port horcht. Wenn das erste TCP-Paket für diesen Port bei quark ankommt, erkennt die Netzwerkschicht dies sofort und sendet umgehend eine ICMP-Message an erdos zurück, um mitzuteilen, daß der Port nicht erreichbar ist (»Port Unreachable«).

    Es gibt eine ganze Reihe von Nachrichten, die ICMP versteht; viele davon beschäftigen sich mit Fehlerbedingungen. Darunter befindet sich auch eine sehr interessante, »Redirect Message« genannte Nachricht. Diese wird vom Routing-Modul erzeugt, wenn es erkennt, dass es von einem anderen Host als Gateway verwendet wird, obwohl es einen wesentlich kürzeren Weg gibt. Beispielsweise könnte die Routing-Tabelle von sophus nach dem Booten unvollständig sein. Die Tabelle könnte die Routen zum Mathe-Netzwerk, dem FDDI-Backbone und die Default Route enthalten, die auf das Gateway gcc1 des Universitäts-Rechenzentrums weist. Alle Pakete, die für quark bestimmt sind, würden also an gcc1 geschickt werden, und nicht an niels, das Gateway des physikalischen Instituts. Empfängt es ein solches Datagramm, bemerkt gcc1, dass dies eine schlechte Route ist und leitet das Paket an niels weiter, während gleichzeitig eine ICMP-Redirect-Nachricht an sophus gesandt wird, die dem Rechner die bessere Route mitteilt.

    Nun sieht das vielleicht nach einer sehr cleveren Methode aus, mit der Sie vermeiden können, alle außer den grundlegenden Routen von Hand einzutragen. Seien Sie aber gewarnt, dass es nicht immer eine gute Idee ist, sich auf dynamische Routing-Schemata zu verlassen -- egal ob RIP oder ICMP-Redirects. ICMP-Redirect und RIP bieten Ihnen gar keine oder nur geringe Möglichkeiten, die Echtheit der empfangenen Routing-Informationen zu überprüfen. Auf diese Weise könnten bösartige Taugenichtse Ihr gesamtes Netz lahmlegen oder noch schlimmeres tun. Aus diesem Grund behandelt der Netzwerk-Kode des Kernels Redirect-Messages für Netzwerkrouten so, als wären es nur Redirects für Host-Routen.

    Das Domain Name System

    Auflösung von Hostnamen

    Wie bereits beschrieben, dreht sich bei der Adressierung von TCP/IP-Netzwerken alles um 32-Bit-Zahlen. Es wird Ihnen aber wahrscheinlich schwer fallen, sich mehr als ein paar dieser Nummern zu merken. Aus diesem Grund sind Hosts im allgemeinen unter einem »normalen« Namen wie gauss oder strange bekannt. Es gehört zu den Pflichten der Anwendung, die zu diesem Namen gehörende IP-Adresse zu ermitteln. Dieser Prozess wird als »Auflösung des Hostnamens« oder Hostname Resolution bezeichnet.

    Muss ein Programm die IP-Adresse eines bestimmten Host ermitteln, ist es auf die Bibliotheksfunktionen gethostbyname(3) und gethostbyaddr(3) angewiesen. Diese und eine Reihe verwandter Funktionen werden traditionell in einer separaten Bibliothek (der sog. Resolver Library) gespeichert, unter Linux sind sie aber Teil der Standard libc-Bibliothek. Im allgemeinen Sprachgebrauch wird diese Sammlung von Funktionen »der Resolver« genannt.

    Nun ist es bei einem kleinen Netzwerk wie einem Ethernet, ja selbst bei einem Cluster solcher Netze, nicht besonders schwer, die Tabellen zu verwalten, mit denen die Hostnamen auf Adressen abgebildet werden. Diese Informationen werden üblicherweise in einer Datei namens /etc/hosts gespeichert. Wenn Sie einen Host hinzufügen oder entfernen, müssen Sie nur die hosts-Dateien auf allen Hosts entsprechend korrigieren. Das wird natürlich sehr mühsam in Netzwerken, die sich aus mehr als einer Handvoll Rechnern zusammensetzen.

    Eine Lösung für dieses Problem ist das von Sun Microsystems entwickelte NIS, oder Network Information System, das im allgemeinen Sprachgebrauch auch YP oder Yellow Pages (also »Gelbe Seiten«) genannt wird. NIS speichert die hosts-Datei (und andere Informationen) in einer Datenbank auf einem Masterhost, vom dem Clients die Informationen im Bedarfsfall abrufen. Dennoch ist diese Lösung nur für Netzwerke mittlerer Größe, z. B. LANs, anwendbar, weil sie die Verwaltung der gesamten hosts-Datenbank durch eine zentrale Instanz erfordert, von der aus die Daten dann an alle Server verteilt werden müssen.

    Auch im Internet wurden zu Beginn alle Adress-Informationen in einer einzigen Datenbank namens HOSTS.TXT gespeichert. Diese Datei wurde vom »Network Information Center«, kurz NIC, verwaltet und musste von allen teilnehmenden Sites heruntergeladen und installiert werden. Als das Netzwerk wuchs, traten verschiedene Probleme mit diesem Schema auf. Neben dem administrativen Aufwand, der mit der regelmäßigen Installation von HOSTS.TXT verbunden war, wurde die Last auf den diese Datei verteilenden Servern zu hoch. Noch schwerwiegender war das Problem, dass alle Namen beim NIC registriert werden mussten, um sicherzustellen, dass Namen nicht doppelt verwendet wurden.

    Aus diesen Gründen wurde im Jahr 1984 ein neues Schema für die Auflösung von Adress-Namen eingeführt, das sogenannte Domain Name System. DNS wurde von Paul Mockapetris entwickelt und widmete sich beiden Problemen. Es wird ausführlich in DNS and BIND von Paul Albitz und Cricket Liu beschrieben. Die eigentliche Definition findet sich in den RFCs 1033, 1034 und 1035.

    Einstieg in DNS

    DNS organisiert Hostnamen in einer Hierarchie von Domänen (engl. Domains). Eine Domain ist eine Sammlung von Sites, die in irgendeiner Weise zusammengehören -- sei es, dass sie ein Netzwerk bilden (z. B. alle Maschinen der Universität oder alle Hosts im BITNET), weil sie einer bestimmten Organisation (z. B. der Regierung) angehören, oder einfach, weil sie geographisch nah beieinander liegen. Beispielsweise werden in den USA Universitäten in der Domain edu zusammengefasst, wobei jede Universität bzw. jedes College nochmal unter einer Unterdomain (Subdomain) zusammengefaßt wird. Die Groucho-Marx-Universität könnte die Domain groucho.edu bekommen, wobei dem mathematischen Institut der Name maths.groucho.edu zugewiesen würde. Bei Hosts im Netzwerk des Instituts würde der Domainname einfach an den Hostnamen angehängt, d. h. erdos wäre als erdos.maths.groucho.edu bekannt. Solch ein Name wird als »voll qualifizierter Domainname« (fully qualified domain name, kurz FQDN) bezeichnet, weil er den Host weltweit eindeutig identifiziert.

    Abbildung 2-3. Ein Ausschnitt des Domain-Namensraums

    Abbildung 2--3 zeigt einen Ausschnitt aus dem Namensraum (Name Space). Der Eintrag an der Wurzel dieses Baums, der durch einen einzelnen Punkt symbolisiert wird, wird passenderweise Root Domain genannt und umfasst alle anderen Domains. Um zu verdeutlichen, dass ein gegebener Hostname ein voll qualifizierter Domainname, und nicht nur ein in einem relativen Verhältnis zu irgendeiner lokalen Domain stehender Name ist, wird ihm manchmal ein Punkt angehängt. Das verdeutlicht, dass der letzte Teil des Namens die Root-Domain bedeutet.

    Abhängig von ihrer Position in der Namenshierarchie wird eine Domain als Top-Level, Second-Level oder Third-Level bezeichnet. Weitere Unterteilungen können zwar vorkommen, sind aber selten. Verschiedenen Top-Level-Domains werden Sie häufiger begegnen:

    edu / (Meist U.S.-amerikanische) Bildungseinrichtungen wie Universitäten etc.

    com / Kommerzielle Organisationen und Unternehmen.

    org / Nichtkommerzielle Organisationen. Private UUCP-Netzwerke sind häufig in dieser Domain zu finden.

    net / Gateways und andere administrative Hosts in einem Netzwerk.

    mil / Militärische Einrichtungen der US-Armee.

    gov / US-amerikanische Regierungsbehörden.

    uucp / Diese Domain enthält offiziell die Namen aller UUCP-Sites, die keinen vollständigen Domainnamen haben. Sie wird aber kaum noch verwendet.


    Technisch gesehen, gehören die vier erstgenannten Domains zum U.S.-amerikanischen Teil des Internet. Nichtsdestotrotz können Sie in diesen Domänen auch Sites aus der restlichen Welt begegnen. Dies trifft vor allem auf die net-Domain zu. Nur mil und gov werden ausschließlich in den USA benutzt.

    Außerhalb der USA besitzt jedes Land eine eigene Top-Level-Domain. Genutzt wird dabei der aus zwei Buchstaben bestehende Ländercode nach ISO-3166. Finnland nutzt beispielsweise die fi-Domain; fr wird von Frankreich genutzt, de von Deutschland und au von Australien. Unterhalb dieser Domain kann das NIC des jeweiligen Landes die Hostnamen nach Gutdünken organisieren. Zum Beispiel arbeitet Australien mit einer Second-Level-Domain, die sich an den internationalen Top-Level-Domains orientiert, also com.au, edu.au und so weiter. Andere, darunter auch Deutschland, benutzen diese zusätzliche Ebene nicht, arbeiten aber mit etwas längeren Namen, die direkt auf die Organisationen hinweisen, die eine bestimmte Domain betreiben. Beispielsweise sind Hostnamen wie ftp.informatik.uni-erlangen.de nicht unüblich. Schreiben Sie's der deutschen Tüchtigkeit zu.

    Auf der anderen Seite deuten solche nationalen Domains nicht zwangsläufig an, dass ein Host in dieser Domain auch tatsächlich in diesem Land steht. Es bedeutet nur, dass der Host beim NIC dieses Landes registriert wurde. Ein schwedischer Hersteller könnte in Australien eine Niederlassung betreiben, aber trotzdem alle Hosts unter der Top-Level-Domain se registrieren.

    Die Organisation von Namen in einer Hierarchie von Domains löst auch das Problem der Eindeutigkeit von Namen sehr elegant. Bei DNS muss ein Hostname nur innerhalb einer Domain eindeutig sein, und schon ist sichergestellt, dass er sich von allen anderen Hosts weltweit unterscheidet. Mehr noch, voll qualifizierte Namen sind einfacher zu merken. Alle diese Argumente sind für sich genommen schon Grund genug, eine große Domain in mehrere Subdomains aufzuteilen.

    Aber DNS tut noch mehr für Sie. Es erlaubt Ihnen, die Verwaltung einer Subdomain auf deren Administratoren zu übertragen. Beispielsweise könnten die Betreiber am Groucho-Rechenzentrum eine Subdomain für jedes Institut einrichten. Die Subdomains math und physics haben Sie ja bereits kennengelernt. Wenn sich nun herausstellen sollte, dass das Netzwerk am physikalischen Institut zu groß und zu chaotisch ist, um es von außen zu verwalten (Physiker sind schließlich als ein etwas ungebärdiger Menschenschlag bekannt), könnten sie die Kontrolle über die Domain physics.groucho.edu einfach an die Administratoren dieses Netzwerks übergeben. Die Administratoren könnten beliebige Hostnamen verwenden und entsprechende IP-Adressen vergeben, ohne dass sich von außen jemand einmischte.

    Zu diesem Zweck wird der Namensraum in Zonen aufgeteilt, die jeweils in der entsprechenden Domain wurzeln. Beachten Sie den feinen Unterschied zwischen einer Zone und einer Domain: Die Domain groucho.edu umfasst alle Hosts der Groucho-Marx-Universität, während die Zone groucho.edu nur die Hosts einschließt, die direkt vom Rechenzentrum verwaltet werden, also beispielsweise die vom mathematischen Institut. Die Hosts am physikalischen Institut gehören einer anderen Zone, namentlich physics.groucho.edu an. In Abbildung 2--3 wird der Beginn einer Zone durch einen kleinen Kreis rechts neben dem Domainnamen markiert.

    Namenssuche (Name Lookup) mit DNS

    Auf den ersten Blick macht das ganze Theater mit Domains und Zonen die Auflösung von Namen zu einer furchtbar komplizierten Angelegenheit. Wenn also keine zentrale Stelle kontrolliert, welche Namen an welche Hosts vergeben wurden, wie soll dann eine einfache Anwendung das herausfinden?!

    Nun kommt der wirklich geniale Teil von DNS. Wenn Sie die IP-Adresse von erdos ermitteln wollen, sagt Ihnen DNS, dass Sie sich an die Leute wenden sollen, die den Host verwalten, und die werden Ihnen das schon mitteilen.

    Tatsächlich ist DNS eine gigantische verteilte Datenbank. Es setzt sich aus einer Menge von sogenannten Name-Servern zusammen, die Informationen über eine oder mehrere Domains liefern. Jede Zone besitzt mindestens zwei, meist mehrere Name-Server, die alle benötigten Informationen zu den Hosts in dieser Zone enthalten. Um die IP-Adresse von erdos zu ermitteln, müssen Sie nur den Name-Server der Zone groucho.edu ansprechen, der Ihnen die benötigten Daten zurückliefert.

    Einfacher gesagt, als getan, werden Sie denken. Wie weiß ich, wie der Name-Server an der Groucho-Marx-Universität zu erreichen ist? Für den Fall, dass Ihr Computer nicht mit dem Orakel zur Auflösung von Adressen ausgestattet ist, hilft Ihnen DNS auch hier. Wenn Ihre Anwendung Informationen über erdos ermitteln muss, tritt es an den lokalen Name-Server heran, der eine sogenannte iterative Anfrage durchführt. Er beginnt mit einer Anfrage an einen Name-Server für die Root-Domain, bei dem er nach der Adresse für erdos.maths.groucho.edu nachfragt. Der Root-Name-Server erkennt, dass die Adresse nicht in seine Zuständigkeitszone fällt, sondern in eine unterhalb der edu-Domain. Er teilt Ihnen daraufhin mit, für weitere Informationen einen Name-Server für die edu-Zone anzusprechen, und liefert Ihnen eine Liste aller edu-Name-Server, zusammen mit deren Adressen gleich mit. Ihr lokaler Name-Server geht dann hin und fragt einen dieser Server, beispielsweise a.isi.edu. Auf ähnliche Weise wie der Root-Name-Server weiß a.isi.edu, daß die groucho.edu-Leute eine eigene Zone betreiben, und zeigt auf die entsprechenden Server. Der lokale Name-Server richtet seine Anfrage nach erdos nun an einen dieser Server, der erkennt, dass der Name zu seiner Zone gehört, und dieser liefert nun endlich die entsprechende IP-Adresse zurück.

    Das sieht nach einer ganzen Menge zu übertragender Daten aus, nur um eine mickrige IP-Adresse in Erfahrung zu bringen, ist aber minimal, verglichen mit der Datenmenge, die übertragen werden müsste, wenn Sie immer noch mit HOSTS.TXT herumhantieren müssten. Andererseits bietet dieses Schema immer noch genügend Platz für Verbesserungen.

    Um die Antwortzeiten bei zukünftigen Anfragen zu verringern, speichert der Name-Server die gewonnenen Informationen in seinem lokalen Cache. Das nächste Mal, wenn jemand in Ihrem lokalen Netz die Adresse eines Host der Domain groucho.edu benötigt, muss Ihr Name-Server den ganzen Prozess nicht von vorne beginnen, sondern tritt direkt mit dem Name-Server von groucho.edu in Kontakt.(4)

    Der Name-Server speichert diese Informationen nun aber nicht für immer, sondern rangiert sie nach einer bestimmten Zeit wieder aus. Die Zeitspanne, nach der eine Information ungültig wird, wird Time to live, kurz TTL genannt. Jedem Eintrag in der DNS-Datenbank wird eine solche TTL vom für die Zone verantwortlichen Administrator zugewiesen.

    Domain-Name-Server

    Name-Server, die alle Informationen zu den Hosts einer Zone gespeichert haben, besitzen die Autorität für diese Zone und werden manchmal auch als Master-Name-Server bezeichnet. Jede Anfrage nach einem Host in dieser Zone endet letztendlich bei einem dieser Master-Name-Server.

    Um ein in sich geschlossenes Bild einer Zone zu liefern, müssen die Master-Server entsprechend gut synchronisiert sein. Dies wird erreicht, indem man einen der Server als primären Server einrichtet, der seine Zonen-Informationen aus entsprechenden Dateien bezieht, während man die anderen als sekundäre Server einrichtet, die die Zonendaten in regelmäßigen Abständen vom primären Server übertragen.

    Ein Grund für die Verwendung mehrerer Name-Server liegt in der Verteilung der anfallenden Arbeit, ein anderer in der Redundanz. Fällt ein Name-Server aus irgendeinem Grund aus (z. B. durch einen Absturz oder eine Unterbrechung der Netzwerk-Verbindung), verteilen sich alle Anfragen auf die verbliebenen Server. Natürlich schützt Sie dieses Schema nicht vor Fehlfunktionen der Server (beispielsweise durch Bugs im Server-Programm selbst), die falsche Antworten auf alle DNS-Anfragen produzieren.

    Natürlich ist auch ein Name-Server denkbar, der keine Autorität für eine Domain besitzt.(5) Eine solche Art Server ist dennoch nützlich, weil er trotzdem in der Lage ist, DNS-Anfragen für Anwendungen im lokalen Netz durchzuführen und die Informationen zu cachen. Er wird daher als Caching-Only-Server bezeichnet.

    Die DNS-Datenbank

    Sie haben gesehen, dass DNS nicht nur mit IP-Adressen für Hosts hantiert, sondern auch Informationen über Name-Server austauscht. In der Tat kann eine DNS-Datenbank eine ganze Reihe unterschiedlicher Einträge enthalten.

    Eine einzelne Informationseinheit in einer DNS-Datenbank wird Resource Record, oder kurz RR genannt. Zu jedem Record gehört ein Typ, der die Art der enthaltenen Daten beschreibt, und eine Klasse, die den Netzwerktyp beschreibt, für den der Record gilt. Letzteres ist nötig, um unterschiedliche Adress-Schemata zu unterstützen, wie beispielsweise

    IP-Adressen (IN-Klasse) oder Hesiod-Adressen (verwendet vom Kerberos-System des MIT) und einige mehr. Der Prototyp eines Resource Records ist der A-Record, bei dem ein voll qualifizierter Domainname mit einer IP-Adresse assoziiert ist.

    Natürlich kann ein Host mehr als einen Namen besitzen. Dabei muss aber einer dieser Namen der offizielle oder kanonische Hostname sein, während die anderen einfach nur Aliase sind, die auf diesen Namen zeigen. Der Unterschied liegt darin, dass der kanonische Hostname einen entsprechenden A-Record besitzt, während die anderen nur einen Record vom Typ CNAME verwenden, der auf den kanonischen Hostnamen zeigt.

    Wir behandeln an dieser Stelle nicht alle Record-Typen, sondern heben sie uns für ein späteres Kapitel auf, und geben Ihnen hier nur ein kurzes Beispiel. Beispiel 2--1 zeigt einen Ausschnitt aus der Domain-Datenbank, die in die Name-Server für die Zone physics.groucho.edu geladen wird. Beispiel 2-1. Ein Auszug aus der Datei named.hosts für das physikalische Institut

    Neben den A- und CNAME-Records erkennen Sie am Anfang der Datei einen speziellen Record, der sich über mehrere Zeilen hinzieht. Dies ist der sogenannte SOA-Resource Record (Start Of Authority), der allgemeine Informationen zu der Zone enthält, für die der Server Autorität besitzt. Dazu gehört beispielsweise die Default-TTL für alle Records.

    Beachten Sie, dass alle Namen in der Beispieldatei, die nicht mit einem Punkt enden, relativ zur Domain groucho.edu interpretiert werden. Der spezielle Name »@« der beim SOA-Record genutzt wird, ist eine Abkürzung für den Domainnamen selbst.

    Sie haben oben gesehen, dass die Name-Server für die Domain groucho.edu irgendwie etwas über die Zone physics erfahren müssen, damit bei Anfragen (Queries) an die entsprechenden Name-Server verwiesen werden kann. Dies wird üblicherweise durch ein Paar von Records erreicht: dem NS-Record, der die FDQN des Servers enthält, und einem A-Record, der die Adresse für diesen Namen enthält. Diese Records halten den Namensraum zusammen und werden daher im Amerikanischen häufig als Glue Records bezeichnet. Sie sind die einzigen Beispiele für Records, bei denen eine übergeordnete Zone Informationen zu einer untergeordneten Zone enthält. Die auf die Name-Server für physics.groucho.edu zeigenden Records sind in Beispiel 2--2 aufgeführt.

    Code
    1. Beispiel 2-2. Auszug aus der Datei named.hosts der GMU ;Zonen-Daten für die Zone groucho.edu. @ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. { 940701 ; Seriennummer 360000 ; aktualisieren 3600 ; erneuter Versuch 3600000 ; ausrangieren 3600 ; TTL-Standardeinstellung } .... ; ; Glue Records für die Zone physics.groucho.edu physics IN NS niels.physics.groucho.edu. IN NS gauss.maths.groucho.edu. niels.physics IN A 149.76.12.1 gauss.maths IN A 149.76.4.23 ...

    Reverse Lookup

    Neben der Ermittlung einer IP-Adresse eines bestimmten Host ist es manchmal auch notwendig, den kanonischen Hostnamen zu bestimmen, der zu einer bestimmten Adresse gehört. Dies wird als Reverse Mapping bezeichnet und wird von verschiedenen Netzwerkdiensten genutzt, um die Identität eines Client zu überprüfen. Wenn Sie nur mit einer hosts-Datei arbeiten, wird diese Datei bei einem Reverse Lookup einfach nach einem Host durchsucht, dem die fragliche IP-Adresse gehört. Mit DNS steht eine ausführliche Suche im Namensraum natürlich außer Frage. Statt dessen wurde eine spezielle Domain eingerichtet (in-addr.arpa), die die IP-Adressen aller Hosts in umgekehrter »Dotted Quad Notation« enthält. Beispielsweise entspricht die IP-Adresse 149.76.12.4 dem Namen 4.12.76.149.in-addr.arpa. Der Resource Record-Typ, der diese Namen mit den entsprechenden kanonischen Hostnamen verbindet, ist PTR.

    Das Einrichten einer Autoritätszone bedeutet üblicherweise auch, dass den Administratoren die vollständige Kontrolle darüber gegeben wird, wie sie Adressen an Namen zuweisen. Weil sie dabei üblicherweise mit einem oder mehreren IP-Netzwerken oder Subnetzen hantieren, kommt es zu einer Eins-auf-viele-Abbildung zwischen DNS-Zonen und IP-Netzwerken. Zum Beispiel umfasst das physikalische Institut die Subnetze 149.76.8.0, 149.76.12.0 und 149.76.14.0.

    Als Konsequenz daraus müssen neue Zonen in der in-addr.arpa-Domain zusammen mit der physics-Zone eingerichtet und an die Netzwerk-Administratoren des Instituts delegiert werden: 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa und 14.76.149.in-addr.arpa. Anderenfalls müsste bei der Installation eines neuen Host im Collider Lab die Administration der übergeordneten Domain benachrichtigt und die neuen Adressen müssten in deren in-addr.arpa-Zonendatei eingetragen werden.

    Die Zonendatenbank für Subnetz 12 ist in Beispiel 2--3 zu sehen. Die entsprechenden Glue Records in der Datenbank ihrer übergeordneten Zonen sind in Beispiel 2--4 abgebildet.

    Beispiel 2-3. Ausschnitt aus der Datei named.rev für Netzwerk 149.76

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

    Beispiel 2-4. Ausschnitt aus der Datei named.rev für Subnetz 12


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

    bomb_2.gif



    Eine wichtige Konsequenz des in-addr.arpa-Systems ist, dass Zonen nur als Obermengen von IP-Netzwerken eingerichtet werden können und, was noch wichtiger ist, dass die Netmasken dieser Netzwerke an Byte-Grenzen ausgerichtet sein müssen. Alle Subnetze an der Groucho-Marx-Universität verwenden die Netmask 255.255.255.0, damit eine in-addr.arpa-Zone für jedes Subnetz eingerichtet werden kann. Wäre statt dessen die Netmask 255.255.255.128 verwendet worden, wäre die Einrichtung von Zonen für das Subnetz 149.76.12.128 unmöglich, weil es keine Möglichkeit gibt, DNS mitzuteilen, dass die 12.76.149.in-addr.arpa-Domain in zwei Autoritätszonen mit Hostnamen von 1 bis 127 und von 128 bis 255 aufgeteilt wurde.



    Aus einer älteren Version hier im Forum heraus, neu aufgesetzt und mit freundlicher Unterstützung:


    Copyright © 1996 by O'Reilly Verlag


    Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.


    Inhaltsverzeichnis