Intranet in Team

herausgegeben von Oliver Mark

Kapitel 3 (Auszug)

Dienste

DHCP - Dynamic Host Configuration Protocol

Wer schon einmal ein TCP/IP-Netzwerk mit, sagen wir, mehr als drei Arbeitsstationen betreut hat und eines Tages den Internetprovider gewechselt hat, hat vielleicht eine Idee von der Problematik, mit der sich Netzwerkadministratoren in großen IP-Netzwerken herumschagen müssen: Wie ändere ich IP-Konfigurationsparameter, ohne mich an jeden Arbeitsplatz zu begeben?

Wahrscheinlich ließe sich die Aufgabe auch mit Softwareverteilungsmechanismen erledigen, aber in heterogenen Netzwerken - und in welchem Netzwerk wird auf den Arbeitsstationen heute nur ein Betriebssystem eingesetzt? - heißt die Antwort heute schlicht und einfach »DHCP«.

»DHCP« steht für »Dynamic Host Configuration Protocol« und stellt in TCP/IP-Netzwerken einen Mechanismus zur dynamischen Zuweisung von IP-Adressen und anderen TCP/IP-bezogenen Konfigurationsparametern an die angeschlossenen Computersysteme, im folgenden Clients genannt, zur Verfügung.

Konkret heißt das, daß alle für den TCP/IP-Client relevanten Informationen an zentraler Stelle definiert werden können und eine lokale Konfiguration des TCP/IP-Protokolls unnötig ist.

DHCP reduziert den Administrationsaufwand von TCP/IP-Clients extrem. Wenn der Begriff »Plug&Play« durch negative Erfahrungen in der letzten Zeit nicht so negativ belegt wäre, würde ich den Einsatz von DHCP als den Weg zu einem Plug&-Play-TCP/IP-Netzwerk bezeichnen. In einem IP-Netzwerk mit DHCP-Server braucht ein TCP/IP-Client nur noch an das physikalische Netz angeschlossen zu werden und kann sofort loslegen. Je nach Auslastung des Netzwerkadministrators empfiehlt sich der Einsatz von DHCP ab etwa drei Arbeitsstationen.

Geschichtliches und Formelles

DHCP ist ein »Internet-Standard« und also in einem »Request for Comment«, kurz RFC, beschrieben. Der RCF 2131 enthält die Spezifikationen für DHCP; RFC 2132 enthält die Beschreibung der Konfigurationsoptionen, die einem Client mitgeteilt werden können. Nicht alle Client-Betriebssysteme unterstützen alle Optionen.

Das Dynamic Host Configuration Protocol wird von der Dynamic Host Configuration Working Group (DHCWG) der Internet-Instanz Internet Engineering Task Force (IETF) betreut.

DHCP wird selbstverständlich kontinuierlich weiterentwickelt. Integration mit Novells NDS und Netware/IP, Posix-Timezone-Ergänzungen, Serverauswahloptionen und Multicast-Erweiterungen sind als Beispiele zu nennen. Demzufolge muß auch die DHCP-Client/Server-Software weiterentwickelt werden.

Geschichtliche »Vorläufer« von DHCP sind BOOTP und RARP. DHCP ist, was die Klassifikation durch die IETF und das Internet Activities Board (IAB) angeht, mit dem Attribut »elective«, also wahlweise, versehen, während BOOTP das Attribut »recommended«, also empfohlen, trägt. DHCP ist die Weiterentwicklung oder Erweiterung des Bootstrap Protocol, BOOTP, welches unter anderem einen höheren Definitionsaufwand pro Client am Server erfordert. RARP (Reverse Address Resolution Protocol) ist von der Firma Sun Microsystems eingeführt worden und kann, im Gegensatz zu BOOTP (und damit DHCP), nicht über LAN-Segmentgrenzen hinweg eingesetzt werden.

Grundsätzliches

