TCP/IP-Grundlagen für Microsoft Windows

Microsoft Corporation

Zusammenfassung

In diesem Kapitel wird ausführlich das Domain Name System (DNS) und dessen Verwendung in privaten Intranets und dem Internet erläutert. DNS ist zur Namensauflösung von Domänennamen, wie z. B. www.example.com, bei allen Arten von Netzwerkanwendungen erforderlich, vom Internetbrowser bis zum Active Directory®-Verzeichnisdienst. Der Netzwerkadministrator muss über die entsprechenden Kenntnisse über DNS-Namen, Domänen, Zonen, Namenserverrollen und Replikation verfügen, um ein privates Intranet und das Internet ordnungsgemäß konfigurieren und verwalten zu können.

Auf dieser Seite

	Zielsetzung
	Das Domain Name System
	Namensauflösung
	Namenserverrollen
	Ressourcendatensätze und Zonen
	Zonenübertragungen
	Dynamisches DNS-Update
	Kapitelzusammenfassung
	Kapitelglossar

Zielsetzung

Nach dem Lesen dieses Kapitels werden Sie zu Folgendem in der Lage sein:

Zum Seitenanfang

Das Domain Name System

Das ursprüngliche Verfahren zur Namensauflösung erfolgte mithilfe einer Datei namens Hosts.txt, die im inzwischen veralteten Advanced Research Projects Agency-Netzwerk (ARPANET), dem Vorgänger des heutigen Internets, verwendet wurde. Als die Anzahl der Hosts im ARPANET noch relativ klein war, war die Verwaltung der Datei Hosts.txt einfach, da sie aus unstrukturierten Namen und den entsprechenden IPv4-Adressen bestand. Die Computer, die mit dem ARPANET verbunden waren, haben die Hosts.txt in regelmäßigen Abständen von einem zentralen Speicherort heruntergeladen und zur lokalen Namensauflösung verwendet. Als aus ARPANET das heutige Internet wurde, ist die Anzahl der Hosts enorm angestiegen, und das zentralisierte Verwalten und manuelle Verteilen einer Textdatei mit den Computernamen des Internets wurde zu aufwendig.

Der Ersatz für die Datei Hosts.txt musste verteilt werden können, einen hierarchischen Namespace zulassen und sollte möglichst einfach zu verwalten sein. Das ursprüngliche Ziel bei der Entwicklung von DNS bestand darin, die unhandliche, zentral verwaltete Textdatei durch eine handlichere, verteilte Datenbank zu ersetzen, die einen hierarchischen Namespace, eine Delegation und Verteilung der Verwaltung, erweiterbare Datentypen und eine praktisch unbegrenzte Datenbankgröße bei einer akzeptablen Leistung ermöglicht.

DNS definiert einen Namespace und ein Protokoll für die Namensauflösung und Datenbankreplikation:

Historisch gesehen ist die am meisten verbreitete Implementierung des DNS-Protokolls die Berkeley Internet Name Domain (BIND). BIND wurde ursprünglich an der University of California in Berkeley für die Berkeley Software Distribution Version 4.3 des UNIX-Betriebssystems entwickelt.

DNS-Komponenten

Die RFCs (Requests for Comments) 974, 1034 und 1035 definieren die primären Spezifikationen für DNS. Durch RFC 1034 erhält DNS die drei folgenden Komponenten:

DNS-Namen

DNS-Namen haben eine ganz spezifische Struktur, mit der der Speicherort des Namens im DNS-Namespace identifiziert wird. Ein vollqualifizierter Domänenname (FQDN – Fully Qualified Domain Name) ist ein DNS-Domänenname, der von seinem Speicherort relativ zum Stammverzeichnis des Namespace (als Stammdomäne bezeichnet) erstellt wurde. FQDNs verfügen über folgende Attribute:

Domänen und untergeordnete Domänen

Der DNS-Namespace besteht aus einer logischen invertierten Baumstruktur. Jede Verzweigung (bzw. jeder Knoten) in der Struktur erhält einen Namen von maximal 63 Zeichen Länge. Jeder Knoten der Struktur ist ein Teil des als Domäne bezeichneten Namespace. Eine Domäne ist eine Verzweigung in der Baumstruktur und kann sich an jeder Stelle der Struktur befinden. Domänen können für einen Lastenausgleich oder für Verwaltungsaufgaben an Knotenpunkten innerhalb der Domäne in untergeordnete Domänen unterteilt werden. Die Position der Domäne innerhalb der DNS-Hierarchie wird durch den Domänennamen angegeben. Der FQDN identifiziert die Domäne relativ zum Stamm. Domänennamen und FQDNs werden erstellt, indem die Knotennamen – vom festgelegten Domänenknoten zurück bis zum Stamm – kombiniert werden. Die verschiedenen Knoten werden dabei durch einen Punkt (.) getrennt. Dem Stamm der Struktur ist der spezielle Name "" (Null) vorbehalten, der durch Hinzufügen eines abschließenden Punkts am Ende des Domänennamens (z. B. www.sales.example.com.) angegeben wird. Domänen und untergeordnete Domänen werden in Zonen zusammengefasst, um eine verteilte Verwaltung des DNS-Namespace zu ermöglichen.

In Abbildung 8-1 ist der DNS-Namespace abgebildet, wie er im Internet vorkommt.

Abbildung 8-1  Der DNS-Namespace
Abbildung vergrößern

In Abbildung 8-1 sind verschiedene Domänen der obersten Ebene und Beispielhosts der Domäne "microsoft.com." abgebildet. Ein nachgestellter Punkt gibt einen Domänennamen eines Hosts relativ zur Stammdomäne an. Um eine Verbindung zu diesem Host herzustellen, würde ein Benutzer den Namen "www.microsoft.com." angeben. Wenn der Benutzer den letzten Punkt nicht angibt, wird er automatisch vom DNS-Auflösungsprogramm hinzugefügt. Einzelne Organisationen verwalten die Domänen der zweiten Ebene (untergeordnete Domänen der Domänen der obersten Ebene) und die zugehörigen Namenserver. Microsoft z. B. verwaltet die Domäne "microsoft.com.".

DNS-Server und das Internet

Domänen definieren unterschiedliche Autoritätsebenen innerhalb einer hierarchischen Struktur. Die oberste Hierarchieebene wird als Stammdomäne bezeichnet. Der DNS-Namespace im Internet weist, wie in Abbildung 8-1 dargestellt, folgende Struktur auf:

