Szenarien zur Namensauflösung - Domain Name Service und das Active Directory (2)

Lesezeit
4 Minuten
Bis jetzt gelesen

Szenarien zur Namensauflösung - Domain Name Service und das Active Directory (2)

24.09.2007 - 12:16
Veröffentlicht in:
Wir haben die Grundlagen und Komponenten des Domain Name Service besprochen und wie man eine DNS-Infrastruktur überprüfen kann. Nun wollen wir verschiedene Szenarien vorstellen, wie das Active Directory in eine DNS-Infrastruktur integriert werden kann. Außerdem werden wir Skripte und Tools zeigen, mit denen sich der DNS einrichten und verwalten lässt.
Der Domain Name Service (DNS) dient in einem Active-Directory- Netzwerk nicht nur zum Auffinden der Namen von Clients und Servern, sondern vor allem auch dazu, die Active-Directory- Dienste von Domänencontrollern zu finden. In diesem Artikel möchte ich auf die gebräuchlichsten Szenarien eingehen, wie man ein Active Directory (AD) in eine DNS-Infrastruktur einbinden kann.

DNS-Einträge für das Active Directory
Damit die Dienste der Domänencontroller (DC) in einem Active Directory von den Mitgliedern der Domäne gefunden werden können, werden diese von den DCs in die entsprechende DNS-Zone eingetragen.

Für die domänenspezifischen Dienste werden hierbei DNS-Subdomänen verwendet.Wenn zum Beispiel für eine Firma der Namensraum “firma.de” verwendet wird, werden in der Zone “firma.de” die DNS-Subdomänen “_msdcs.firma.de”, “_sites.firma.de”, “_tcp.firma.de” und “_udp.firma.de” eingerichtet (beim Windows Server 2003 gibt es noch zusätzlich die DNSSubdomänen “domainDnsZones” und “forestDnsZones”). In diesen DNSSubdomänen findet man alle Informationen über die Anmeldeserver und die “Globalen Katalogserver” (GC) der Umgebung sowie darüber,welche Server die Rolle des PDC-Emulators halten. Über die Struktur unterhalb dieser DNSSubdomänen können zum Beispiel die Domänenmitglieder auch einen bestimmten Dienst in einem ausgewählten Standort suchen.

Sowohl für die Anmeldung der Clients an die Active-Directory-Domäne wie auch für die Replikation zwischen den Domänencontrollern ist es wichtig, dass die Einträge der Domänencontroller und Dienste im DNS gefunden werden. Besondere Aufmerksamkeit verdienen hier die Einträge, die unterhalb der “_msdcs”-DNSDomäne der ersten Domäne in einer Gesamtstruktur (auch Rootdomäne) liegen: Unterhalb dieser DNS-Domäne werden von allen Domänenmitgliedern die Einträge der globalen Katalogserver gesucht. Haben Sie mehrere Active-Directory-Domänen über mehrere Standorte verteilt und die erste Domäne der Gesamtstruktur existiert nicht in allen Standorten, sollten Sie überlegen, wie Sie diese DNS-Subdomäne auch auf den DNS-Servern der weiteren Standorte zur Verfügung stellen. Der Windows Server 2003 berücksichtigt dies standardmäßig:Wenn Sie den DNSService beim Einrichten der Active-Directory- Domäne automatisch konfigurieren lassen, legt der Assistent eine separate Zone für die “_msdcs”-DNS-Domäne an und erstellt eine Delegation der übergeordneten Domäne. Das hat den Hintergrund, dass eine Zone unabhängig von anderen Zonen auf dem Server repliziert werden kann. Beim Einrichten des Active Directory konfiguriert der Windows Server 2003 diese Zone so, dass sie über das Active Directory auf alle DNSServer der Gesamtstruktur, die auch Domänencontroller sind, repliziert wird. Auch bei einem Windows-2000-Active- Directory wird aus dem gleichen Grund empfohlen, die “_msdcs”-DNS-Domäne der Rootdomäne als eigene Zone anzulegen. Damit ist der Administrator in der Lage, diese Zone als sekundäre Zone auf die DNS-Server in anderen Standorten zu übertragen – auch diejenigen, in denen kein DNS-Server der Rootdomäne steht.

Namensraum
Eine häufig gestellte Frage von Administratoren beim Einrichten von DNS lautet:“Welchen Namensraum soll ich verwenden?” Der Namensraum stellt die oberste in der DNS-Hierarchie verwendete DNS-Domäne dar. So würden in den Namensraum “company.com” auch alle DNS-Namen unterhalb dieser Domäne fallen, zum Beispiel auch “eu.company.com”. Für ein Active Directory muss mindestens ein Namensraum verwendet werden. Bei der Wahl des Namensraums sollten Sie beachten, dass der Name nicht von anderen Unternehmen registriert sein sollte, da dies unter Umständen zu rechtlichen Problemen führen könnte. Also sollten Sie entweder einen Namen verwenden, der für Sie registriert ist, oder einen, der nicht registrierbar ist. Betrachten wir jetzt einige DNS-Szenarien.