Um in einem TCP/IP-Netzwerk kommunizieren zu können, braucht ein Client mindestens eine IP-Adresse, die dazugehörende Netzwerkmaske und, wenn er auch Systeme außerhalb dieses Netzwerks erreichen möchte, die Adresse des Standard-Routers (auch oft als »Standard-Gateway« bezeichnet). In einem »ordentlichen« TCP/IP-Netzwerk kommen dann noch weitere Informationen wie die IP-Adresse des DNS-Servers, der Host-Name und der lokale Domain-Name dazu. In einem komplexeren TCP/IP-Netzwerk können dann noch weitere Informationen benötigt werden, beispielsweise die Adressen von Proxy- und Socks-Gateways, Newsservern und anderen.

Diese Informationen müssen normalerweise direkt am Client konfiguriert werden und erfordern so eine Nachbearbeitung jeder Client-Installation, da mindestens die IP-Adresse für jeden Client einmalig sein muß.

Um diese Aufgabe in größeren und großen Netzwerken zu bewältigen, wurden BOOTP und sein »Nachfolger« DHCP geschaffen, um eine automatische Zuweisung der benötigten Informationen zu ermöglichen.

Eine DHCP-Installation besteht aus zwei Teilen: einem DHCP-Server und einem oder mehreren DHCP-Clients. Einfach ausgedrückt werden alle benötigten Informationen am Server konfiguriert und der jeweilige Client fragt sie nach dem Start des Betriebssystems nur noch ab.

Die Funktionsweise der DHCP-Client/Server-Kommunikation

Ein als DHCP-Client konfiguriertes Betriebssystem (bei Windows 95 beispielsweise die Standardeinstellung) hat nach dem Start nur die Information, daß das TCP/IP-Protokoll verwendet werden soll, mit welcher Netzwerkkarte es verwendet werden soll und daß ein DHCP-Server alle weiteren Informationen bereitstellt.

Der DHCP-Client muß also zunächst den DHCP-Server finden. Dies wird durch das Aussenden einer DHCP-DISCOVER-Nachricht im lokalen Segment (oder Ring) erreicht. Die DHCP-DISCOVER-Anfrage wird dann vom DHCP-Server mit einer DHCP-OFFER-Nachricht beantwortet. Nach einem weiteren Nachrichtenaustausch, einem DHCP-REQUEST vom Client und der DHCP-ACKNOWLEDGE-Bestätigung vom Server verwendet der Client dann die ihm zugewiesenen Informationen für die Kommunikation im TCP/IP-Netzwerk.

DHCP-Informationen zwischen Client und Server werden über UDP/IP ausgetauscht. Um DHCP-Anfragen über Segmentgrenzen hinaus zu verschicken, müssen die Router (oder Switches), die zur Verbindung der Segmente verwendet werden, über eine sogenannte »BOOTP Relay«- oder »BOOTP Helper«-Funktionalität verfügen. Sobald eine BOOTP-Relay-Funktion verfügbar und eingeschaltet ist, leitet der Router den DHCP-Request entsprechend weiter.

Der DHCP-Server verwaltet eine Datendatei, die zum einen die für jeden Client gültigen Informationen enthält und zweitens einen Bereich von IP-Adressen, die für Clients freigegeben sind. Fragt nun ein Client beim Server nach einer IP-Adresse, stellt der Server anhand der Netzwerkkartenadresse (auch MAC-Adresse genannt) fest, ob dieser Computer schon einmal eine IP-Adresse erhalten hat. Ist dies der Fall, wird dem Client diese Adresse wieder zugeteilt und mit den allgemeinen Informationen übermittelt. Ist jedoch der Client nicht bekannt oder die früher zugeteilte Adresse in der Zwischenzeit wieder vergeben worden, wird eine freie Adresse aus dem Pool vergeben.

