Windows NT in heterogenen Netzen

Kapitel 4: DNS-Dienste nutzen

Letzte Änderung: 18.5.98 von B. Tritsch

Überblick

Zurück zum Index "PC- und MS-Windows-Support"

Zurück zum Inhalt


Das Domain-Konzept

Programme referenzieren Rechner und andere Ressourcen äußerst selten über über binäre Netzwerkadressen. Statt dessen finden ASCII-Zeichenketten viel öfters Verwendung, wie z.B. "ZGDV.DE". Dennoch versteht ein Netzwerk im allgemeinen und das Internet im speziellen ausschließlich binäre Adressen wie 192.44.32.1. Daher werden Mechanismen zur Konvertierung der einen Konvention in die andere benötigt.

Ganz zu Anfang des DARPANET genügte dafür eine einfache ASCII-Datei, die alle Rechnernamen und IP-Adressen auflistete. Jede Nacht holten alle angeschlossenen Rechner diese Datei von der Originalquelle ab. Für ein Netzwerk mit nur einigen hundert Maschinen war dies ein adäquates Vorgehen. Nachdem jedoch zigtausend Maschinen im Internet miteinander verbunden waren, erwies sich dieses Vorgehen als nicht weiter tragfähig. Insbesondere die wachsende Größe der Datei und die Namenskonflikte bei der Einbindung neuer Rechner erforderte die Entwicklung eines neuen Konzepts - des Domain Name Systems (DNS).

Die Essenz von DNS ist die Einführung eines hierarchischen, domänebasierten Namensschemas und eines verteilten Datenbanksystems für die Implementierung dieses Namensschemas. Es wird primär für die Abbildung (Mapping) von Rechnernamen auf IP-Adressen verwendet und ist in den RFCs 1034 und 1035 spezifiziert.

Eine große und sich ständig ändernde Datenbank mit Rechnernamen ist ein nicht-triviales Problem. Beim normalen Postsystem wird das Management von Namen durch die Zuordnung von Zeichenketten für das Land, den Ort, die Straße und den Adressaten geregelt. Bie dieser Art der hierarchischen Adressierung gibt es keine Konfusion zwischen einem Bernhard Tritsch in Darmstadt und einem Bernhard Tritsch in Freiburg. Das Domain Name System funktioniert auf die selbe Weise.

Konzeptionell ist das Internet in mehrere hundert Top Level Domains aufgeteilt, wobei jede Domain viele Rechner umfaßt. Jede Domäne ist aufgeteilt in Subdomänen, die sich wiederum in Subdomänen verzweigen. Alle diese Domänen können in einer Baumstruktur dargestellt werden. Die Blätter der Bäume repräsentieren Subdomänen, die keine weiteren Subdomänen (aber natürlich Rechner) beinhalten. Ein Blatt kann eine einzelne Maschine aber auch eine Firma mit tausenden von Einzelrechnern umfassen.

Die Top Level Domains bestehen aus zwei Gruppen: generische und länderspezifische. Die generischen Domänen sind

Die länderspezifischen Domänen wie de umfassen einen Eintrag für jedes Land, wie es in ISO 3166 definiert ist.

Jede Domäne wird durch den aufsteigenden Pfad bis hin zur (unbenannten) Wurzel des Baumes benannt. Die Komponenten werden durch einen Punkt voneinander getrennt. Daher kann eine Abteilung (GRZ) innerhalb des Instituts für Graphische Datenverarbeitung (IGD) in der Fraunhofer-Gesellschaft (FHG) folgendermaßen heißen: "GRZ.IGD.FHG.DE". Dieser Name steht dabei in keinerlei Konflikt mit einer Abteilung GRZ am MIT in den USA: "GRZ.MIT.EDU". Solche Namen werden als Fully Qualified Domain Name bezeichnet.

Domänenamen sind unabhängig von der Groß- und Kleinschreibung, daher bedeuten edu und EDU das selbe. Komponentennamen können bis zu 63 Buchstaben lang sein, der gesamte Pfad bis zu 255 Buchstaben.

Domain Name Service - DNS