Die Stammdomäne verwendet die Bezeichnung "Null" und wird durch einen einzelnen Punkt (.) angegeben. In den USA werden mehrere Stammdomänen-Namenserver durch die Internet Assigned Names Authority (IANA) verwaltet.

Die nächsthöhere Ebene der Hierarchie ist in eine Reihe von Knoten unterteilt, den so genannten Top-Level-Domänen. Top-Level-Domänen werden nach Art der Organisation und Land/Region zugewiesen. Im Folgenden finden Sie einige der verbreiteten Top-Level-Domänen:

Jede Top-Level-Domäne verfügt über Namenserver, die von IANA verwaltet werden. Top-Level-Domänen können Second-Level-Domänen und Hosts enthalten.

Second-Level-Domänen enthalten die Domänen und Namen für Organisationen und Länder/Regionen. Die Namen der Second-Level-Domänen werden entweder durch die Organisation oder das Land/die Region selbst verwaltet (durch einen eigenen DNS-Server im Internet) oder mithilfe eines Internetdienstanbieters (ISP – Internet Service Provider), der die Namen im Auftrag der Organisation bzw. des Landes/der Region verwaltet.

Zonen

Eine Zone ist ein zusammenhängender Bereich einer Domäne des DNS-Namespace, dessen Datenbankdatensätze in einer bestimmten DNS-Datenbankdatei bestehen und verwaltet werden, die auf einem oder mehreren DNS-Servern gespeichert ist. Ein einzelner DNS-Server kann so konfiguriert werden, dass er eine oder mehrere Zonen verwaltet. Jede Zone ist an einem spezifischen Domänenknoten verankert, der Stammdomäne der Zone. Zonendateien enthalten nicht notwendigerweise den vollständigen Zweig (d. h. alle untergeordneten Domänen) unterhalb der Stammdomäne der Zone. Eine Domäne kann z. B. in mehrere untergeordnete Domänen unterteilt werden, für die getrennte DNS-Server zuständig sind. Sie können Domänen über mehrere Zonendateien hinweg aufteilen, wenn die Domänenverwaltung auf verschiedene Gruppen verteilt werden oder die Datenreplikation effektiver gestaltet werden soll.

In Abbildung 8-2 wird der Unterschied zwischen Domänen und Zonen dargestellt.

Abbildung 8-2  Domänen und Zonen
Abbildung vergrößern

In dem Beispiel ist "microsoft.com" eine Domäne (der gesamte Zweig des DNS-Namespace, der mit dem microsoft.com.-Knoten beginnt). Die gesamte Domäne wird jedoch nicht von einer einzelnen Zonendatei verwaltet. Ein Teil der Domäne befindet sich in einer Zone für "microsoft.com." und ein anderer Teil in einer Zone für die "dev.microsoft.com."-Domäne. Diese Zonen entsprechen verschiedenen DNS-Datenbankdateien, die sich entweder auf demselben oder auf verschiedenen DNS-Servern befinden können.

Zum Seitenanfang

Namensauflösung

Die folgenden zwei Arten von Abfragen können von einem DNS-Auflösungsprogramm (auf einem DNS-Client oder einem weiteren DNS-Server) an einen DNS-Server gesendet werden:

Beispiel für die DNS-Namensauflösung

Anhand des Beispiels eines Computers, auf dem ein Microsoft Windows® XP-Betriebssystem oder Windows Server 2003 ausgeführt wird und der mit dem Internet verbunden ist, soll verdeutlicht werden, wie rekursive und iterative Abfragen für allgemeine DNS-Namensauflösungen verwendet werden. Ein Benutzer gibt http://www.example.com in das Feld Adresse des Internetbrowsers ein. Wenn der Benutzer die EINGABETASTE drückt, wird vom Browser ein Windows Sockets-Funktionsaufruf ausgeführt - entweder gethostbyname() oder getaddrinfo() -, um den Namen http://www.example.com in eine IP-Adresse aufzulösen. Im DNS-Teil des Vorgangs zur Windows-Hostnamensauflösung geschieht Folgendes:

In Abbildung 8-3 wird dieser Vorgang dargestellt.

Abbildung 8-3  Beispiel von rekursiven und iterativen Abfragen bei einer DNS-Namensauflösung
Abbildung vergrößern

Alle DNS-Abfragen sind DNS-Name Query Request-Nachrichten (Name Query Request – Namensabfrageanforderung). Alle DNS-Antworten sind DNS-Name Query Response-Nachrichten (Name Query Response – Namensabfrageantwort).

In der Praxis werden die Ergebnisse von Abfragen von den DNS-Servern fortlaufend zwischengespeichert. Wenn ein DNS-Server eine Übereinstimmung zwischen der aktuellen Anforderung und einem Eintrag im Cache findet, wird keine iterative DNS-Abfrage gesendet. In diesem Beispiel wird angenommen, dass sich auf den DNS-Servern keine Cacheeinträge befinden, die das Senden von iterativen Namensabfragen verhindern.

Forward-Lookups sind Abfragen, bei denen ein DNS-Client versucht, einen FQDN in seine zugeordnete IP-Adresse aufzulösen. Zonen, die Zuordnungen von FQDNs zu IP-Adressen enthalten, werden als Forward-Lookupzonen bezeichnet.

Umgekehrte Abfragen

Bei einer umgekehrten Abfrage stellt der DNS-Client die IP-Adresse bereit und fordert den entsprechenden Hostnamen an, anstatt einen Namen bereitzustellen und nach einer IP-Adresse zu fragen. Umgekehrte Abfragen werden auch als Reverse-Lookups bezeichnet, und Zonen, die Zuordnungen von IP-Adressen zu FQDNs enthalten, werden als Reverse-Lookupzonen bezeichnet.

Da die IP-Adresse nicht von einem Domänennamen im DNS-Namespace abgeleitet werden kann, ist eine korrekte Antwort nur durch ein vollständiges Durchsuchen aller Domänen sichergestellt. Um ein aufwändiges Durchsuchen aller Domänen für eine umgekehrte Abfrage zu vermeiden, wurden Domänen mit umgekehrter Namenszuordnung und Zeiger-(PTR-)Ressourcen-Datensätze erstellt.