Über DHCP können IP-Adressen aber auch statisch vergeben werden. Dazu wird am Server die IP-Adresse einer Netzwerkkartenadresse fest zugeordnet. Bei diesem Verfahren ist zwar der Administrationsaufwand höher, da alle Netzwerkkartenadressen und IP-Adressen eingetragen werden müssen, aber dafür bekommt jeder Client immer dieselbe IP-Adresse, während andere Informationen, wie die Adresse des DNS-Servers, dynamisch geändert werden können. In der Praxis wird man hier eine Mischkonfiguration erstellen: Computer, die im Netz eine fest Aufgabe haben, wie beispielsweise ein NFS-Server oder WWW-Proxy, bekommen über ihre Netzwerkkartenadresse eine feste IP-Adresse zugewiesen, während einfache Arbeitsplätze aus einem Pool bedient werden und so unter Umständen nach jedem Einschalten eine andere IP-Adresse bekommen.

DHCP kann neben den oben genannten Basisinformationen im Prinzip jede beliebige Information an den TCP/IP-Stack oder darauf aufsetzende Programme verteilen. Grenzen werden nur durch die TCP/IP-Implementation des Clients gesetzt. Ein OS/2-Warp-Client kann beispielsweise auch noch Informationen wie Default LPR Printer, Default WWW Home Page, WWW Proxy Server, News Server, SOCKS Server, NFS Mount Points oder X Font Server verarbeiten.

DHCP-Server sind inzwischen Bestandteil von praktisch jedem kommerziellen Netzwerkbetriebssystem wie IBM OS/2 Warp Server, Novell Netware oder Microsoft Windows NT Server. Und selbstverständlich für jedes Unix-Derivat, das unter der Sonne verfügbar ist. Nicht alle Server unterstützen jedoch alle Fuktionen wie beispielsweise eine direkte Zuordnung von IP-Adresse anhand der Netzwerkkartenadresse. Hier muß vor der Auswahl des DHCP-Servers die Verfügbarkeit der benötigten Fuktionen betrachtet werden.

Auch bei Client-Betriebssystemen mit TCP/IP-Stack ist inzwischen die DHCP-Funktionalität meistens enthalten. So muß beispielsweise bei IBMs OS/2 Warp Connect Version 3 die DHCP-Funktion mit einem kostenlosen Update noch nachgerüstet werden, bei Version 4 ist es jedoch genauso wie bei Windows 95, Windows NT und Apple MacOS System 7.5.3 (Open Transport 1.1 und höher) im Basisbetriebssystem enthalten.

Hier gilt im allgemeinen das Internet-Standard-Ideal »Every Server with every Client«. In der Praxis haben Kombinationen wie Netware-DHCP mit Windows 95/NT und OS/2 Clients genauso problemlos funktioniert wie Warp-Server-DHCP mit Windows95/NT- oder OS/2-Clients.

Implementationsüberlegungen

Der Einsatz von DHCP bietet neben der automatischen Verteilung von TCP/IP-Konfigurationsparametern auch noch weitere Vorteile. So kann zum Beispiel die Anzahl der verwendeten IP-Adressen an die Anzahl der vorhandenen Netzwerkanschlüsse angepaßt werden. In einer Firma, in der an demselben Arbeitsplatz unterschiedliche Mitarbeiter arbeiten, beispielsweise mit Laptops, muß nicht unbedimgt für jeden Computer eine eigene IP-Adresse reserviert werden.

Als Nachteil könnte man die Notwendigkeit der ständigen Verfügbarkeit des DHCP-Servers anführen. Tatsächlich sehen die DHCP-Spezifikationen aber zwei Mechanismen vor, die verhindern, daß ein Client nicht arbeiten kann, wenn der DHCP-Server kurzfristig nicht verfügbar ist. Zum einen ist es möglich, einen zweiten DHCP-Server aufzustellen - dieser muß dann jedoch mit einem unterschiedlichen IP-Adressen-Pool arbeiten - und zum anderen muß ein Client seine DHCP-Informationen nicht bei jedem Systemstart abfragen, sondern der Administrator kann über die Definition der sogenannten Lease-Time festlegen, nach welcher Zeit ein Client seine DHCP-Informationen aktualisieren muß. Ist die Lease-Time hinreichend lang gewählt, kann der DHCP-Server auch kurzfristig nicht erreichbar sein und die Clients können trotzdem arbeiten.

Im wesentlichen ist vor einer Einführung von DHCP zu prüfen, ob

