Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

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

ayi

<a href="https://serverfault.com/q/473529/118258" rel="noopener nofollow ugc">Espérons-le</a>, nous <a href="https://serverfault.com/q/38208/118258" rel="noopener nofollow ugc">savons tous</a> quelles sont les <a href="http://www.mdmarra.com/2013/07/more-documentation-from-microsoft-about.html" rel="noopener nofollow ugc">recommandations pour nommer une forêt Active Directory</a>, et elles sont assez simples. En résumé, cela peut se résumer en une seule phrase.
<a href="http://technet.microsoft.com/en-us/library/cc738121%28WS.10%29.aspx" rel="noopener nofollow ugc">Utilisez un sous-domaine d’un nom de domaine existant enregistré, et choisissez-en un qui ne sera pas utilisé en externe.</a> Par exemple, si je devais constituer une société et enregistrer le domaine <code>hopelessn00b.com</code>, ma forêt AD interne devrait être nommée <code>internal.hopelessn00b.com</code> ou <code>ad.hopelessn00b.com</code> ou <code>corp.hopelessn00b.com</code>.
Il y a des raisons extrêmement convaincantes d’éviter d’utiliser des <a href="http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html" rel="noopener nofollow ugc">TLD « fictifs »</a> ou des <a href="http://support.microsoft.com/kb/300684/en-us" rel="noopener nofollow ugc">noms de domaine à étiquette unique</a>, mais j’ai du mal à trouver des raisons aussi convaincantes d’éviter d’utiliser le domaine racine (<code>hopelessn00b.com</code>) comme nom de domaine et d’utiliser un sous-domaine comme <code>corp.hopelessn00b.com</code> à 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 <code>A</code> et de taper <code>www.</code> 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 <code>ad.hopelessn00b.com</code> comme nom de forêt Active Directory plutôt que <code>hopelessn00b.com</code> ?
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 <code>corp.employeur.com</code> pour notre réseau interne, il veut maintenant garder une forêt AD nommée <code>employeur.com</code> (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.

ayi_2

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.
<ul>
<li></li>
</ul>
Le problème du <code>www</code> que vous avez souligné ci-dessus. Ennuyeux, mais pas rédhibitoire.
<ul>
<li></li>
</ul>
Cela vous oblige à maintenir des enregistrements en double pour tous les serveurs publics qui sont également accessibles en interne, pas seulement <code>www</code>. <code>mail.hopelessnoob.com</code> 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 <code>mail.hopelessnoob.com</code> ou <code>publicwebservice.hopelessnoob.com</code>. Avec certaines configurations, <a href="https://serverfault.com/questions/508605/why-dont-more-organizations-use-inside-to-inside-nat-or-similar-solutions-to-al">comme un ASA avec des interfaces internes et externes</a>, 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.
<ul>
<li></li>
</ul>
Imaginez ce scénario — Vous êtes <code>hopelessnoob.com</code> en interne et en externe. Vous avez une société partenaire appelée <code>example.com</code> 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.
<ul>
<li></li>
</ul>
Si vous déployez un jour <a href="http://en.wikipedia.org/wiki/DirectAccess">DirectAccess</a>, 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.