Ein Beispiel für eine Anwendung, die umgekehrte Abfragen verwendet, ist das Tracert-Tool, das in er Standardeinstellung umgekehrte Abfragen verwendet, um die Namen von Routern in einem Routingpfad anzuzeigen. Wenn Sie umgekehrte Abfragen verwenden möchten, müssen Sie bei der Administration eines DNS-Servers Reverse-Lookupzonen und PTR-Datensätze erstellen, damit die umgekehrten Abfragen beantwortet werden können.

Umgekehrte Abfragen für IPv4-Adressen

Zur Unterstützung von Reverse-Lookups für IPv4-Adressen wurde eine spezielle Domäne mit dem Namen in-addr.arpa. erstellt. Knoten in der in-addr.arpa-Domäne sind nach den Zahlen in der mit Punkten versehenen dezimalen Darstellung der IPv4-Adressen benannt. Da IPv4-Adressen jedoch von links nach rechts spezifischer werden und Domänennamen von rechts nach links, muss die Reihenfolge von IPv4-Adressoktetten umgekehrt werden, um den in-addr.arpa-Domänennamen zu bilden, der der IPv4-Adresse entspricht. Für die verallgemeinerte IPv4-Adresse w.x.y.z ist der entsprechende umgekehrte Abfragename beispielsweise z.y.x.w.in-addr.arpa. IANA übergibt die Verantwortlichkeit zur Administration des umgekehrten Abfrage-Namespace unterhalb der in-addr.arpa-Domäne an Organisationen, sobald diesen IPv4-Adresspräfixe zugewiesen werden.

In Abbildung 8-4 wird ein Beispiel für den Reverse-Lookup-Teil des DNS-Namespace dargestellt.

Abbildung 8-4  Ein Beispiel für den Reverse-Lookup-Teil des DNS-Namespace

Innerhalb der in-addr.arpa-Domäne werden spezielle Zeiger-(PTR-)Ressourcendatensätze hinzugefügt, um die IPv4-Adressen mit ihren entsprechenden Hostnamen zu verknüpfen. Zur Suche nach einem Hostnamen für die IPv4-Adresse 157.54.200.2 sendet ein DNS-Client eine DNS-Abfrage nach einem PTR-Datensatz für den Namen 2.200.54.157.in-addr.arpa. Bei umgekehrten Abfragen wird derselbe Vorgang zur Namensauflösung verwendet, der vorher für Forward-Lookups beschrieben wurde (eine Kombination von rekursiven und iterativen Abfragen). Der DNS-Server findet den PTR-Datensatz mit dem FQDN, der der IPv4-Adresse 157.54.200.2 entspricht, und sendet diesen FQDN zurück an den DNS-Client.

Umgekehrte Abfragen für IPv6-Adressen

Bei IPv6-Reverse-Lookups wird die ip6.arpa.-Domäne verwendet. Zur Erzeugung der Domänen für umgekehrte Abfragen wird jede Hexadezimalziffer in der vollständig dargestellten 32-stelligen IPv6-Adresse in umgekehrter Reihenfolge zu einer eigenständigen Ebene in der umgekehrten Domänenhierarchie.

Der Reverse-Lookup-Domänenname für die Adresse 3ffe:ffff::1:2aa:ff:fe3f:2a1c (vollständig dargestellt als 3ffe:ffff:0000:0001:02aa:00ff:fe3f:2a1c) ist beispielsweise c.1.a.2.f.3.e.f.f.f.0.0.a.a.2.0.1.0.0.0.0.0.0.0.f.f.f.f.e.f.f.3.ip6.arpa.

Wie in IPv4-Adressen werden in der umgekehrten IPv6-Domäne IPv6-Adressen durch PTR-Datensätze FQDNs zugeordnet.

Zwischenspeichern und TTL

Für jede aufgelöste Abfrage (entweder rekursiv oder iterativ) werden die zurückgegebenen Informationen vom für die DNS-Auflösung zuständigen Programm für einen Zeitraum zwischengespeichert, der in jedem Ressourcendatensatz in der DNS-Antwort angegeben ist. Dies wird als "positives Zwischenspeichern" bezeichnet. Der Zeitraum zum Zwischenspeichern der Datensätze in Sekunden wird als Time To Live (TTL - Lebensdauer) bezeichnet. Der Netzwerkadministrator der Zone, die den Datensatz enthält, entscheidet über den TTL-Standardwert für Daten in der Zone. Durch kleinere TTL-Werte kann sichergestellt werden, dass Daten über die Domäne im Netzwerk konsistenter sind, wenn sich die Zonendaten oft ändern. Durch diese Vorgehensweise wird jedoch auch die Auslastung auf Namenservern erhöht, da die positiven Cacheeinträge schneller gelöscht werden.

Nach dem Zwischenspeichern von Daten durch ein DNS-Auflösungsprogramm muss dieses den empfangenen TTL-Wert herunterzählen, um zu ermitteln, wann die Daten aus dem Cache zu löschen sind. Bei Abfragen, die mit den zwischengespeicherten Daten erfüllt werden können, entspricht der zurückgegebene TTL-Wert der übrig gebliebenen Zeitspanne, nach der die Daten aus dem DNS-Cache gelöscht werden. Auch DNS-Auflösungsprogramme des Clients verfügen über Datencaches und berücksichtigen den TTL-Wert, um den Zeitpunkt zur Löschung der Daten zu ermitteln.

Der DNS-Clientdienst in Windows XP und Windows Server 2003 sowie der DNS-Serverdienst in Windows Server 2003 unterstützen positives Zwischenspeichern.

Negatives Zwischenspeichern

Wie ursprünglich in RFC 1034 definiert, bezeichnet negatives Zwischenspeichern das Zwischenspeichern fehlgeschlagener Namensauflösungen. Eine Namensauflösung schlägt fehl, wenn ein DNS-Server eine DNS-Name Query Response-Nachricht mit der Kennzeichnung zurückgibt, dass der Name nicht gefunden wurde. Negatives Zwischenspeichern kann die Antwortzeiten für Namen verringern, die durch DNS während eines iterativen Abfragevorgangs weder für den DNS-Client noch für die DNS-Server aufgelöst werden können. Wie beim positiven Zwischenspeichern läuft auch für negative Cacheeinträge die Gültigkeitsdauer auf der Grundlage des in der DNS-Name Query Response-Nachricht erhaltenen TTL-Werts ab, und sie werden aus dem Cache gelöscht.