Für das Verständnis der DNS-Namenskonventionen sind zwei Begriffe von Bedeutung: Domänen und Zonen. Die Domäne taucht bereits im Zusammenhang mit den bekannten Internet-Namen auf, z.B. "IGD.FHG.DE" oder "ZGDV.DE". Domänen sind weltweit strukturiert und werden vom Network Information Center (NIC) sowie seinen nationalen Ablegern (z.B. DeNIC) vergeben und verwaltet.

Eine Domäne kennzeichnet eine logische Struktur von Rechnern. Innerhalb einer Domäne kann es also wie weiter oben schon beschrieben Subdomänen geben. Diese dienen einer weiteren Strukturierung umfangreicherer Netzwerke. Beim Betrieb einer eigenen Domäne ist ihr Besitzer auch für deren Verwaltung über einen Domain Name Server verantwortlich.

Auch der zweite obengenannte Begriff - die Zone - steht in direkter Abhängigkeit zum DNS. Eine Zone definiert dabei, welche Internet-Namen in einer bestimmten Zonendatei verwaltet werden. Ein DNS-Server kann eine oder mehrere Zonen verwalten. Hierbei enthält eine Zone nicht zwingend alle Subdomänen einer Domäne. Eine größere Domäne kann daher in mehrere Zonen aufgeteilt werden, die getrennt verwaltet werden.

Der Domain Name Server (oder einfacher Name Server) speichert Informationen über die Domäne sowie die darin enthaltenen Systeme. Bei diesen lassen sich drei Rollen unterscheiden:

  1. Auf primären Name Servern wird das Original der DNS für eine Zone verwaltet. Dort werden alle Änderungen vorgenommen.
  2. Sekundäre Name Server bekommen ihre Daten von anderen Name Servern über das Netzwerk. Die Übermittlung von Zoneninformationen (= DNS-Datenbank) bezeichnet man als Zonentransfer.
  3. Ein Master Name Server ist der Server, von dem ein sekundärer Name Server seine Zoneninformationen erhält. Ein sekundärer Name Server kann seine Daten sowohl von einem primären Name Server als auch von einem sekundären Name Server erhalten.

Sekundäre Name Server sind aus dreierlei Gründen erforderlich:

  1. Durch sie wird Redundanz und damit eie höhere Verfügbarkeit geschaffen: Beim Ausfall eines Name Servers steht immer noch ein zweiter Server für Anfragen zur Auflösung eines Internet-Namens in eine IP-Adresse zur Verfügung.
  2. An Standorten, die mit schmalbandigen Leitungen verbunden sind, ist es effizienter einmal die Zoneninformation zu übermitteln und dann auf einen lokalen DNS-Server zuzugreifen, als jedesmal den primären Name Server zu belasten.
  3. Durch den Einsatz mehrerer DNS-Server kann die Last auf dem primären Server reduziert werden.

Ein DNS-Server kann sowohl primärer Name Server für eine Zone als auch sekundärer Name Server für eine andere Zone sein. Zwischen dem logischen Konzept der Domäne, dem dateibezogenen Konzept der Domäne und dem physischen DNS-Server gibt es keinen zwingenden Zusammenhang.

Wenn ein Client nun auf einen DNS-Server zugreift, spielen die dort vorhandenen Zonendateien aber wieder eine wichtige Rolle. Der DNS-Server versucht die angeforderte Information mit Hilfe der Zonendateien bereitzustellen. In kleineren und mittleren lokalen Netzen, in denen die gesamten Informationen auf allen DNS-Servern verfügbar sind, ist dies kein Problem. In großen Netzwerken und bei einem Zugriff auf das Internet ist die Information aber sehr häufig nicht lokal in einer der Zonendateien verfügbar. DNS kennt für solch einen Fall das Konzept des Forwarder. Ausgewählte DNS-Server können als Forwarder eingerichtet werden. Nur diese Systeme können auf weitere DNS-Server - vor allem im Internet - zugreifen. Solch eine Beschränkung ist sowohl aus Gründen der Lastverteilung als auch der Sicherheit nötig. Allein dadurch kann bei einer Firewall gezielt eingeschränkt werden welche Systeme mit dem Internet kommunizieren dürfen und welche nicht.

