Was muss ich beim DNS für Active Directory beachten? (Reloaded)

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.

Update 3. August 2010: Microsoft hat nun eine eigene „offizielle“ und umfassende Liste an Empfehlungen veröffentlicht. Siehe dazu:

[faq-o-matic.net » DNS für AD: Die offiziellen Empfehlungen]
http://www.faq-o-matic.net/2010/08/03/dns-fr-ad-die-offiziellen-empfehlungen/

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-Server konfiguriert sein.
  (Zudem sollte es zwei WINS-Server geben, idealerweise auch auf den DCs. Viel mehr als zwei sollten es normalerweise nicht sein.)
  Hinweis: WINS ist heutzutage nicht mehr zu empfehlen, weil Microsoft es nicht mehr pflegt. Zwar kann es in einigen Situationen dazu beitragen, Kommunikationsfehler zu umgehen, trotzdem sollte man heute lieber darauf verzichten.
• Der Name der DNS-Zone wird identisch mit dem AD-Namen gewählt.
• Konfigurationsoptionen der DNS-Zone: „Active-Directory-integriert“, sichere Updates zulassen.
  (Dadurch ist es nur einmalig nötig, die Zone einzurichten. Alle anderen DCs, die auch DNS-Server sind, erhalten die Zone automatisch, sie muss dort nicht separat eingerichtet werden. Einfach DNS-Server installieren und eine Weile warten.)
• Der Name von AD und DNS sollte ein echter DNS-Name sein, also (mindestens) einen Punkt und eine TLD enthalten und somit kein Single-Label-DNS darstellen!
  (Heißt: „firma.de“ oder „ad.firma.de“ und nicht nur „firma“!)
• Eine Reverse-Lookup-Zone für das Netzwerk ist nicht zwingend erforderlich, hilft aber, manche Probleme zu vermeiden.
• 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! Auch nicht als sekundären Eintrag.
  Falls eine Internet-Namensauflösung durch die Clients gewünscht ist, sollte man auf den DNS-Server einen Forwarder (Weiterleitung) auf den DNS-Server des Providers bzw. auf einen anderen externen DNS-Server eintragen.
• Jeder DC bzw. DNS-Server muss selbst natürlich auch als DNS-Client konfiguriert sein.
  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.
• In den DNS-Client-Einstellungen des DNS-Servers 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.
  (Achtung, diese Empfehlung ist umstritten. So spricht Microsofts Support oft eine gegenteilige Empfehlung aus. Da unsere Empfehlung auf Problemen beruht, die vor mehreren Jahren beobachtet wurden – siehe etwa einen alten KB-Eintrag -, beharren wir nicht auf diesem Punkt. Die Loopback-Adresse kann z.B. besser sein, wenn sich die IP-Adresse des Servers mal ändert. Es gibt allerdings auch heute in speziellen Situationen Probleme, die durch die Loopback-Adresse erzeugt werden, siehe dazu z.B. diese ADDE-Diskussion.)
• 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.