Der DNS-Clientdienst in Windows XP und Windows Server 2003 sowie der DNS-Serverdienst in Windows Server 2003 unterstützen negatives Zwischenspeichern.

Round Robin-Lastenausgleich

DNS-Name Query Response-Nachrichten können mehrere Ressourcendatensätze enthalten. Beispielsweise kann die DNS-Name Query Response-Nachricht bei einem einfachen Forward-Lookup mehrere Adressdatensätze (A-Datensätze) enthalten, die wiederum die mit dem gewünschten Host verknüpften IPv4-Adressen enthalten. Wenn mehrere Ressourcendatensätze für denselben Ressourcendatensatztyp vorhanden sind, treten folgende Probleme auf:

Zur Behebung dieser Probleme wird in RFC 1794 ein Mechanismus mit dem Namen Round Robin bzw. Load Sharing (Lastenverteilung) beschrieben, mit dem Lasten auf Netzwerkressourcen verteilt werden können. Die zentrale Annahme in RFC 1794 besteht darin, dass dieselbe Art von Dienst für mehrere Benutzer von mehreren Servern angeboten wird, wenn mehrere Ressourcendatensätze für denselben Ressourcendatensatztyp und denselben Namen vorhanden sind. Zum Beispiel wird die www.microsoft.com-Website tatsächlich von mehreren Webservern mit verschiedenen IPv4-Adressen gehostet. Um zu versuchen, die Last der Anfragen aller Benutzer, die auf www.microsoft.com zugreifen, zu verteilen, ändern die für microsoft.com autorisierenden DNS-Server die Reihenfolge der Ressourcendatensätze für den www.microsoft.com-Namen in aufeinander folgenden DNS-Name Query Response-Nachrichten. Der DNS-Client verwendet die Daten des ersten Ressourcendatensatzes in der Antwort.

Wenn beispielsweise drei A-Datensätze für www.microsoft.com mit den IPv4-Adressen 131.107.0.99, 131.107.0.100 und 131.107.0.101 vorhanden sind, funktioniert das Round Robin-Schema folgendermaßen:

Das Muster wiederholt sich bei nachfolgenden Abfragen. Der Rotationsvorgang wird für eine beliebige Anzahl von Ressourcendatensätzen auf die Liste der Datensätze angewendet.

Ein DNS-Server, auf dem Windows Server 2003 ausgeführt wird und der auf eine rekursive Abfrage antwortet, versucht in der Standardeinstellung, die Ressourcendatensätze nach den Adressen zu sortieren, die der IP-Adresse des anfragenden DNS-Clients am meisten entsprechen. Sie können diesen Server für das Round Robin-Verfahren gemäß RFC 1794 konfigurieren. Um zu bestimmen, welche Adressen der IPv4-Adresse des DNS-Clients am meisten entsprechen, sortiert der DNS-Serverdienst in Windows Server 2003 die Adressen mithilfe eines Vergleichs der höherwertigen Bits der IPv4-Adresse des DNS-Clients und der IPv4-Adresse des abgefragten Hostnamens. Diese Vergleichsmethode ähnelt dem Routenermittlungsprozess, in dem IPv4 oder IPv6 die IPv4- bzw. IPv6-Routingtabelle untersucht, um die Route zu bestimmen, die der Zieladresse eines gesendeten oder weitergeleiteten Pakets am meisten entspricht.

Zum Seitenanfang

Namenserverrollen

DNS-Server speichern Informationen über Bereiche des Domänennamespace. Wenn Namenserver für eine oder mehrere Zonen verantwortlich sind, werden sie für diese Zonen als "autorisierend" bezeichnet. In Abbildung 8-2 ist z. B. der Namenserver mit der Zone dev.microsoft.com autorisierend für die Zone dev.microsoft.com.

Zum Konfigurieren eines DNS-Servers müssen Namenserver-(NS-)Ressourcendatensätze für alle übrigen Namenserver, die sich in dieser Domäne befinden, hinzugefügt werden. Wenn sich die zwei Zonen aus dem Beispiel auf der vorherigen Seite auf verschiedenen Namenservern befinden, würde jeder dieser Server mit einem NS-Datensatz über den anderen Server konfiguriert werden. Diese NS-Datensätze stellen Zeiger auf die anderen autorisierenden Server der Domäne zur Verfügung.

DNS definiert zwei Typen von Namenservern, von denen beide unterschiedliche Funktionen haben:

Da die Informationen für jede Zone in separaten Dateien gespeichert werden, wird die Zuweisung des primären oder sekundären Namenservers auf Zonenebene definiert. Ein Namenserver kann also für bestimmte Zonen als primärer Namenserver, für andere Zonen als sekundärer Namenserver fungieren.

Wenn Sie auf einem sekundären Namenserver eine Zone definieren, konfigurieren Sie die Zone mit dem Namenserver, von dem die Zoneninformationen abgerufen werden sollen. Die Quelle der Zoneninformationen eines sekundären Namenservers wird als Master-Namenserver bezeichnet. Für die angeforderte Zone kann ein Master-Namenserver entweder ein primärer oder sekundärer Namenserver sein. In Abbildung 8-5 ist die Beziehung zwischen primären, sekundären und Master-Namenservern dargestellt.

Abbildung 8-5  Primäre, sekundäre und Master-Namenserver
Abbildung vergrößern

Ein sekundärer Namenserver nimmt beim Starten Kontakt zum Master-Namenserver auf und initiiert eine Zonenübertragung für jede Zone, für die er als sekundärer Namenserver fungiert. Zonenübertragungen können auch regelmäßig stattfinden (vorausgesetzt, Daten auf dem Master-Namenserver wurden geändert), wie im SOA-Eintrag der Zonendatei angegeben. Im Abschnitt "Ressourcendatensätze und Zonen" dieses Kapitels wird der SOA-Ressourcendatensatz beschrieben.

Weiterleitungen

