Situation:
- Wir haben eine DR-Site, die getestet werden muss
Auf der DR-Site gibt es eine Mischung aus Linux- und Windows-Hosts. Im Katastrophenfall, wenn der SERVER auf der Produktionssite nicht verfügbar ist, wird SERVER_DR auf DR eingeschaltet und derselben Windows-Domäne hinzugefügt. Dies wird auf diese Weise durchgeführt, wenn die primäre Site nicht verfügbar ist und wir den ursprünglichen Datensatz für SERVER aus AD nicht löschen möchten.
Das Problem, das ich zu lösen versuche, ist eine Namensauflösung auf der DR-Site. Prozesse und Skripte verwenden den DNS-Namen SERVER, daher sollten Anfragen an SERVER auf der DR-Site in SERVER_DR übersetzt werden. Wir haben keinen Zugriff, um irgendetwas auf Windows DNS zu tun.
Meine Idee ist, BIND zu verwenden, um dieses Problem zu lösen. Hosts in DR sollten sich mit AD authentifizieren können. Die Tatsache, dass sie auf nichts anderes außerhalb der DR-Site in der Windows-Domäne zugreifen müssen, sollte das Problem vereinfachen.
Dienste, auf die DR-Hosts zugreifen müssen, sind meist File-Sharing- und SQL-Server. Ich glaube, SQL-Server könnten hier ein Problem darstellen, da sie SPN verwenden.
Dies bringt mich auf die Idee, BIND für unsere von BIND auf der DR-Site gehaltene Zone .domain.com zu verwenden. Ich sehe jedoch ein mögliches Problem, wenn sich Windows DR-Hosts gegenüber AD authentifizieren müssen, da sie, wenn ich mich recht erinnere, nicht bewertete Datensätze verwenden müssen. Aus den zuvor genannten Gründen können wir Zonen nicht von AD delegieren.
Lohnt sich die Mühe, dieses Problem zu lösen? Einer meiner Kollegen hat vorgeschlagen, für jeden Windows DR-Host eine Hosts-Datei zu verwenden. Allerdings sieht das ziemlich hässlich aus, da es nicht viele davon gibt und meine Zeit mit der Einrichtung von BIND möglicherweise verschwendet ist.
Antwort1
Mit HOSTS-Dateien funktioniert die AD-Authentifizierung nicht ordnungsgemäß. Für die AD-Authentifizierung sind die SRV-RRs erforderlich, die nur ein DNS-Server bereitstellen kann (da eine HOSTS-Datei nur aus A-RRs besteht).
Schauen Sie hier nach einer früheren Antwort von mir zur Verwendung von BIND zur Unterstützung von AD:Verwenden von BIND9 und DHCPD zur Unterstützung einer Windows-Domäne
Wenn die Computernamen auf Ihrem Windows-Server unterschiedlich sind, werden Sie Probleme mit der ordnungsgemäßen Funktion einiger Software haben. Der Versuch, den Nicht-DR-Namen einfach einem Windows-Server mit einem anderen Computernamen zuzuordnen, funktioniert bei einigen Protokollen, bei anderen jedoch nicht (SPNs im AD sind beispielsweise an Computernamen „gebunden“).
Mir ist nicht klar, warum Sie Windows DNS nicht auf der DR-Site verwenden können. Ich würde denken, dass Sie einen Windows DNS-Server einrichten und im schlimmsten Fall die Zone _msdcs.domain.com an den Windows DNS-Server in der vorhandenen BIND-Infrastruktur delegieren könnten.
Ich denke, ich müsste etwas besser verstehen, was Sie erreichen möchten und warum Sie diese Einschränkungen haben. Generell würde ich jedoch darauf hinwirken, die DR-Umgebung möglichst nah an die Produktionsumgebung heranzubringen, damit der Arbeitsaufwand beim Verschieben von Vorgängen in die DR-Umgebung so gering wie möglich ist.
Antwort2
Es gibt keine einfache Möglichkeit, Hosts auf der DR-Site dazu zu bringen, „SERVER“ in die IP-Adresse von SERVER_DR aufzulösen und dabei alle AD-DNS-Sachen am Laufen zu halten. Was Sie tun müssen, ist, für alle Serverreferenzen einen Alias zu verwenden.
Normalerweise gehe ich so vor, dass ich eine neue Domäne (z. B. mydomain.site) erstelle, die nicht in AD integriert ist. Auf diese Weise können Sie separate und unterschiedliche Zonendateien für unterschiedliche DNS-Server verwenden. Ändern Sie dann alle Verweise auf Ihre Server in server.mydomain.site. Auf diese Weise können Ihre Benutzer einen einzigen Servernamen verwenden, der sich in das für die Site Passende auflösen lässt.
Hinweis: Damit die Windows-Dateifreigabe mit einem CNAME-Alias funktioniert, müssen Sie einen Registrierungseintrag für den LanManServer-Dienst hinzufügen. Siehehttp://support.microsoft.com/kb/281308für Details. Dies funktioniert sowohl unter W2k8 als auch unter 2k und 2k3.
Ich empfehle Ihnen dringend, den Windows-DNS zum Hosten der .site-Domäne zu verwenden. Wenn Sie Ihre Systemadministratoren wirklich nicht zum Helfen überreden können, können Sie BIND verwenden und die Windows-DNS-Server als Weiterleitungen konfigurieren. Dann würde BIND die .site-Domäne auflösen, während Windows für alle anderen Domänen einschließlich der AD-Domäne verwendet würde. Dies macht die Wartung jedoch komplexer, daher würde ich es nach Möglichkeit vermeiden.
JR
PS zu „NB, damit die Dateifreigabe unter Windows mit einem CNAME-Alias funktioniert“
Der Sinn der Verwendung des Alias besteht darin, dass Sie Freigaben durchsuchen oder Netzlaufwerke mit UNC-Namen wie \myserver.mydomain.site\share zuordnen können, wobei der Name „myserver.mydomain.site“ in die IP-Adresse Ihres Zielservers aufgelöst wird und an verschiedenen Standorten in unterschiedliche IP-Adressen aufgelöst werden kann. Standardmäßig lässt der LanManServer-Dienst das Durchsuchen nicht zu, es sei denn, der Servername stimmt mit dem tatsächlichen Servernamen überein. In diesem Fall erhalten Sie eine Fehlermeldung wie „Im Netzwerk ist ein doppelter Name vorhanden“. Dies dient der Erhöhung der Sicherheit. Der erwähnte KB-Artikel beschreibt, wie Sie die Namensüberprüfung deaktivieren, damit UNC-Namen wie die oben genannten funktionieren.
Tatsächlich verwende ich diesen Trick routinemäßig, da er das Verschieben von Dateifreigaben auf andere Server vereinfacht. Es ist kein Ersatz für DFS, kann aber ein nützlicher Trick sein.