<p>Bonjour,</p>
<p>Cette question est fondamentale dans la conception d’une infrastructure Active Directory, et la réponse courte est : <strong>non, il n’est plus recommandé d’utiliser <code>.local</code> pour un domaine Active Directory</strong>. Voici une analyse complète et approfondie pour comprendre pourquoi, avec les alternatives recommandées par Microsoft.</p>
<h2><a name="p-34546-le-problme-historique-avec-local-1" class="anchor" href="#p-34546-le-problme-historique-avec-local-1" aria-label="Heading link"></a>Le problème historique avec <code>.local</code></h2>
<h3><a name="p-34546-origine-du-problme-2" class="anchor" href="#p-34546-origine-du-problme-2" aria-label="Heading link"></a>Origine du problème</h3>
<p>La pratique d’utiliser <code>.local</code> comme suffixe de domaine AD était très courante dans les années 2000 (exemples : <code>entreprise.local</code>, <code>mondomaine.local</code>). À l’époque, cette convention semblait logique car elle indiquait clairement qu’il s’agissait d’un domaine interne, non accessible depuis Internet.</p>
<p>Cependant, <strong>deux conflits majeurs ont rendu cette pratique problématique</strong> :</p>
<h3><a name="p-34546-conflit-n1-mdns-et-bonjourzeroconf-3" class="anchor" href="#p-34546-conflit-n1-mdns-et-bonjourzeroconf-3" aria-label="Heading link"></a>Conflit n°1 : mDNS et Bonjour/Zeroconf</h3>
<p>Le protocole <strong>mDNS (Multicast DNS)</strong>, standardisé dans la <strong>RFC 6762</strong>, réserve officiellement le domaine de premier niveau <code>.local</code> pour la <strong>résolution de noms locaux sans serveur DNS</strong> (zero-configuration networking). Ce protocole est utilisé par :</p>
<ul>
<li><strong>Apple Bonjour</strong> (macOS, iOS, Apple TV, imprimantes réseau Apple)</li>
<li><strong>Avahi</strong> (implémentation Linux de mDNS)</li>
<li><strong>Chromecast</strong> et autres appareils Google Cast</li>
<li>De nombreuses <strong>imprimantes réseau</strong> et <strong>NAS modernes</strong></li>
</ul>
<p>Lorsque vous avez un domaine AD en <code>.local</code> et des appareils Apple ou des imprimantes réseau sur le même réseau, des <strong>conflits de résolution DNS</strong> se produisent systématiquement. Les appareils Apple tentent de résoudre <code>serveur.mondomaine.local</code> via mDNS au lieu du DNS Active Directory, causant des échecs d’authentification et de résolution de noms.</p>
<h3><a name="p-34546-conflit-n2-rfc-2826-et-rsolution-dns-4" class="anchor" href="#p-34546-conflit-n2-rfc-2826-et-rsolution-dns-4" aria-label="Heading link"></a>Conflit n°2 : RFC 2826 et résolution DNS</h3>
<p>La <strong>RFC 2826</strong> stipule que les noms de domaines <code>.local</code> ne doivent pas être délégués dans le DNS global. Bien que <code>.local</code> ne soit pas un TLD enregistré dans la racine DNS d’IANA, son utilisation dans mDNS crée une ambiguïté architecturale qui perturbe les résolveurs DNS modernes.</p>
<h2><a name="p-34546-les-recommandations-officielles-de-microsoft-5" class="anchor" href="#p-34546-les-recommandations-officielles-de-microsoft-5" aria-label="Heading link"></a>Les recommandations officielles de Microsoft</h2>
<p>Microsoft a publié des recommandations claires dans sa documentation sur la conception d’Active Directory :</p>
<blockquote>
<p><strong>Microsoft recommande explicitement de ne PAS utiliser <code>.local</code></strong> pour les nouveaux déploiements AD DS (Active Directory Domain Services).</p>
</blockquote>
<p>Les recommandations officielles préconisent les approches suivantes :</p>
<h3><a name="p-34546-option-1-sous-domaine-dun-nom-de-domaine-enregistr-recommand-6" class="anchor" href="#p-34546-option-1-sous-domaine-dun-nom-de-domaine-enregistr-recommand-6" aria-label="Heading link"></a>Option 1 : Sous-domaine d’un nom de domaine enregistré (recommandé)</h3>
<p><strong>Exemple</strong> : Si votre domaine public est <code>entreprise.fr</code>, utilisez <code>corp.entreprise.fr</code> ou <code>ad.entreprise.fr</code> pour votre AD interne.</p>
<p><strong>Avantages</strong> :</p>
<ul>
<li>Cohérence totale avec les standards DNS</li>
<li>Pas de conflits avec mDNS</li>
<li>Facilite la mise en place de <strong>Split-DNS</strong> (résolution différente en interne et en externe)</li>
<li>Compatible avec les certificats SSL/TLS (y compris les certificats wildcard)</li>
<li>Préparation facilitée pour les <strong>scénarios hybrides Azure AD</strong></li>
</ul>
<h3><a name="p-34546-option-2-domaine-interne-distinct-mais-non-enregistr-7" class="anchor" href="#p-34546-option-2-domaine-interne-distinct-mais-non-enregistr-7" aria-label="Heading link"></a>Option 2 : Domaine interne distinct mais non enregistré</h3>
<p><strong>Exemple</strong> : <code>entreprise.internal</code>, <code>corp.lan</code></p>
<p>Bien que meilleure que <code>.local</code>, cette approche a ses propres limitations liées aux <strong>certificats SSL/TLS</strong> (les autorités de certification publiques refusent d’émettre des certificats pour des TLD non enregistrés depuis 2015).</p>
<h3><a name="p-34546-option-3-mme-nom-que-le-domaine-public-dconseill-sauf-cas-spcifiques-8" class="anchor" href="#p-34546-option-3-mme-nom-que-le-domaine-public-dconseill-sauf-cas-spcifiques-8" aria-label="Heading link"></a>Option 3 : Même nom que le domaine public (déconseillé sauf cas spécifiques)</h3>
<p><strong>Exemple</strong> : Le domaine AD est <code>entreprise.fr</code> (même que le domaine public)</p>
<p>Nécessite une configuration <strong>Split-DNS</strong> rigoureuse et peut créer des confusions, mais est techniquement viable.</p>
<h2><a name="p-34546-tableau-comparatif-des-options-de-nommage-ad-9" class="anchor" href="#p-34546-tableau-comparatif-des-options-de-nommage-ad-9" aria-label="Heading link"></a>Tableau comparatif des options de nommage AD</h2>
<div class="md-table">
<table>
<thead>
<tr>
<th>Convention</th>
<th>Exemple</th>
<th>Compatibilité mDNS</th>
<th>Certificats SSL</th>
<th>Recommandé Microsoft</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>.local</code></td>
<td><code>corp.local</code></td>
<td>Conflits</td>
<td>Non (depuis 2015)</td>
<td>Non</td>
</tr>
<tr>
<td>Sous-domaine enregistré</td>
<td><code>ad.entreprise.fr</code></td>
<td>Aucun conflit</td>
<td>Oui</td>
<td>Oui (option 1)</td>
</tr>
<tr>
<td>TLD interne personnalisé</td>
<td><code>corp.internal</code></td>
<td>Aucun conflit</td>
<td>Non (depuis 2015)</td>
<td>Acceptable</td>
</tr>
<tr>
<td>Même domaine que public</td>
<td><code>entreprise.fr</code></td>
<td>Aucun conflit</td>
<td>Oui</td>
<td>Conditionnel</td>
</tr>
</tbody>
</table>
</div><h2><a name="p-34546-impact-sur-les-certificats-ssltls-10" class="anchor" href="#p-34546-impact-sur-les-certificats-ssltls-10" aria-label="Heading link"></a>Impact sur les certificats SSL/TLS</h2>
<p>Depuis <strong>novembre 2015</strong>, les autorités de certification publiques (DigiCert, Let’s Encrypt, Sectigo, etc.) <strong>refusent d’émettre des certificats pour des noms internes non qualifiés</strong> et des TLD non enregistrés, conformément aux <strong>Baseline Requirements du CA/Browser Forum</strong>.</p>
<p>Cela signifie que si vous avez un domaine AD en <code>.local</code>, vous ne pouvez pas obtenir de certificats SSL publics valides pour vos services internes (Exchange, SharePoint, RDS, etc.). Vous devez soit :</p>
<ul>
<li>Utiliser une <strong>PKI interne</strong> (Microsoft ADCS) avec vos propres certificats</li>
<li>Accepter les <strong>avertissements de sécurité</strong> sur les certificats non approuvés</li>
<li>Migrer vers un nommage de domaine conforme</li>
</ul>
<h2><a name="p-34546-problmes-pratiques-observs-avec-local-11" class="anchor" href="#p-34546-problmes-pratiques-observs-avec-local-11" aria-label="Heading link"></a>Problèmes pratiques observés avec <code>.local</code></h2>
<h3><a name="p-34546-symptmes-courants-en-environnement-mixte-windowsapple-12" class="anchor" href="#p-34546-symptmes-courants-en-environnement-mixte-windowsapple-12" aria-label="Heading link"></a>Symptômes courants en environnement mixte Windows/Apple</h3>
<pre><code class="lang-auto">Erreur : Impossible de joindre le domaine corp.local
DNS lookup failed for corp.local
Kerberos authentication error: Cannot find KDC for realm CORP.LOCAL
</code></pre>
<h3><a name="p-34546-configuration-dns-problmatique-sur-macos-13" class="anchor" href="#p-34546-configuration-dns-problmatique-sur-macos-13" aria-label="Heading link"></a>Configuration DNS problématique sur macOS</h3>
<p>Sur macOS, pour contourner le problème avec un domaine <code>.local</code> existant, il faut modifier <code>/etc/resolver/</code> :</p>
<pre data-code-wrap="bash"><code class="lang-bash"># Sur chaque Mac, créer un fichier de résolveur pour bypasser mDNS
sudo mkdir -p /etc/resolver
sudo tee /etc/resolver/corp.local << EOF
domain corp.local
search corp.local
nameserver 192.168.1.10
nameserver 192.168.1.11
EOF
</code></pre>
<p>Cette solution de contournement est fragile et doit être appliquée sur chaque appareil Apple individuellement.</p>
<h2><a name="p-34546-migration-dun-domaine-local-existant-14" class="anchor" href="#p-34546-migration-dun-domaine-local-existant-14" aria-label="Heading link"></a>Migration d’un domaine <code>.local</code> existant</h2>
<p>Si vous avez déjà un domaine AD en <code>.local</code> et souhaitez migrer, voici les étapes de haut niveau :</p>
<h3><a name="p-34546-tape-1-inventaire-et-planification-15" class="anchor" href="#p-34546-tape-1-inventaire-et-planification-15" aria-label="Heading link"></a>Étape 1 : Inventaire et planification</h3>
<pre data-code-wrap="powershell"><code class="lang-powershell"># Lister tous les contrôleurs de domaine
Get-ADDomainController -Filter * | Select-Object Name, IPv4Address, Site
Vérifier le niveau fonctionnel actuel
Get-ADDomain | Select-Object Name, DomainMode
Get-ADForest | Select-Object Name, ForestMode
Lister les approbations de forêt existantes
Get-ADTrust -Filter * | Select-Object Name, TrustType, TrustDirection
</code></pre>
<h3><a name="p-34546-tape-2-renommage-du-domaine-option-risque-16" class="anchor" href="#p-34546-tape-2-renommage-du-domaine-option-risque-16" aria-label="Heading link"></a>Étape 2 : Renommage du domaine (option risquée)</h3>
<p>Microsoft fournit l’outil <code>rendom.exe</code> pour renommer un domaine AD, mais cette opération est <strong>extrêmement risquée</strong> et nécessite :</p>
<ul>
<li>Un plan de rollback détaillé</li>
<li>Une fenêtre de maintenance étendue</li>
<li>Des tests approfondis en environnement de laboratoire</li>
<li>La recréation de toutes les approbations de forêt</li>
</ul>
<h3><a name="p-34546-tape-3-migration-vers-une-nouvelle-fort-option-recommande-17" class="anchor" href="#p-34546-tape-3-migration-vers-une-nouvelle-fort-option-recommande-17" aria-label="Heading link"></a>Étape 3 : Migration vers une nouvelle forêt (option recommandée)</h3>
<p>Dans la plupart des cas professionnels, il est préférable de <strong>créer une nouvelle forêt AD</strong> avec le nommage correct et de migrer les objets progressivement avec des outils comme <strong>ADMT (Active Directory Migration Tool)</strong>.</p>
<h2><a name="p-34546-recommandations-pour-les-nouveaux-dploiements-18" class="anchor" href="#p-34546-recommandations-pour-les-nouveaux-dploiements-18" aria-label="Heading link"></a>Recommandations pour les nouveaux déploiements</h2>
<p>Si vous démarrez un <strong>nouveau déploiement AD</strong>, voici les bonnes pratiques :</p>
<ol>
<li><strong>Enregistrez un nom de domaine</strong> si ce n’est pas encore fait</li>
<li><strong>Choisissez un sous-domaine</strong> : <code>corp.votre-entreprise.fr</code> ou <code>ad.votre-entreprise.fr</code></li>
<li><strong>Configurez le Split-DNS</strong> pour que le sous-domaine interne soit résolu différemment en interne et en externe</li>
<li><strong>Planifiez la PKI</strong> en conséquence pour les certificats SSL</li>
</ol>
<pre data-code-wrap="powershell"><code class="lang-powershell"># Exemple : installer le rôle AD DS avec le bon nom de domaine
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Promouvoir en tant que premier DC avec un nom conforme
Install-ADDSForest -DomainName "corp.entreprise.fr"
-DomainNetbiosName "CORP" -ForestMode "WinThreshold"
-DomainMode "WinThreshold" -InstallDns:$true
-SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd!" -AsPlainText -Force) `
-Force:$true
</code></pre>
<h2><a name="p-34546-conclusion-19" class="anchor" href="#p-34546-conclusion-19" aria-label="Heading link"></a>Conclusion</h2>
<p><strong>L’utilisation de <code>.local</code> pour un domaine Active Directory est une pratique déconseillée</strong> depuis la standardisation de mDNS/RFC 6762 et les exigences des CA publiques en matière de certificats. Pour un nouveau déploiement, optez systématiquement pour un <strong>sous-domaine d’un nom de domaine enregistré</strong> (ex : <code>corp.entreprise.fr</code>).</p>
<p>Si vous disposez déjà d’un domaine <code>.local</code> en production, une évaluation soigneuse s’impose avant toute migration — les risques sont réels et la planification doit être rigoureuse. N’hésitez pas à me préciser votre situation actuelle (nouveau déploiement ou migration d’existant, version de Windows Server, présence d’appareils non-Windows) afin que je puisse vous fournir des recommandations plus ciblées.</p>