Wenn ein DNS-Server eine Abfrage empfängt, versucht er, die angeforderten Informationen innerhalb der eigenen Zonendateien zu finden. Wenn dies fehlschlägt, weil der Server für die Domäne mit dem angeforderten Namen nicht autorisierend ist und der Datensatz nicht bei einer vorherigen Suche zwischengespeichert wurde, muss der Server mit anderen Namenservern kommunizieren, um die Anforderung zu beantworten. In globalen Netzwerken wie dem Internet wird für DNS-Abfragen für Namen, die nicht den Domänennamen der zweiten Ebene des Unternehmens verwenden, eventuell eine Interaktion mit DNS-Servern über WAN-Verbindungen außerhalb des Unternehmens notwendig. Um zu verhindern, dass sämtliche DNS-Server des Unternehmens Abfragen über das Internet senden, können Sie Weiterleitungen konfigurieren. Eine Weiterleitung sendet Abfragen über das Internet. Andere DNS-Server des Unternehmens werden so konfiguriert, dass sie ihre Abfragen an die Weiterleitung weiterleiten.

Abbildung 8-6 zeigt ein Beispiel zu Intranetservern, die eine Weiterleitung zum Auflösen von Internetnamen verwenden.

Abbildung 8-6  Verwenden einer Weiterleitung zum Auflösen von Internetnamen
Abbildung vergrößern

Namenserver können Weiterleitungen im nicht exklusiven oder im exklusiven Modus verwenden.

Weiterleitungen im nicht exklusiven Modus

Wenn ein Namenserver im nicht exklusiven Modus eine DNS-Abfrage erhält, die er nicht anhand der eigenen Zonendateien auflösen kann, sendet er eine rekursive Abfrage an seine Weiterleitung. Die Weiterleitung versucht, die Abfrage aufzulösen, und gibt die Ergebnisse an den anfordernden Namenserver zurück. Wenn die Weiterleitung die Abfrage nicht auflösen kann, versucht der Namenserver, der die ursprüngliche Abfrage erhalten hat, die Abfrage mithilfe von iterativen Abfragen aufzulösen.

Ein Namenserver, der eine Weiterleitung im nicht exklusiven Modus verwendet, führt Folgendes beim Auflösen eines Namens durch:

Weiterleitungen im exklusiven Modus

Im exklusiven Modus sind Namenserver auf die Weiterleitungen angewiesen, um Namen aufzulösen. Wenn ein Namenserver im exklusiven Modus eine DNS-Abfrage erhält, die nicht durch die eigenen Zonendateien aufgelöst werden kann, sendet er eine rekursive Abfrage an seine zugeordnete Weiterleitung. Die Weiterleitung führt dann die gesamte erforderliche Kommunikation durch, die zum Auflösen der Abfrage notwendig ist, und gibt die Ergebnisse an den ursprünglichen Namenserver zurück. Wenn die Weiterleitung die Abfrage nicht auflösen kann, gibt der ursprüngliche Namenserver einen Abfragefehler an den ursprünglichen DNS-Client zurück. Namenserver im exklusiven Modus versuchen nicht, die Abfrage selbst aufzulösen, wenn die Weiterleitung die Anforderung nicht erfüllen kann.

Ein Namenserver, der eine Weiterleitung im exklusiven Modus verwendet, führt Folgendes beim Auflösen eines Namens durch:

Reine Cachenamenserver

Obwohl alle DNS-Server aufgelöste Abfragen zwischenspeichern, gibt es DNS-Server, die nur Abfragen durchführen, die Antworten zwischenspeichern und die Ergebnisse zurückgeben. Diese Server heißen "reine Cachenamenserver". Reine Cachenamenserver sind für keine Domäne autorisierend und enthalten nur die Informationen, die sie beim Auflösen von Abfragen zwischengespeichert haben.

Wenn reine Cacheserver gestartet werden, werden keine Zonenübertragungen durchgeführt, da die Server über keine Zonen verfügen und keine Einträge in ihren Caches vorliegen. Reine Cacheserver müssen zu Anfang Abfragen so lange weiterleiten, bis im Cache genügend Einträge vorhanden sind, um häufig verwendete Abfragen nur unter Verwendung der Cache-Einträge auflösen zu können.

Zum Seitenanfang

Ressourcendatensätze und Zonen

Wenn Ihr Unternehmen mit dem Internet verbunden ist, muss oftmals keine DNS-Infrastruktur verwaltet werden. In kleinen Netzwerken ist DNS-Namensauflösung einfacher und effizienter, wenn der DNS-Client einen vom ISP verwalteten DNS-Server abfragt. Die meisten ISPs verwalten Domäneninformationen gegen eine Gebühr. Wenn Ihr Unternehmen die Kontrolle über die eigene Dömane benötigt oder die Kosten für einen ISP nicht tragen möchte, können Sie eigene DNS-Server für Ihr Unternehmen einrichten.

In beiden Fällen, also entweder beim Abfragen über den DNS-Server eines ISP oder beim Einrichten separater DNS-Server, muss die IANA über den Domänennamen der Organisation und über die IP-Adressen von mindestens zwei DNS-Servern im Internet, die diese Domäne bedienen, informiert werden. In Unternehmen können auch nicht vom Internet abhängige DNS-Server eingerichtet werden.

Aus Gründen der Zuverlässigkeit und Redundanz werden mindestens zwei Computer als DNS-Server empfohlen – ein primärer und ein sekundärer Namenserver. Der primäre Namenserver verwaltet die Informationsdatenbank, die dann vom primären Namenserver auf den sekundären Namenserver repliziert wird. Diese Replikation ermöglicht das Bearbeiten von Namensabfragen, wenn einer der Namenserver nicht verfügbar ist. Die Replikation wird basierend auf der Häufigkeit der Namensänderungen in der Domäne geplant. Sie sollte so häufig durchgeführt werden, dass Änderungen auf beiden Servern vorhanden sind. Übermäßige Replikation kann jedoch einen negativen Einfluß auf die Leistung des Netzwerks und der Namenserver haben.

Ressourcendatensatzformat

Ressourcendatensätze haben folgendes Format:

BesitzerTTLTyp    Klasse    RDATA

Ressourcendatensätze werden in DNS-Anforderungs- und DNS-Antwortnachrichten in binärer Form dargestellt. In textbasierten DNS-Datenbankdateien werden die meisten Ressourcendatensätze als einzelne Textzeilen dargestellt. Zur besseren Lesbarkeit werden häufig Leerzeilen und Kommentare in die Datenbankdateien eingefügt, die vom DNS-Server ignoriert werden. Kommentare fangen immer mit einem Semikolon (;) an und enden mit einem Wagenrücklauf.

Folgendes Beispiel zeigt einen in einer DNS-Datenbankdatei gespeicherten A-Ressourcendatensatz:

srv1.dev.microsoft.com.   3600   A    IN    157.60.221.205

