DNS ist eines der wichtigsten Themen im Zusammenhang mit Active Directory. Ein FAQ-Artikel kann hier keine umfassende Anleitung geben. Da aber viele Administratoren nicht genau wissen, was sie beim DNS berücksichtigen müssen, hier ein paar Hinweise.

Man beachte: Es gibt drei wesentliche Problemquellen im Zusammenhang mit Active Directory und Exchange:

• Namensauflösung
• Namensauflösung
• Namensauflösung

Beim DNS-Design können einfache von komplexeren Umgebungen unterschieden werden. Unter "einfach" sind hier Netzwerke mit einem einzigen Standort zu verstehen, in denen ein zusammenhängendes IP-Subnetz für das LAN verwendet wird. In diesen Umgebungen führen die folgenden Empfehlungen zu einer sinnvollen DNS-Umgebung:

• Alle DCs sollten als DNS- und WINS-Server konfiguriert sein.
• Der Name der DNS-Zone wird identisch mit dem AD-Namen gewählt. Konfigurationsoptionen: "Active-Directory-integriert", sichere Updates zulassen.
• Der Name von AD und DNS sollte ein echter DNS-Name sein, also einen Punkt und eine TLD enthalten und simit kein Single-Label-DNS darstellen! (Heißt: "firma.de" oder "ad.firma.de" und nicht nur "firma")
• Jedes Domänenmitglied sollte mindestens zwei der DCs als DNS-Server eingetragen bekommen (und idealerweise auch mindestens zwei WINS-Server). Das lässt sich über DHCP sehr effizient einrichten. Achtung: Auf keinen Fall einen externen DNS-Server (z.B. den des Providers) bei einem Client eintragen!
• Jeder DC bzw. DNS-Server muss selbst natürlich auch als DNS-Client konfiguriert sein. Hierbei sollten stets reale IP-Adressen eingetragen werden; die Loopback-Adresse 127.0.0.1, die der dcpromo-Assistent einträgt, sollte durch die echte Adresse ersetzt werden. Grundsätzlich ist es empfehlenswert, dass der primäre Eintrag auf einen anderen DNS-Server zeigt und der sekundäre auf die eigene Adresse. Dadurch lassen sich einige Fehlersituationen vermeiden.
• Die DCs müssen korrekt im DNS eingetragen sein (A-Einträge, SRV-Einträge, PTR-Einträge)
  : um dies zu erzwingen ggf. im CMD-Fenster ausführen (nacheinander):
  ipconfig /flushdns
  ipconfig /registerdns
  net stop netlogon
  net start netlogon
• Jeder Client und jeder Server muss im DNS eingetragen sein, und zwar vor allem in der Forward-, zusätzlich gern auch in der Reverse-Lookup-Zone. Bei richtiger Konfiguration geschehen die Eintragungen automatisch.

In komplexeren Umgebungen, die aus mehreren IP-Subnetzen und/oder aus mehreren Standorten bestehen, sollten weitere Empfehlungen berücksichtigt werden, damit DNS nicht zur "Insel" wird. Folgendes Szenario könnte auftreten:

Am Hauptstandort ist Active Directory mit mehreren DNS-Servern korrekt konfiguriert. Nun soll ein Domänencontroller für eine Niederlassung aufgesetzt werden. Um den Vorgang effizient zu halten, wird der DC zunächst am Hauptstandort installiert und konfiguriert - logischerweise mit den IP-Adressen des Hauptstandorts. Der fertige Domänencontroller wird in die Niederlassung gebracht. Bei der Inbetriebnahme vor Ort wird seine IP-Konfiguration auf das Subnetz der Niederlassung angepasst. Der primäre DNS-Eintrag zeigt auf den Server selbst, denn er hat ja DNS installiert, und durch die bereits erfolgte Replikation kann er alle vorhandenen Ressourcen auflösen. Alles in Butter also. Alles in Butter?

Nein. Denn die Domänencontroller am Hauptstandort haben in ihren DNS-Zonen noch die "alte" IP-Adresse des Niederlassungs-DC stehen. Da dieser primär seine eigene DNS-Datenbank nutzt, wird auch nur diese aktualisiert. Die DNS-Server am Hauptstandort können also den Namen des Niederlassungs-DCs nicht auflösen. Dadurch schlägt die Active-Directory-Replikation fehl, und die Niederlassung wird zur Insel. Ähnliche Effekte können auftreten, wenn an einem der Standorte die IP-Adressen geändert werden.

Um solche Situationen zu vermeiden, sollte in Netzwerken mit mehreren Standorten eine DNS-Sterntopologie aufgebaut werden: Die DNS-Server der Außenstellen zeigen mit ihrem primären DNS-Eintrag auf einen Server des Hauptstandorts. Dadurch aktualisieren sie dort ihre eigenen Einträge, die dann durch die DNS-Replikation (idealerweise integriert in die AD-Replikation) an alle anderen DNS-Server verteilt werden. Der sekundäre bzw. weitere DNS-Server-Einträge können dann auf Server des eigenen Standorts bzw. auf die lokale Maschine zeigen, damit Unterbrechungen der WAN-Verbindung nicht zu lokalen Betriebsunterbrechungen führen. Eine solche Konfiguration vermeidet auch Probleme bei nächträglichen Änderungen der IP-Subnets.

Natürlich sollten diese Konfigurationen stets aktuell dokumentiert werden, damit mögliche Fehler schnell aufgedeckt werden können.

Zu diesem Thema vergleiche auch folgenden Newsgroup-Thread: http://groups.google.com/group/microsoft.public.de.german.windows.server.active_directory/browse_frm/thread/74b695bc8bfb8c73/afaa9654ec6f3f82?hl=de#afaa9654ec6f3f82

Für hilfreiche Anmerkungen außerdem besten Dank an Frank Carius.