Einen privaten Namensraum verwenden
Häufig wird für den internen Namensraum ein Name wie “firma.local” verwendet, da “.local” derzeit kein offizieller Top-Level-Domänenname ist. Dies versteht man unter einem privaten Namen. Hierbei gibt es jedoch immer das Risiko, dass der Name in Zukunft einmal als Top-Level-Domänenname zugelassen wird. Zum Beispiel wird der Name “.local” derzeit in einem Internet Draft für Multicast-DNS-Namen vorgeschlagen, was zu Problemen führen kann,wenn dieser Namensraum im Netzwerk benutzt wird (siehe auch files. multicastdns.org/draft-cheshire-dnsextmulticastdns. txt).

Daher empfehle ich immer, einen offiziell registrierten Namen zu verwenden. Dies kann der Name sein, der für den offiziellen Internetauftritt Ihres Unternehmens verwendet wird, oder auch ein weiterer registrierter Name, der nicht benutzt wird. Ansonsten haben Sie mit einem privaten Namen aber den Vorteil, dass Sie ihn nicht offiziell registrieren müssen und dass Sie keine Konflikte zwischen dem internen und dem externen Namensraum zu lösen haben. Dabei werden die DNS-Namen wie folgt aufgelöst:
- Interne Clients lösen interne Namen über den internen DNS-Server auf.
- Interne Clients lösen externe Namen über den internen DNS-Server auf (dieser hat den DNS-Server des Internet Service Providers (ISP) als Weiterleitung eingetragen und fragt bei diesem nach).
- Interne Clients lösen den eigenen Webserver genauso auf wie alle anderen externen Namen.
- Externe Clients können interne Namen nicht auflösen.
- Externe Clients können den eigenen Webserver auflösen (über den DNSServer des ISP).
- Der Webserver kann extern und intern meistens über “http://firma.de” (ohne “www”) aufgelöst werden.

Intern und extern den gleichen Namensraum verwenden
Wenn Sie intern und extern den gleichen Namen verwenden (zum Beispiel “firma.de”), ist zu berücksichtigen, dass Ihre externen Webserver für die Anwender erreichbar bleiben müssen. Sorgen Sie deshalb dafür, dass die internen DNS-Server in der Lage sind, die externen Namen (wie “www.firma.de”) aufzulösen. Dies bedeutet einen zusätzlichen Verwaltungsaufwand für die Administratoren.

Hierbei gibt es zwei Möglichkeiten:
- Sie richten Host-Einträge (A-Records) im internen DNS-Server für die externen Server ein.Wenn der ISP die IP-Adressen ändert, müssen Sie dies auch im internen DNS verwalten.
- Sie richten eine Delegation für den Namen Ihrer Webserver auf den internen DNS-Servern ein. Diese werden auf die DNS-Server des ISP delegiert (zum Beispiel wird eine Delegation für “www”in der Zone “firma.de” erstellt, die auf die IP-Adresse des ISP zeigt). Wenn Ihr ISP jetzt die IP-Adressen der Webserver ändert, brauchen Sie keine Änderungen in den internen DNSEinträgen vorzunehmen.

Außerdem müssen Sie bei diesem Szenario berücksichtigen, dass der vollqualifizierte Domänenname (FQDN – Fully Qualified Domain Name) der Domäne von den Domänencontrollern und Clients benötigt wird. Im Internet mag Ihr Webauftritt auch unter “http://firma.de” erreichbar sein, intern wird und darf dies nicht der Fall sein. Bei Anfragen von Clients nach “firma.de” werden stets die IP-Adressen der Domänencontroller dieser Domäne zurückgegeben.

Bei diesem Szenario werden die DNSNamen wie folgt aufgelöst:
- Interne Clients lösen interne Namen über den internen DNS-Server auf.
- Interne Clients lösen externe Namen über den internen DNS-Server auf (dieser hat den DNS-Server des Internet Service Providers (ISP) als Weiterleitung eingetragen und fragt bei diesem nach).
- Interne Clients lösen den eigenen Webserver über den internen DNSServer auf. Der Administrator hat auf diesem den Eintrag entweder über einen Hosteintrag oder über eine Delegation auf den DNS-Server des ISP eingerichtet.
- Externe Clients können interne Namen nicht auflösen.
- Externe Clients können den eigenen Webserver auflösen (über den DNSServer des ISP).
- Der Webserver kann nur extern meistens über “http://firma.de” (ohne “www”) aufgelöst werden. Intern können die Clients den Webserver über diesen Namen nicht auflösen.

  Seite 1 von 3           /a>>/>Nächste Seite>>              





Ausgabe 04/05 des IT-Administrator Magazins S. 26- 31, Autor: Ulf B. Simon-Weidner

Ähnliche Beiträge

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (3)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im dritten und letzten Teil gehen wir auf weitere Varianten ein, etwa die ZTP-Provisionierung ohne proprietären Server, die Boot-Loader-Variante iPXE oder das alte Verfahren AutoInstall.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (2)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im zweiten Teil der Workshopserie schildern wir den proprietären Cisco-Ansatz "Network-Plug-and-Play", der über eine GUI erfolgt und bei dem sich die ausgerollten Komponenten an die Gegebenheiten im Netzwerk anpassen lassen.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (1)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Sowohl die Installation von Betriebssystemen als auch Applikationen erfolgt meist automatisiert. Im Gegensatz dazu kommen diese Prozesse bei Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im ersten Teil skizzieren wir die möglichen Rollout-Verfahren und beschreiben, welche Ansätze und Möglichkeiten sich Unternehmen hier bieten.