Jeder Ressourcendatensatz beginnt in der ersten Spalte mit dem Besitzer (srv1.dev.microsoft.com.). Wenn die erste Spalte leer ist, wird angenommen, dass der Besitzer dieses Datensatzes der Besitzer des vorherigen Datensatzes ist. Nach dem Besitzer folgen TTL (3600 Sekunden = 1 Stunde), Typ (A = Adressdatensatz), Klasse (IN = Internet) und RDATA (Ressourcendaten = 157.60.221.205). Wenn kein TTL-Wert angegeben ist, legt der DNS-Server den Wert auf die im SOA-(Start of Authority-)Datensatz der Zone angegebene TTL fest.

Ressourcendatensatztypen

Die DNS-Standards definieren viele Ressourcendatensatztypen. Die am häufigsten verwendeten Ressourcendatensätze sind:

Die RFCs 1035, 1034, 1183 und andere definieren weniger häufig verwendete Ressourcendatensätze. Der DNS-Serverdienst in Windows Server 2003 erfüllt die RFCs 1034, 1035 und 1183 vollständig.

Der DNS-Serverdienst in Windows Server 2003 unterstützt auch folgende Microsoft-spezifische Ressourcendatensatztypen:

Ausführliche Informationen zu Struktur und Inhalten der verschiedenen DNS-Ressourcendatensatztypen finden Sie in "Hilfe und Support für Windows Server 2003" unter dem Thema "Ressourcendatensatzreferenz".

Delegations- und Verbindungsdatensätze

Delegations- und Verbindungsdatensätze werden zu einer Zonendatei hinzugefügt, um die Delegierung einer untergeordneten Domäne an eine separate Zone anzugeben. In Abbildung 8-2 muss der für die Zone microsoft.com autorisierende DNS-Server beispielsweise so konfiguriert werden, dass er beim Auflösen von Namen für dev.microsoft.com Folgendes ermitteln kann:

In Abbildung 8-2 wurde beispielsweise die Autorität für die Zone dev.microsoft.com vom Namenserver für die Domäne microsoft.com. an den Namenserver devdns.dev.microsoft.com mit der IPv4-Adresse 157.60.41.59. delegiert. Folgende Datensätze müssen zur Zonendatei für die Zone microsoft.com. hinzugefügt werden:

dev.microsoft.com.          IN      NS   devdns.dev.microsoft.com. 
devdns.dev.microsoft.com.   IN      A    157.60.41.59

Ohne den Delegationsdatensatz für dev.microsoft.com schlagen Abfragen für alle Namen fehl, die mit dev.microsoft.com enden. Verbindungsdatensätze werden benötigt, wenn der Name des für die delegierte Zone autorisierenden Namenservers in der Domäne des Namenservers ist, der die Namensauflösung versucht. Im oben aufgeführten Beispiel wird ein A-Datensatz für devdns.dev.microsoft.com. benötigt, da sich dieser FQDN im Bereich microsoft.com. des DNS-Namespace befindet. Ohne diesen A-Datensatz kann der microsoft.com.-DNS-Server den Namenserver für die Zone dev.microsoft.com. nicht finden, und alle Namensauflösungen für Namen in der Domäne dev.microsoft.com schlagen fehl. Verbindungsdatensätze werden nicht benötigt, wenn sich der Name des für die delegierte Zone autorisierenden Namenservers in einer anderen Domäne als der Domäne der Zonendatei befindet. In diesem Fall verwendet der DNS-Server normale iterative Abfragen, um den Namen in eine IP-Adresse aufzulösen.

Der DNS-Serverdienst in Windows Server 2003 fügt beim Delegieren einer untergeordneten Domäne automatisch Delegations- und Verbindungsdatensätze hinzu.

Die Datei für Stammhinweise

Die Datei für Stammhinweise, auch Cachedatei genannt, enthält die Namen und Adressen von Stammservern. Zum Auflösen von Domänennamen im Internet verfügt die mit dem DNS-Serverdienst in Windows Server 2003 bereitgestellte Standarddatei über die Datensätze für die Stammserver des Internets. Für nicht mit dem Internet verbundene Installationen sollte die Datei mit einer ersetzt werden, die die Namenserver enthält, die für den Stamm des privaten Netzwerks autorisierend sind. Diese Datei heißt Cache.dns und ist im Ordner systemroot/System32/Dns gespeichert.

Die aktuelle Cachedatei für das Internet finden Sie auf der FTP-Site für InterNIC (in englischer Sprache).

Zum Seitenanfang

Zonenübertragungen

Sekundäre Namenserver erhalten Zonendateien von einem Master-Namenserver mithilfe einer Zonenübertragung. Eine Zonenübertragung repliziert die Datensätze in der Zonendatei vom Masterserver auf den sekundären Server. Zonenübertragungen werden für alle Zonen ausgeführt, für die ein DNS-Server beim Starten ein sekundärer Namenserver ist. Danach werden sie fortlaufend durchgeführt, um sicherzustellen, dass die lokale Zonendatei die aktuellsten Informationen zur Zone enthält. Es gibt zwei Typen von Zonenübertragungen, die vollständige und die inkrementelle Übertragung.

Vollständige Zonenübertragung

In den ursprünglichen DNS-RFCs wurden Zonenübertragungen als Übertragung der gesamten Zonendatei definiert, unabhängig von Änderungen an der Datei nach der letzten Übertragung. Bei vollständigen Zonenübertragungen wird folgender Vorgang durchgeführt:

Abbildung 8-7 zeigt eine vollständige Zonenübertragung.

Abbildung 8-7  Eine vollständige Zonenübertragung
Abbildung vergrößern

Wenn der sekundäre Server keine Antwort auf die SOA-Abfrage erhält, werden die SOA-Abfragen gemäß einem im SOA-Ressourcendatensatz der lokalen Zonendatei festgelegten Wiederholungsintervall wiederholt. Der sekundäre Server fährt mit den Wiederholungen fort, bis die vergangene Zeit für die Durchführung einer Zonenübertragung einen Ablaufzeitpunkt erreicht, der im SOA-Ressourcendatensatz der lokalen Zonendatei festgelegt ist. Nach dem Ablaufzeitpunkt schließt der sekundäre Server die Zonendatei und verwendet sie nicht zur Beantwortung nachfolgender Abfragen. Der sekundäre Server versucht weiter, die Zonenübertragung durchzuführen. Wenn die Zonenübertragung erfolgreich ist, wird die lokale Zonendatei geöffnet und für nachfolgende Abfragen verwendet.