Die übrigen DNS-Server werden so eingerichtet, daß sie die Forwarder verwenden. Diese Konfiguration erfolgt auf der Ebene des DNS-Servers und nicht auf der Ebene der Zonen oder Domänen. Wenn ein Client nun eine Anfrage an seinen DNS-Server sendet, versucht dieser zunächst die Anfrage mit Hilfe der Zoneninformationsdatei zu beantworten. Falls das nicht klappt, leitet er die Frage an einen der angegeben Forwarder weiter. Dieser kümmert sich um die Anfrage (ggf. durch den Zugriff auf weiter DNS-Server) und gibt das Ergebnis an den ersten DNS-Server zurück. Dieser liefert dann die erfragte IP-Daresse an den Client.

Neben den klassischen Anfragen, bei denen auf Basis eines Internet-Namens eine IP-Adresse erfragt wird, kann auch eine IP-Adresse an den DNS-Server gesendet werden, um den zugehörigen Internet-Namen zu erhalten. Diese Anfragen werden als rekursiv (oder invers) bezeichnet. Ihr Zweck liegt darin zu überprüfen, ob ein Server tatsächlich der ist, der er zu sein vorgibt - oder ob er womöglich einen falschen Namen zu einer IP-Adresse angibt.

Hier ergibt sich ein Hauptangriffspunkt kommerzieller Anbieter sicherheitskritischer Dienste, wie z.B. Banken mit Online-Anschluß. Das DNS-Spoofing entspricht der gezielten Manipulation der Zuordnung zwischen logischem Namen und IP-Adresse eines Servers. Es wird dabei vorgegaukelt, daß sich über den logischen Namen zu einem bestimmten Rechner verbunden wurde. Dies ist dann jedoch ein Rechner der Angreifer, der damit auch möglicherweise sicherheitskritische Informationen des Benutzers erhält.

Konfiguration von DNS unter Windows NT

Die Konfiguration des DNS auf einem Windows NT Client erfolgt über den "Systemsteuerung"-Ordner: Start - Einstellungen - Netzwerk-Icon - Protokolle - TCP/IP-Protokoll - DNS

Abbildung 4.1: NT-Dialogbox zur Konfiguration von DNS

Es exisitiert auch ein DNS-Server unter Windows NT 4.0. Dieser ist im Resource Kit (Die Technische Referenz) verfügbar. Ab Windows NT 5.0 wird DNS als Standard jedem NT-Server beiliegen.

Kann oder möchte man kein DNS verwenden, kann die Namensauflösung auch mit Hilfe einer HOSTS oder einer LMHOSTS-Datei arbeiten. Diese ASCII-Dateien ordnen in einer Tabelle logische Namen zu physikalischen IP-Adressen. Während sich die HOSTS-Datei an UNIX-Konventionen hält, erlaubt LMHOSTS eine erweiterte Syntax. Die Konfiguration erfolgt über Start - Einstellungen - Netzwerk-Icon - Protokolle - TCP/IP-Protokoll - WINS

Abbildung 4.2: Konfiguration einer LMHOSTS-Abfrage

Eine HOSTS-Datei sieht dabei folgenderrmaßen aus:

# Copyright (c) 1993-1995 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows NT.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost
153.97.128.104	pcdevnsol4 pcdevnsol4.igd.fhg.de
153.97.128.103	pcdevnsol3 pcdevnsol3.igd.fhg.de
153.97.128.102	pcdevnsol2 pcdevnsol2.igd.fhg.de
153.97.128.111	pcdevnsol5 pcdevnsol5.igd.fhg.de

Eine LMHOSTS-Datei hat dagegen folgendes Aussehen:

# 102.54.94.97     maestro         #PRE #DOM:technik    # DC von "Technik"
# 102.54.94.102    "spiele \0x14"                       # besonderer Server
# 102.54.94.123    nordpol         #PRE                 # Server in 3/4317
# #BEGIN_ALTERNATE
# #INCLUDE \\lokal\public\lmhosts
# #INCLUDE \\maestro\public\lmhosts
# #END_ALTERNATE
#
# In diesem Beispiel enth„lt der Server "spiele" ein Sonderzeichen
# im Namen, und der Server "nordpol" wird bereits zu Anfang in den
# Namen-Cache geladen.
# Die Adreßzuordnung für den Server "maestro" wird angegeben, um diesen
# Server weiter unten in der #INCLUDE-Gruppe verwenden zu können.
# Wenn der Server "lokal" nicht verfügbar ist, wird die zentrale LMHOSTS-
# Datei auf "maestro" verwendet.

Zum nächsten Kapitel