Ein korrekt konfigurierter DHCP-Server ist für den Netzwerkadministrator die reine Freude. Diskussionen mit Benutzern über das Ausfüllen von TCP/IP-Konfigurationen erübrigen sich und bei der Änderung von Netzwerkmasken oder IP-Adressen wie der des DNS Servers muß nur an einer Stelle eingegriffen werden. Der Einsatz wird empfohlen.

Literaturhinweise

DHCP FAQ: http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html

DHCP Bucknell-University-Seite: http://www.bucknell.edu/~droms/dhcp/

DHCP Emory-University-Seite: http://nws.cc.emory.edu/WebStaff/Alan/NetMan/Computing/DHCP/

RFC 2131 (DHCP-Protokoll): http://ds.internic.net/rfc/rfc2131.txt

RFC 2132 (DHCP-Optionen): http://ds.internic.net/rfc/rfc2132.txt

RFC 1542 (BOOTP-Ergänzungen): http://ds.internic.net/rfc/rfc1542.txt

RFC 1534 (DHCP/BOOTP-Zusammenarbeit): http://ds.internic.net/rfc/rfc1543.txt

InterNIC-Documentation-Server (RFCs und anderes): http://ds.internic.net/ds/dspg0intdoc.html

IETF-WWW-Server: http://www.ietf.cnri.rston.va.us/home.html

DHCP Mailinglisten

dhcp-v4@bucknell.edu: Allgemeine Diskussion über DHCP mit TCP/IP Version 4 (traditionelles TCP/IP)

dhcp-bake@bucknell.edu: Diskussion über DHCP-»Bakeoffs«

dhcp-impl@bucknell.edu: Diskussion über DHCP-Implementation für Entwickler

dhcp-serve@bucknell.edu: Diskussion über Server-Server-Kommunikation

dhcp-dns@bucknell.edu: Diskussion über die Interaktion zwischen DHCP und (Dynamic) DNS

dhcp-v6@bucknell.edu: Diskussion über DHCP mit TCP/IP Version 6 (neues TCP/IP oder IPng)

dhcp-v6impl@bucknell.edu: Diskussion über DHCP mit TCP/IP-Version-6-Implementation

Alle Mailinglisten sind in englischer Sprache. Anfragen sind an »listserv@bucknell.edu« zu richten. Es sind auch Archive dieser Mailinglisten abrufbar.

DNS - Domain Name System

Die Abkürzung DNS wird auch gerne mit »Domain Name Service« oder »Domain Name Server« übersetzt. Das Domain Name System ist ein integraler Bestandteil des Internet und im allgemeinen auch jedes Intranets. Es sorgt dafür, daß ein Benutzer überhaupt in der Lage ist, mit Domain-Namen oder Host-Namen wie »www.nic.de« zu arbeiten. Es ist für die Umsetzung von Host-Namen auf numerische IP-Adressen wie »192.168.0.1« zuständig.

Tatsächlich ist das DNS für das Funktionieren des Internets dermaßen kritisch, daß ein totaler DNS-Ausfall das Internet für praktisch alle Computersysteme und Benutzer unbenutzbar machen würde.

Der Domain Name Server

Die Frage nach der Notwendigkeit eines Domain Name Servers - also eines Computersystems, das die Domain-Name-System-Funktionalität in einem TCP/IP-Netzwerk zur Verfügung stellt, ist praktisch überflüssig. Menschen arbeiten viel lieber mit Host-Namen als mit IP-Adressen - ganz einfach deshalb, weil sich Host-Namen leichter merken lassen als IP-Adressen.

Da jedoch das einzelne Computersystem - oder besser: der TCP/IP-Stack - auf Protokollebene nicht mit Host-Namen arbeitet, muß ein System her, das den Host-Namen in eine IP-Adresse umwandelt. Und da es nicht sinnvoll ist, in einem großen Netzwerk alle Computersysteme mit einer lokalen Host-Tabelle zu versehen, kann dieser Dienst auf ein oder mehrere Systeme, die sogenannten DNS-Server, ausgelagert werden.