Inkrementelle Zonenübertragung

Bei einer vollständigen Zonenübertragung wird die gesamte Zonendatei übertragen. Dies kann einen erheblichen Teil der Verarbeitungsressourcen und Netzwerkbandbreite belegen, wenn die Zonendateien groß sind und Zonendatensätze häufig geändert werden. Zur Minimierung der Informationsmenge, die bei Änderungen an Zonendatensätzen in Zonenübertragungen gesendet wird, gibt RFC 1995 eine Standardmethode für die Durchführung inkrementeller Zonenübertragungen an. Bei inkrementellen Zonenübertragungen werden nur Ressourcendatensätze während der Zonenübertragung gesendet, die geändert wurden (hinzugefügt, gelöscht oder geändert).

Bei inkrementellen Zonenübertragungen führt der sekundäre Server die gleiche Abfrage des SOA-Datensatzes des Masterservers durch und vergleicht die jeweiligen Felder für die Seriennummer. Wenn Änderungen vorhanden sind, sendet der sekundäre Server eine IXFR-Anforderung (eine Anforderung für eine inkrementelle Zonenübertragung) an den Masterserver. Der Masterserver sendet die geänderten Datensätze, und der sekundäre Server erstellt aus den nicht geänderten Datensätzen und den Datensätzen aus der inkrementellen Zonenübertragung eine neue Zonendatei.

Abbildung 8-8 zeigt eine inkrementelle Zonenübertragung.

Abbildung 8-8  Eine inkrementelle Zonenübertragung
Abbildung vergrößern

Damit der Masterserver die Datensätze ermitteln kann, die sich geändert haben, muss dieser eine Verlaufsdatenbank für Änderungen an den Zonendateien verwalten. Die Änderungen an den Zonendateien sind mit einer Seriennummer verknüpft, damit der Masterserver ermitteln kann, welche Änderungen nach der Seriennummer vorgenommen wurden, die in der IXFR-Anforderung des sekundären Servers angegeben ist.

Der DNS-Serverdienst in Windows Server 2003 unterstützt inkrementelle Zonenübertragungen.

DNS-Benachrichtigung

Bei vollständigen und inkrementellen Zonenübertragungen initiiert stets der sekundäre Server die Zonenübertragung, basierend auf der regelmäßigen Abfrage des SOA-Datensatzes des Masterservers. Die ursprünglichen DNS-RFCs definieren keinen Benachrichtigungsmechanismus für den Fall, dass vom Masterserver eine große Anzahl von Änderungen an die sekundären Server weitergegeben werden soll.

Um die Datenkonsistenz auf den sekundären Servern zu verbessern, spezifiziert RFC 1996 die DNS-Erweiterung DNS Notify (DNS-Benachrichtigung). Diese Erweiterung ermöglicht es Masterservern, Benachrichtigungen über eventuell notwendige Zonenübertragungen an sekundäre Server zu senden. Nach dem Empfang einer DNS-Benachrichtigung fordern sekundäre Server den SOA-Datensatz ihres Masterservers an und initiieren gegebenenfalls eine vollständige oder inkrementelle Zonenübertragung.

Abbildung 8-9 zeigt den Vorgang der DNS-Benachrichtigung.

Abbildung 8-9  Der DNS-Benachrichtigungsvorgang
Abbildung vergrößern

Der Masterserver verwaltet für jede Zone eine Benachrichtigungsliste (eine Liste mit IP-Adressen), um die sekundären Server zu ermitteln, an die Benachrichtigungen gesendet werden sollen. Wenn die Zone aktualisiert wird, sendet der Masterserver Benachrichtigungen nur an Server, die in der Benachrichtigungsliste enthalten sind.

Der DNS-Serverdienst in Windows Server 2003 unterstützt die Konfiguration einer Benachrichtigungsliste (einer Liste mit IPv4-Adressen) für jede Zone.

Zum Seitenanfang

Dynamisches DNS-Update

DNS wurde ursprünglich als Schema zur Namensauflösung relativ statischer Namen und Adressen definiert. DNS-Datensätze enthielten Informationen zu Servern, deren Namens- und Adresskonfiguration nicht häufig geändert wurde. Aus diesem Grund war die manuelle Verwaltung von Ressourcendatensätzen in Zonendateien überschaubar. Diese ursprünglichen Annahmen funktionieren gut in Umgebungen, die auf statisch konfigurierten Servern und Clientcomputern basieren, in denen die Clientcomputer nur mit den Servercomputern kommunizieren und in denen die Adresskonfiguration nicht geändert wird. Mit der Einführung von Peer-to-Peer-Kommunikation und -Anwendungen sowie DHCP (Dynamic Host Configuration Protocol) sind die beiden Annahmen des statischen DNS in Frage gestellt. In einer Windows-basierten Umgebung kommunizieren Clientcomputer häufig direkt miteinander und werden mithilfe von DHCP automatisch konfiguriert. Clientcomputer müssen den Namen des jeweils anderen Clientcomputers auflösen können, um miteinander zu kommunizieren. Aus diesem Grund müssen sie über entsprechende DNS-Ressourcendatensätze verfügen. Mit DHCP konnte sich die Adresskonfiguration von Clientcomputern bei jedem Start ändern. Das manuelle Verwalten von DNS-Datensätzen für eine solche Umgebung ist offensichtlich unpraktisch.

Aus diesem Grund definiert RFC 2136 das dynamische DNS-Update. Durch das dynamische Aktualisieren von Zonendaten auf einem primären Server einer Zone steht hiermit eine automatisierte Methode zum Füllen des DNS-Namespace mit den aktuellen Namen und Adressen von Client- und Servercomputern zur Verfügung. Mit dynamischen DNS-Updates werden DNS-Datensätze automatisch erstellt, geändert und entfernt, entweder von Hostcomputern oder von DHCP-Servern in deren Auftrag. Zum Beispiel sendet ein Clientcomputer, der dynamische DNS-Updates unterstützt, UPDATE-Nachrichten an seinen DNS-Server, um automatisch A-, AAAA- und PTR-Datensätze hinzuzufügen. Der DNS-Server, der ebenfalls dynamische DNS-Updates unterstützen muss, überprüft, ob der Clientcomputer zum Durchführen der Aktualisierung berechtigt ist, und aktualisiert dann seine lokalen Zonendateien.

