PowerEdge: Website in einer Windows-Umgebung mit identischen internen und externen Domainnamen nicht erreichbar

In allen folgenden Beispielen heißen die AD-Domain und die registrierte Domain beide domain.com und es gibt eine Unternehmenswebsite mit dem Namen www.domain.com. Die identischen Domainnamen schaffen eine gespaltene (Split-Brain) DNS-Umgebung. In diesem Fall haben die internen und externen DNS-Namespaces denselben Namen, sind aber getrennt.

Problem 1: Auf eine extern gehostete Unternehmenswebsite kann vom Büro aus nicht zugegriffen werden.
Dies ist das häufigste Problem in einer gespaltenen DNS-Umgebung. Die Website des Unternehmens oder eine andere unternehmenseigene, mit dem Internet verbundene Ressource kann von Clients, die zur Domain hinzugefügt wurden, vom Büro aus nicht erreicht werden. Computer außerhalb des Büros haben keine Probleme, die Website zu erreichen.

Problem 2: Auf eine intern gehostete öffentliche Website kann vom Büro aus nicht zugegriffen werden.
Dies ist eine Variation von Problem 1 oben. Der Unterschied besteht darin, dass die Website intern gehostet wird, entweder hinter einer Firewall im internen Netzwerk des Unternehmens oder in einer DMZ. Sie soll sowohl für interne als auch für externe NutzerInnen zugänglich sein, aber interne NutzerInnen können sie nicht erreichen. Externe NutzerInnen melden keine Probleme.

Problem 3: Die Website wird unvollständig oder gar nicht geladen, nachdem Problem 1 oder 2 behoben wurde.
Die Website wird für interne NutzerInnen möglicherweise gar nicht oder nur unvollständig geladen. Teile der Website werden möglicherweise nicht angezeigt und Links innerhalb der Website funktionieren möglicherweise nicht. Externe NutzerInnen können ohne Probleme auf die Website zugreifen.

Problem 1: Auf eine extern gehostete Unternehmenswebsite kann vom Büro aus nicht zugegriffen werden.

Der Grund dafür lässt sich anhand dessen ermitteln, was passiert, wenn interne NutzerInnen versuchen, die Website des Unternehmens zu durchsuchen:

1. Der Computer fragt den DNS-Server der Domain, in der Regel einen Domaincontroller (DC), nach der IP-Adresse von www.domain.com.
2. Der DC hostet eine Forward-Lookup-Zone mit dem Namen domain.com, sodass in dieser Zone nach einem Hostdatensatz gesucht wird mit dem Namen www.
3. Der DC findet keinen Hostdatensatz mit dem Namen www und da er für die Zone domain.com autorisierend ist, wird die Abfrage nicht weitergeleitet.
4. Der DC antwortet dem Computer und teilt mit, dass keine Adresse gefunden werden konnte für www.domain.com.
5. Der Browser auf dem Computer zeigt „Seite kann nicht angezeigt werden“ oder einen ähnlichen Fehler an.

Das Problem tritt auf, weil ein autorisierender DNS-Server keine Abfragen nach Namen in seinen Zonen an andere DNS-Server sendet. Er gibt die Antwort „nicht gefunden“ zurück, wenn kein Datensatz vorhanden ist, der einer bestimmten Abfrage entspricht. In diesem Beispiel gibt es andere DNS-Server mit dem richtigen Eintrag: die DNS-Server, die die öffentliche Zone domain.com hosten. Dies zeigt sich daran, dass Maschinen außerhalb des Büros die Website erreichen können. Abfragen von internen Rechnern werden jedoch nicht an diesen Server gesendet.

Problem 2: Auf eine intern gehostete öffentliche Website kann vom Büro aus nicht zugegriffen werden.
Der Grund für das Problem ist ähnlich wie in Problem 1. Interne NutzerInnen können in diesem Fall den Namen der Website korrekt in ihre öffentliche IP-Adresse auflösen. Sie können die Website jedoch aufgrund der Art und Weise, wie die Firewall konfiguriert ist, immer noch nicht erreichen. Sie erwartet, dass NutzerInnen im internen Netzwerk mit ihrer privaten Adresse und nicht mit ihrer öffentlichen Adresse auf die Website zugreifen.