Ein DNS-Server verwaltet also mehrere Tabellen, die es ihm ermöglichen, auf die Anfrage mit einer gegebenen IP-Adresse den dazugehörigen Host-Namen zu liefern und auch umgekehrt bei Angabe eines Host-Namens die IP-Adresse des Hosts.

Geschichtliches und Formelles

Die älteste Art der Verwaltung von Host-Namen und dazugehörigen IP-Adressen ist die lokale Host-Tabelle. In den Anfangszeiten des Internet hatte jeder Computer eine solche Tabelle, in der alle anderen Computersysteme mit ihren IP-Adressen und Host-Namen gelistet waren. Diese Form kann heute noch verwendet werden, oft bei kleinen und geschlossenen IP-Netzwerken.

Etwa 1982 wurde es jedoch immer schwieriger, nur mit diesen Tabellen zu arbeiten. Im Wesentlichen war die Verteilung der durch das Stanford Research Institute's Network Information Center (SRI-NIC) verwalteten Liste zu aufwendig, und so wurde von Paul Mockapetris und anderen ein neues System, das Domain Name System, entwickelt.

Die Kommunikation eines DNS-Servers mit einem DNS-Client (Resolver), ist in RFC 1035 spezifiziert.

Während eine IP-Adresse ein Computersystem von links nach rechts näher spezifiziert - der linke Teil einer IP-Adresse spezifiziert das Netz, der rechte Teil das Computersystem - ist dies bei Domain- und Host-Namen genau entgegengesetzt. Durch Punkte voneinander getrennt, kommt in einem Hostnamen von links nach rechts erst der Name des Computersystems, dann unter Umständen eine oder mehr Subdomains, dann die Domain und zuletzt die Top-Level Domain, beispielsweise »router.hamburg.nic.de« oder »www.nic.de«.

Der von einem Computersystem zu verwendende DNS-Server muß als IP-Adresse an diesem Computersystem eingetragen werden. Eine automatische Verteilung ist über BOOTP oder DHCP möglich.

Die kleinste Einheit eines Domain-Name-Systems ist ein einziger DNS-Server. Ein DNS-Server besteht aus zwei Teilen, einem DNS-Resolver und dem eigentlichen DNS-Server. Der DNS-Resolver generiert DNS-Anfragen, während ein DNS-Server diese Fragen typischerweise anhand mehrerer Tabellen beantwortet. Tatsächlich ist jedes Computersystem mit TCP/IP-Stack auch ein DNS-Resolver.

Ein DNS-Server enthält eine Tabelle mit allen Host-Namen und dazugehörigen IP-Adressen seines Netzes. Meistens ist ein DNS-Server für eine komplette Domain, beispielsweise »nic.de«, oder eine Subdomain wie zum Beispiel »hamburg.nic.de« zuständig. Diese Verwaltungseinheit wird auch als »DNS-Zone« bezeichnet. Ein DNS-Server, der für eine Zone die DNS-Tabelle führt, wird als »Authority« und »primary DNS Server« für diese Zone bezeichnet. Es kann für jede Zone weitere DNS-Server geben, die als »secondary DNS Server« bezeichnet werden. Sekundäre DNS-Server werden als Backup für den primären DNS-Server eingerichtet, um einen Ausfallschutz zu gewährleisten. Weiterhin kann ein DNS-Server mehrere Domänen oder Zonen verwalten.

Neben der Information, welche Host-Namen in seiner Domain existieren, hat jeder DNS-Server auch die Information, welcher DNS-Server für die nächsthöhere Domain zuständig ist. Der DNS-Server für »hamburg.nic.de« kennt also den DNS-Server von »nic.de«, während diesem die IP-Adresse des DNS-Server für »de« bekannt ist.

