Die Best Practices für die Active Directory (AD)-Domain-Gestaltung empfehlen die Verwendung eines registrierten Domainnamens als Namen einer AD-Domain. Zu den möglichen Alternativen gehört die Verwendung eines nicht öffentlichen DNS Suffix (z. b. local oder . LAN) im AD-Domainnamen oder die Erstellung der AD-Domain zu einer unter Domain der registrierten Domäne (z. b.Corp.Domain.com).
Sie können in der Angelegenheit jedoch nicht immer eine Auswahl treffen. möglicherweise unterstützen Sie eine AD-Domain, die denselben Namen wie die registrierte Domain des Unternehmens hat, und das Management möchte eventuell keinen der Namen ändern. Dies wird als Split- DNS -Szenario (oder Split-Brain-DNS) bezeichnet, in dem zwei verschiedene DNS-Namespaces vorhanden sind: der interne Namespace, der von AD verwendet wird, und der externe Namespace, der vom Public Domain-Registrar verwendet wird, mit demselben Namen. In diesem Szenario werden einige besondere Herausforderungen dargestellt. In diesem Artikel werden einige häufig auftretende Probleme in einer Split-DNS-Umgebung beschrieben.
In den nachfolgenden Beispielen werden die AD-Domain und die registrierte Domäne als Domain.combezeichnet und es gibt eine Unternehmenswebsite namens www.Domain.com.
Problem 1: Extern gehostete Unternehmenswebsite, die nicht im Büro
verfügbar ist Dies ist das häufigste Problem in einer Split-DNS-Umgebung: die Website des Unternehmens oder eine andere unternehmenseigene, mit dem Internet verbundene Ressource kann nicht über das Innere des Büros von Computern erreicht werden, die der AD-Domain hinzugefügt werden, aber Maschinen außerhalb des Büros haben keine Probleme, die Website zu erreichen. Der Grund dafür ist, dass Sie untersuchen, was geschieht, wenn ein interner Benutzer versucht, die Website des Unternehmens zu durchsuchen:
Das Problem tritt auf, weil ein DNS-Server, der über eine bestimmte Suchzone in der Datenbank verfügt – die Domain.com -Zone in diesem Beispiel – sendet keine Abfragen für Datensätze in dieser Zone anderswo; Er gibt einfach eine "not found"-Antwort zurück, wenn kein Daten Satz mit einer bestimmten Abfrage übereinstimmt. In diesem Beispiel gibt es einen anderen DNS Server mit dem richtigen Daten Satz: der DNS-Server, der die öffentliche Domain.com -Zone hostet, die zum Domain-Registrar gehört, wie durch die Tatsache ersichtlich, dass Maschinen außerhalb des Büros die Website erreichen können. Abfragen von internen Maschinen greifen zwar nie auf diesen Server zu.
Die Lösung für dieses Problem ist einfach: Erstellen Sie einen Host-Eintrag mit dem Namen www in der Domain.com -Zone auf dem DC und geben Sie ihm die IP-Adresse der Website. Maschinen, die DNS-Server Abfragen, erhalten dann die richtige Antwort und können die Website durchsuchen.
Problem 2: Intern gehostete öffentliche Website unzugänglich im Büro
Hierbei kann es sich um eine Variation von Problem 1 oben handeln. Der Unterschied in diesem Fall besteht darin, dass die Website intern gehostet wird, entweder hinter einer Firewall im internen Netzwerk des Unternehmens oder in einer DMZ. Er sollte sowohl für interne als auch externe Benutzer zugänglich sein, aber interne Benutzer können diese nicht erreichen, während externe Benutzer keine Probleme melden.
Der Grund für das Problem ist ähnlich wie in Problem 1. interne Benutzer in diesem Fall sind in der Lage, den Namen der Website in der öffentlichen IP-Adresse korrekt aufzulösen. Allerdings sind Sie nach wie vor nicht in der Lage, die Website zu erreichen, da die Firewall konfiguriert ist. Es wird davon ausgegangen, dass Benutzer im internen Netzwerk über die private Adresse und nicht über die öffentliche Adresse auf die Website zugreifen.
Es gibt auch hier eine einfache Korrektur: Erstellen Sie einen Host-Daten Satz mit dem Namen www in der Domain.com -Zone auf dem DC, aber dieses Mal geben Sie dem Daten Satz die private IP-Adresse der Website. Interne Maschinen löst den Namen der Website in dieser privaten Adresse auf, während externe Maschinen den Namen weiterhin in der öffentlichen Adresse der Website auflösen.
Problem 3: Die Website wird unvollständig geladen oder wird nach der obigen Änderung
weiterhin nicht geladen. Dies kann der Fall sein, wenn der Website Code Browser von www.Domain.com zu Domain.com umleitet oder wenn sich interne Links auf den Standort als Domain.com und nicht auf www.Domain.combeziehen. Auf internen Computern werden dieselben Symptome angezeigt, unabhängig davon, ob der standortintern oder extern gehostet wird:
In diesem Fall ist das Problem etwas komplizierter. Damit Maschinen Domain.com in eine IP-Adresse auflösen können, muss in der Domain.com -Zone in DNS ein unbelegter Host-Eintrag vorhanden sein. Der Name dieses Datensatzes wird als (derselbe als übergeordneter Ordner) in der Windows DNS Konsole angezeigt. In diesem Fall gibt es jedoch ein Problem: AD verwendet in der Domain.com -Zone Platz freie Hostdatensätze zur Darstellung von DCS für die Domain.com -Domain. Domain Mitglieder verwenden diese Datensätze, wenn Sie einen Gleichstrom für die Authentifizierung suchen. Wenn in der Domain.com -Zone zusätzliche Platz für Hosteinträge vorhanden sind, kann dies zu Verzögerungen oder Authentifizierungsproblemen führen.
Aus diesem Grund kann dieses Problem nicht in DNS allein gelöst werden. Das Erstellen eines unbelegten Host Datensatzes mit der IP-Adresse der Website löst nur vorübergehend das Problem mit dem Website Zugriff für interne Benutzer auf, weil es bereits andere unbelegte Hostdatensätze mit den IP-Adressen des DCS in der Domain gibt. Dies führt zu Domänen Authentifizierungsproblemen.
Die einfachste Methode, dieses Problem zu lösen, besteht darin, den Code der Website so zu ändern, dass entweder die Umleitung entfernt oder die internen Links repariert werden, sodass sich alles auf den Standort als www.Domain.com und nicht auf Domain.combezieht. Wenn der Code nicht geändert werden kann, besteht die einzige andere Option zum Lösen des Problems darin, die AD-Domain umzubenennen. Dies kann eine komplexe Aufgabe sein, je nach Größe und Komplexität der Umgebung.