PowerEdge : Site Web inaccessible dans un environnement Windows avec des noms de domaine internes et externes identiques

Dans tous les exemples ci-dessous, le domaine Active Directory et le domaine enregistré sont tous deux nommés domain.com, et il existe un site Web d’entreprise nommé www.domain.com. Les noms de domaine identiques créent un environnement DNS fractionné (ou « split-brain »). Dans ce cas, les espaces de nommage DNS internes et externes portent le même nom, mais sont distincts.

Problème 1 : Un site Web d’entreprise hébergé en externe est inaccessible depuis le bureau.
Il s’agit du problème le plus courant dans un environnement DNS fractionné. Le site Web de l’entreprise ou toute autre ressource connectée à Internet appartenant à l’entreprise n’est pas accessible depuis le bureau aux clients joints à un domaine. Les machines situées en dehors du bureau n’ont aucun problème d’accès au site Web.

Problème 2 : Un site Web public hébergé en interne est inaccessible depuis le bureau.
Il s’agit d’une variante du problème 1 décrit ci-dessus. La différence est que le site Web est hébergé en interne, soit derrière un pare-feu sur le réseau interne de l’entreprise, soit dans une DMZ. Il est censé être accessible aux utilisateurs internes et externes, mais les utilisateurs internes ne peuvent pas y accéder. Les utilisateurs externes ne signalent aucun problème.

Problème 3 : Le site Web se charge de manière incomplète ou ne se charge pas une fois le problème 1 ou 2 résolu.
Le site peut ne pas se charger du tout ou se charger de manière incomplète pour les utilisateurs internes. Certaines parties du site peuvent ne pas s’afficher et les liens vers le site peuvent ne pas fonctionner. Les utilisateurs externes peuvent accéder au site Web sans problème.

Problème 1 : Un site Web d’entreprise hébergé en externe est inaccessible depuis le bureau.

L’examen de ce qui se passe lorsqu’un utilisateur interne tente de naviguer sur le site Web de l’entreprise peut indiquer l’origine du problème :

1. L’ordinateur de l’utilisateur interroge le serveur DNS du domaine, généralement un contrôleur de domaine (DC), pour obtenir l’adresse IP de www.domain.com.
2. Comme le contrôleur de domaine héberge une zone de recherche directe nommée domain.com, il recherche dans cette zone un enregistrement d’hôte nommé www.
3. Le contrôleur de domaine ne trouve aucun enregistrement d’hôte nommé www, et comme il fait autorité pour la zone domain.com , il ne transmet pas la requête.
4. Le contrôleur de domaine répond à l’ordinateur de l’utilisateur qu’il n’a pas trouvé d’adresse pour www.domain.com.
5. Le navigateur de l’ordinateur de l’utilisateur affiche « Impossible d’afficher la page » ou une erreur similaire.

Le problème survient, car un serveur DNS faisant autorité n’envoie pas de requêtes pour les noms figurant dans ses zones à d’autres serveurs DNS. Il renvoie une réponse « introuvable » si aucun enregistrement ne correspond à une requête donnée. Dans cet exemple, il existe d’autres serveurs DNS avec l’enregistrement correct : les serveurs DNS qui hébergent la zone domain.com publique. En effet, les machines situées en dehors du bureau peuvent accéder au site Web. Cependant, les requêtes des machines internes ne sont pas envoyées à ce serveur.

Problème 2 : Un site Web public hébergé en interne est inaccessible depuis le bureau.
La raison du problème est similaire à celle du problème 1. Dans ce cas, les utilisateurs internes peuvent correctement résoudre le nom du site Web en adresse IP publique. Toutefois, ils ne peuvent toujours pas accéder au site Web en raison de la configuration du pare-feu. Celui-ci attend des utilisateurs du réseau interne qu’ils accèdent au site Web en utilisant son adresse privée plutôt que son adresse publique.

Problème 3 : Le site Web se charge de manière incomplète ou ne se charge pas une fois le problème 1 ou 2 résolu.
Cela peut se produire si le code du site Web redirige les navigateurs depuis www.domain.com to domain.com. Les liens internes peuvent également renvoyer au site sous la forme domain.com plutôt que www.domain.com. Les mêmes symptômes sont observés sur les machines internes, que le site soit hébergé en interne ou en externe.

Dans ce cas, le problème est un peu plus complexe. Pour que les machines puissent résoudre domain.com en adresse IP, il doit y avoir un enregistrement d’hôte vide dans la zone domain.com dans DNS. Le nom de cet enregistrement s’affiche comme (identique au dossier parent) dans la console DNS Windows. Cependant, Active Directory utilise des enregistrements d’hôte vides dans la zone domain.com pour représenter les contrôleurs de domaine du domaine domain.com . S’il y a des enregistrements d’hôte vides supplémentaires dans la zone domain.com , des retards ou des problèmes d’authentification peuvent en résulter.

Pour les raisons susmentionnées, ce problème ne peut pas être résolu en utilisant uniquement DNS. La création d’un enregistrement d’hôte vide avec l’adresse IP du site Web résout uniquement par intermittence le problème d’accès au site Web pour les utilisateurs internes. Les enregistrements d’hôte vides existants se référant aux contrôleurs de domaine interfèrent avec cette solution, en raison de la fonctionnalité DNS de permutation circulaire. Comme ces enregistrements sont automatiquement enregistrés par les contrôleurs de domaine, s’ils sont supprimés de la zone DNS, ils réapparaissent régulièrement.
 

Problème 1 : Un site Web d’entreprise hébergé en externe est inaccessible depuis le bureau.
La solution à ce problème est simple. Créez un enregistrement d’hôte (A) nommé www dans la zone domain.com du contrôleur de domaine et attribuez-lui l’adresse IP du site Web. Les machines qui interrogent ce serveur DNS reçoivent la réponse correcte et peuvent naviguer sur le site Web.

Problème 2 : Un site Web public hébergé en interne est inaccessible depuis le bureau.
Il existe également une solution simple à ce problème. Créez un enregistrement d’hôte nommé www dans la zone domain.com du contrôleur de domaine, mais attribuez-lui l’adresse IP privée du site Web. Les machines internes résolvent le nom du site Web en cette adresse privée, tandis que les machines externes continuent de résoudre le nom en adresse publique du site Web.

Problème 3 : Le site Web se charge de manière incomplète ou ne se charge pas une fois le problème 1 ou 2 résolu.
La façon la plus simple de résoudre ce problème consiste à modifier le code du site Web pour supprimer la redirection. Les liens internes doivent également pointer vers le site en tant que www.domain.com plutôt que domain.com. S’il n’est pas possible de modifier le code, la seule autre possibilité de résoudre le problème consiste à renommer le domaine Active Directory. Cette tâche peut s’avérer complexe, en fonction de la taille et de la complexité de l’environnement.

Remarque : Vous devez accéder au site Web en utilisant le nom www.domain.com dans tous ces exemples. L’accès au site à l’aide du nom domain.com ne fonctionne pas ou fonctionne uniquement par intermittence.

Les pratiques d’excellence pour la conception d’un domaine Active Directory (AD) recommandent de ne pas utiliser un nom de domaine enregistré comme nom de domaine AD. Il existe deux alternatives possibles :

• Utiliser un suffixe DNS non public (.local ou .lan, par exemple) dans le nom de domaine AD.
• Faire du domaine AD un sous-domaine du domaine enregistré (corp.domain.com, par exemple).

Ceci n’est possible que si le domaine AD n’a pas déjà été créé ou si une opération de changement de nom est en cours.