Wenn jetzt ein TCP/IP-Client mittels seiner Resolver-Fuktionalität eine Anfrage an seinen DNS-Server schickt, stellt dieser zuerst fest, ob er selbst für diese Anfrage zuständig ist. Ist dies nicht der Fall, fragt der Resolver des DNS-Servers den nächsthöheren DNS-Server in der Hierarchie nach der Adresse. Kann auch dieser die Anfrage nicht beantworten, landet die Anfrage schließlich bei dem Top-Level-DNS-Server, in unserem Beispiel also dem DNS-Server von »de«, der vom deutschen Network Information Center (DE-NIC) verwaltet wird.

Der Top-Level-DNS-Server eines Landes kennt nun den zuständigen DNS-Server für jede andere Top-Level-Domain und kann die Anfrage weiterleiten. Der jeweilige Top-Level-DNS-Server reicht die Anfrage nun in der entsprechenden Hierarchie wieder nach unten, bis schließlich der zuständige DNS-Server eine Antwort durch die Hierarchie zurückschickt. In allen Fällen ist jedoch auch eine direkte Kommunikation zwischen den Servern möglich.

Üblicherweise werden die bei einem DNS-Server angefragten nicht-lokalen Adressen für eine bestimmte Zeit zwischengespeichert, um die Anfragen an in der Hierarchie höheren Server zu minimieren.

Tatsächlich ist das Domain Name System des Internet die größe verteilte Datenbank der Welt. An ihrer Spitze stehen zur Zeit etwa zehn DNS-Server, die die Informationen über alle Top-Level-Domänen enthalten. Sie kennen alle für die »normalen« Domänen verantwortlichen DNS-Server, die ihrerseits jeweils die DNS-Server ihrer Subdomains kennen. So kann jede DNS-Anfrage letztendlich an den zuständigen DNS-Server weitergeleitet werden.

Wesentliche DNS-Einträge

Im wesentlichen gibt es zwei Sorten von DNS-Einträgen: Type A/PTR Records und MX Records. Wenn ein Computersystem die Adresse eines anderen Computersystems haben möchte, dann meistens weil es entweder eine direkte Verbindung zum Austausch von Daten aufbauen möchte oder die Zustellung einer E-Mail gewünscht wird. Natürlich ist auch die Zustellung einer E-Mail ein Austausch von Daten, jedoch wird dieser als Spezialfall behandelt, da ein Computersystem, das E-Mail empfangen kann, durchaus nicht rund um die Uhr an das Internet angeschlossen sein muß.

Wenn also eine http-Verbindung zu einem WWW-Server gewünscht wird, wird der Type A Record abgefragt. Wird jedoch eine smtp-Verbindung zwecks Auslieferung einer Mail gewünscht, wird auf den Mail Exchange (MX) Record zugegriffen. Dies hat zur Folge, daß eine Firma keine Standleitung zum Internet benötigt, um rund um die Uhr E-Mail empfangen zu können, da der MX Record auch beispielsweise auf das E-Mail-System des Internetproviders zeigen kann, der dann die E-Mail bis zur Abhloung zwischenspeichert.

DNS in Verbindung mit DHCP: DDNS

Die Verwaltung der DNS-Tabellen ist schon für statische TCP/IP-Clients nicht ganz trivial. Was tun, wenn man jetzt auch noch Benutzer hat, die teilweise in unterschiedlichen Netzen (Abteilungen oder Niederlassungen) arbeiten und dennoch unter ihrem alphanumerischen Host-Namen erreichbar sein sollen?

Die IP-Adressenvergabe kann man mit DHCP (siehe dort) hervorragend lösen. Der Benutzer ist also in jedem Netz mit einer IP-Adresse erreichbar. Was nun noch fehlt, ist ein Mechanismus, der es einem TCP/IP-Client erlaubt, seine geänderte IP-Adresse dem für seinen Host-Namen zuständigen DNS-Server mitzuteilen. Die mit dem Host-Namen verknüpfte IP-Adresse muß also auf Anfrage des Clients vom DNS-Server dynamisch geändert werden können.

Diese Funktionalität stellt ein Dynamic Domain Name System Server (DDNS-Server) zur Verfügung. Ein DDNS-Server kann auf Anforderung eines Clients die DNS-Tabelle selbstständig modifizieren und so sicherstellen, daß ein mobiler Client auch über Niederlassungsgrenzen hinweg bei wechselnden IP-Adressen immer unter demselben Host-Namen erreichbar ist.

