Nommer une nouvelle forêt Active Directory — pourquoi le DNS split-horizon n'est-il pas recommandé ?

[ForumBot]

Espérons-le, nous savons tous quelles sont les recommandations pour nommer une forêt Active Directory, et elles sont assez simples. En résumé, cela peut se résumer en une seule phrase.

Utilisez un sous-domaine d’un nom de domaine existant enregistré, et choisissez-en un qui ne sera pas utilisé en externe. Par exemple, si je devais constituer une société et enregistrer le domaine hopelessn00b.com, ma forêt AD interne devrait être nommée internal.hopelessn00b.com ou ad.hopelessn00b.com ou corp.hopelessn00b.com.

Il y a des raisons extrêmement convaincantes d’éviter d’utiliser des TLD « fictifs » ou des noms de domaine à étiquette unique, mais j’ai du mal à trouver des raisons aussi convaincantes d’éviter d’utiliser le domaine racine (hopelessn00b.com) comme nom de domaine et d’utiliser un sous-domaine comme corp.hopelessn00b.com à la place. En fait, la seule justification que je semble trouver est que l’accès au site web externe depuis l’interne nécessite un enregistrement DNS A et de taper www. devant le nom du site web dans un navigateur, ce qui est assez « bof » comme problème.

Alors, qu’est-ce que je rate ? Pourquoi est-il tellement mieux d’utiliser ad.hopelessn00b.com comme nom de forêt Active Directory plutôt que hopelessn00b.com ?

Pour mémoire, c’est vraiment mon employeur qu’il faut convaincre — le patron fait marche arrière, et après m’avoir donné le feu vert pour créer une nouvelle forêt AD nommée corp.employeur.com pour notre réseau interne, il veut maintenant garder une forêt AD nommée employeur.com (identique à notre domaine enregistré en externe). J’espère trouver une ou plusieurs raisons convaincantes pour lesquelles la bonne pratique est la meilleure option, afin de le convaincre… car cela semble plus facile que de démissionner de rage et/ou de trouver un nouvel emploi, du moins pour le moment.

---

Source : Server Fault,)

[ayi]

D’accord, il est assez bien documenté par Microsoft que vous ne devriez pas utiliser le split-horizon ni un TLD inventé, comme vous l’avez mentionné à plusieurs reprises. Il y a quelques raisons à cela.

Le problème du www que vous avez souligné ci-dessus. Ennuyeux, mais pas rédhibitoire.

Cela vous oblige à maintenir des enregistrements en double pour tous les serveurs publics qui sont également accessibles en interne, pas seulement www. mail.hopelessnoob.com est un exemple courant. Dans un scénario idéal, vous auriez un réseau de périmètre séparé pour des choses comme mail.hopelessnoob.com ou publicwebservice.hopelessnoob.com. Avec certaines configurations, comme un ASA avec des interfaces internes et externes, vous avez besoin soit du NAT interne-interne, soit du DNS split-horizon de toute façon, mais pour les grandes organisations avec un véritable réseau de périmètre où vos ressources web ne sont pas derrière une limite NAT en épingle à cheveux — cela cause un travail inutile.

Imaginez ce scénario — Vous êtes hopelessnoob.com en interne et en externe. Vous avez une société partenaire appelée example.com et elle fait la même chose — split-horizon en interne avec son AD et avec son espace de noms DNS accessible publiquement. Maintenant, vous configurez un VPN site-à-site et voulez que l’authentification interne pour la relation de confiance traverse le tunnel tout en ayant accès à leurs ressources publiques externes via Internet. C’est quasiment impossible sans un routage de stratégie incroyablement compliqué ou la conservation de votre propre copie de leur zone DNS interne — vous venez de créer un ensemble supplémentaire d’enregistrements DNS à maintenir.

Si vous déployez un jour DirectAccess, cela simplifie considérablement vos stratégies de résolution de noms — c’est probablement aussi vrai pour d’autres technologies VPN en tunnel partagé.

Certains de ces cas sont marginaux, d’autres non, mais ils sont tous facilement évitables. Si vous avez la possibilité de le faire dès le départ, autant le faire correctement pour ne pas rencontrer l’un de ces problèmes dans dix ans.