Der DNS Clientdienst in Windows XP und Windows Server 2003 und der DNS-Serverdienst in Windows Server 2003 unterstützen dynamische DNS-Updates.

Zum Seitenanfang

Kapitelzusammenfassung

Dieses Kapitel enthält die folgenden wichtigen Informationen:

Zum Seitenanfang

Kapitelglossar

DNS – Siehe "Domain Name System (DNS)".

Dynamísches DNS-Update – Eine Aktualisierung des DNS-Standards, die es DNS-Clients ermöglicht, ihre Ressourcendatensätze automatisch in den Zonen des primären Servers zu registrieren und zu aktualisieren.

DNS-Server – Ein Server, der eine Datenbank mit Zuweisungen von FQDNs zu verschiedenen Datentypen, wie z. B. IP-Adressen, verwaltet.

Domäne – Jeder Zweig des DNS-Namespace.

Domain Name System (DNS) – Eine hierarchische, verteilte Datenbank, die Zuweisungen von DNS-Domänennamen zu verschiedenen Datentypen, wie z. B. IP-Adressen, verwaltet. DNS ermöglicht das Suchen von Computern und Diensten über benutzerfreundliche Namen und die Suche nach anderen Informationen, die in der Datenbank gespeichert sind.

Forward-Lookup – Eine DNS-Abfrage, die einem FQDN eine IP-Adresse zuweist.

Weiterleitung – Ein DNS-Server, der von anderen internen DNS-Servern zum Weiterleiten von Abfragen für das Auflösen von externen bzw. Offsite-DNS-Domänennamen verwendet wird, wie die im Internet verwendeten Domänennamen.

FQDN – Siehe "Fully Qualified Domain Name".

Fully Qualified Domain Name (FQDN – Voll qualifizierter Domänenname) - Ein DNS-Name, der die absolute Position in der Domänennamespace-Baumstruktur angibt. Ein FQDN hat einen nachstehenden Punkt (.), um seine Position relativ zum Stamm des Namespace zu kennzeichnen. Ein Beispiel ist host.example.microsoft.com.

Hostname – Der DNS-Name eines Hosts oder einer Schnittstelle in einem Netzwerk. Damit ein Computer einen anderen finden kann, muss der Name des zu findenden Computers entweder in der Hosts-Datei auf dem suchenden Computer oder auf einem DNS-Server vorhanden sein. Bei den meisten Windows-basierten Computern stimmen Hostname und Computername überein.

Hostnamensauflösung – Der Vorgang des Auflösens eines Hostnamens in eine Ziel-IP-Adresse.

Hosts-Datei – Eine lokale Textdatei im gleichen Format wie die Datei /etc/hosts der BSD-UNIX-Version 4.3. Diese Datei weist Hostnamen IP-Adressen zu und ist im Ordner systemroot\System32\Drivers\Etc gespeichert.

Iterative Abfrage – Eine Abfrage an einen DNS-Server, die die bestmögliche Antwort des Servers anfordert.

Masterserver – Ein DNS-Server, der für eine Zone autorisierend ist und auch als Quelle für Zoneninformationen für andere, sekundäre Server dient. Ein Masterserver kann entweder ein primärer oder ein sekundärer Masterserver sein, abhängig davon, wie er seine Zoneninformationen erhält.

Primärer Server – Ein DNS-Server, der für eine Zone autorisierend ist und als Aktualisierungspunkt für die Zone verwendet werden kann. Nur primäre Server können direkt zum Verarbeiten von Zonenaktualisierungen aktualisiert werden. Diese schließen das Hinzufügen, Entfernen und Ändern von Ressourcendatensätzen ein, die als Zonendaten gespeichert sind.

Rekursive Abfrage – Eine Abfrage an einen DNS-Server, in der der Server die gesamte Arbeitslast und Verantwortung für das Bereitstellen einer vollständigen Antwort auf die Abfrage übernimmt. Der DNS-Server sendet im Auftrag des Anfordernden separate iterative Abfragen an andere DNS-Server, um die Antwort auf die rekursive Abfrage zu vervollständigen.

Reverse-Lookup – Eine DNS-Abfrage, die einer IP-Adresse einen FQDN zuweist.

Stammdomäne – Der Anfang des DNS-Namespace.

Sekundärer Server – Ein DNS-Server, der für eine Zone autorisierend ist und seine Zoneninformationen von einem Masterserver erhält.

Domäne der zweiten Ebene (Second-Level Domain) – Ein DNS-Domänenname, der seinen Stamm hierarchisch auf der zweiten Ebene des Domänennamespace hat, direkt unterhalb der Domänen der obersten Ebene . Zu den Domänennamen der obersten Ebene gehören .com und .org. Wenn DNS im Internet verwendet wird, sind Domänen der zweiten Ebene Namen, die auf einzelne Organisationen und Unternehmen registriert und an diese delegiert sind.

Untergeordnete Domäne – Eine DNS-Domäne, die in der Namespacestruktur direkt unterhalb einer anderen Domäne (der übergeordneten Domäne) positioniert ist. Beispielsweise ist example.microsoft.com eine untergeordnete Domäne der Domäne microsoft.com.

Domänen der obersten Ebene (Top-Level Domains) – Domänennamen, die ihre Stämme hierarchisch auf der ersten Ebene des Domänennamespace haben, direkt unterhalb des Stamms (.) des DNS-Namespace. Im Internet werden Domänennamen der obersten Ebene wie .com und .org zum Klassifizieren und Zuweisen von Domänennamen der zweiten Ebene (wie microsoft.com) zu einzelnen Organisationen und Unternehmen verwendet, abhängig vom Typ der Organisation.

Zone – Ein verwaltbarer Bereich der DNS-Datenbank, der von einem DNS-Server verwaltet wird. Eine Zone speichert die Domänennamen und die Daten der Domäne mit entsprechendem Namen, ausgenommen Domänennamen, die in delegierten untergeordneten Domänen gespeichert sind.

Zonenübertragung – Die Synchronisierung von autorisierenden DNS-Daten zwischen DNS-Servern. Ein mit einer sekundären Zone konfigurierter DNS-Server fragt zur Synchronisierung seiner Zonendaten regelmäßig seinen Masterserver ab.

Zum Seitenanfang

9 von 20