Um sicherzustellen, daß nur der »echte« Client eine Adressenänderung veranlassen kann, authentifizieren sich Server und Client mit elektronischen Schlüsseln, die auf einem Public-Key-Verfahren beruhen.

Durch den Einsatz von DHCP und DDNS können beispielsweise Laptop-Benutzer beliebig den Netzanschluß wechseln und sind trotzdem immer über denselben Host-Namen (»hhf.mobil.teamos2.de«) erreichbar.

DNS-Server

DNS-Server sind heute im allgemeinen Bestandteil jedes Server-Betriebssystems wie IBM OS/2 Warp Server, Novell Netware oder Microsoft Windows NT Server. Und natürlich für jedes Unix verfügbar, falls es nicht gleich mitgeliefert wird. Unterschiede gibt es im wesentlichen in der Verwaltung. Während Unix-Systeme meistens mit textbasierten Tabellen arbeiten, versuchen sich andere Hersteller an grafischen Verwaltungstools. Am einfachsten ist es, zuerst den mit dem eingesetzten Netzwerk-Betriebssystem gelieferten DNS-Server zu testen und dann bei Bedarf auf freie DNS-Implementationen (»BIND« ist für diverse Plattformen verfügbar) oder kommerzielle DNS-Server auszuweichen.

Inkompatibilitäten zwischen DNS-Servern und TCP/IP-Clients selbst unterschiedlichster Welten (beispielsweise U.S.Robotics PalmPilot PalmTop Computer an AIX DNS Server oder ähnliches) sind mir nicht bekannt.

Bei der Entscheidung für eine DHCP/DDNS-Installation muß im Moment noch geprüft werden, inwiefern die Clients mit den Servern zusammenarbeiten. Einige Hersteller von DHCP/DDNS-Servern liefern eigene Clients für unterschiedliche Betriebssystem-Plattformen.

Implementationsüberlegungen

Wenn Sie ein Intranet ohne Anschluß an die Außenwelt betreiben wollen, müssen Sie Ihren eigenen DNS Server aufsetzen. Sollten Sie jedoch über eine Internet-Standleitung verfügen, ist es bei kleineren Netzen zu empfehlen, einfach den DNS-Server des Internet-Service-Providers zu verwenden. Sobald Ihr Netz etwas größer wird und auch viel Datenverkehr nur im eigenen Netz, zum Beispiel mit einem Intranet-WWW-Server, stattfindet, ist die Installation eines DNS-Servers für das lokale Netz sinnvoll.

Wie alle komplexen Dienste muß eine DNS-Server-Implementation eine angemessene Testphase durchlaufen. Um Ausfällen vorzubeugen, bietet sich die Installation eines zweiten (secondary) DNS-Servers an, dieser kann aber auch vom Internet-Service-Provider gestellt werden.

Sobald ein DNS-Server verfügbar ist und alle Clients darauf umgestellt sind (siehe auch DHCP), ist dieser eine der kritischsten Komponenten des TCP/IP-Netzwerks und muß dementsprechend verfügbar gehalten werden. Eine DHCP/DDNS-Server-Installation ist noch kritischer, da die dynamischen Änderung der Client-Informationen nur durch den ersten (primary) DDNS-Server erfolgen kann und nicht durch weitere (secondary) DNS-Server.

Anhang / Literaturhinweise:

DNS-FAQ: http://www.users.pfmc.net/~cdp/cptd-faq/

DNS Resources Directory: http://www.dns.net/dnsrd/ Aktualisierung 2012: Diese Seite existiert nicht mehr; sie ist nur noch im Internet Archive zu finden (auf dem Stand von Mai 2011). Eine aktuelle Seite mit ähnlichen Informationen finden Sie unter http://www.onlinecomputersciencedegree.com/resources/dns-resource-directory/.

^ Zurück zum Anfang


Haftungsausschluß© C&L Computer- und Literaturverlag GmbH 2001-> Mail an C&L