Problem 3: Die Website wird unvollständig geladen oder wird nicht geladen, nachdem Problem 1 oder 2 behoben wurde.
Dies kann passieren, wenn der Website-Code Browser weiterleitet, und zwar von www.domain.com an domain.com. Interne Links können auch auf die Website verweisen als domain.com statt als www.domain.com. Die gleichen Symptome treten auf internen Computern auf, unabhängig davon, ob der Standort intern oder extern gehostet wird.

Das Problem ist in diesem Fall etwas komplexer. Damit Computer domain.com eine IP-Adresse auflösen können, muss ein leerer Hostdatensatz in der Zone domain.com im DNS vorhanden sein. Der Name dieses Eintrags wird als (identisch mit dem übergeordneten Ordner) in der Windows DNS-Konsole angezeigt. AD verwendet jedoch leere Hostdatensätze in der Zone domain.com , um DCs darzustellen für die domain.com Domain. Wenn zusätzliche leere Hostdatensätze in der Zone domain.com vorhanden sind, kann es zu Verzögerungen oder Authentifizierungsproblemen kommen.

Aus den oben genannten Gründen kann dieses Problem nicht allein mit DNS behoben werden. Das Erstellen eines leeren Hostdatensatzes mit der IP-Adresse der Website löst das Problem des Websitezugriffs für interne NutzerInnen nur zeitweise. Die vorhandenen leeren Hostdatensätze, die sich auf DCs beziehen, stören dies aufgrund der Round-Robin-DNS-Funktionalität. Da diese Datensätze automatisch von den DCs registriert werden, werden sie regelmäßig wieder angezeigt, wenn sie aus der DNS-Zone entfernt werden.
 

Problem 1: Auf eine extern gehostete Unternehmenswebsite kann vom Büro aus nicht zugegriffen werden.
Die Lösung für dieses Problem ist einfach. Erstellen Sie einen Hosteintrag (A) mit dem Namen www in der Zone domain.com auf dem DC und geben Sie diesem Eintrag die IP-Adresse der Website. Computer, die diesen DNS-Server abfragen, erhalten dann die richtige Antwort und können die Website durchsuchen.

Problem 2: Auf eine intern gehostete öffentliche Website kann vom Büro aus nicht zugegriffen werden.
Auch dafür gibt es eine einfache Lösung. Erstellen Sie einen Hostdatensatz mit dem Namen www in der Zone domain.com auf dem DC, aber geben Sie dem Datensatz die private IP-Adresse der Website. Interne Computer lösen den Namen der Website in diese private Adresse auf, während externe Computer den Namen weiterhin in die öffentliche Adresse der Website auflösen.

Problem 3: Die Website wird unvollständig geladen oder wird nicht geladen, nachdem Problem 1 oder 2 behoben wurde.
Die einfachste Möglichkeit, dieses Problem zu beheben, besteht darin, den Code der Website zu ändern, um die Weiterleitung zu entfernen. Außerdem sollten interne Links auf die Website als www.domain.com und nicht als domain.com verweisen. Wenn eine Änderung des Codes nicht möglich ist, besteht die einzige andere Möglichkeit zur Behebung des Problems darin, die AD-Domain umzubenennen. Dies kann je nach Größe und Komplexität der Umgebung eine komplexe Aufgabe sein.

Anmerkung: Auf die Website muss mit dem Namen www.domain.com zugegriffen werden, und zwar in all diesen Beispielen. Zugriff auf die Website über den Namen domain.com funktioniert nicht oder nur sporadisch.

Best Practices für das AD-Domaindesign (Active Directory) raten davon ab, einen registrierten Domainnnamen als Namen einer AD-Domain zu verwenden. Dazu werden zwei Alternativen vorgeschlagen:

• Verwenden Sie ein nicht öffentliches DNS-Suffix (.local oder .lan, beispielsweise) im AD-Domainnamen.
• Machen Sie die AD-Domain zu einer Subdomain der registrierten Domain (corp.domain.com).

Dies ist nur möglich, wenn die AD-Domain noch nicht erstellt wurde oder wenn ein Umbenennungsvorgang im Gange ist.