Bonjour,
Cette question est fondamentale dans la conception d’une infrastructure Active Directory, et la réponse courte est : non, il n’est plus recommandé d’utiliser .local pour un domaine Active Directory. Voici une analyse complète et approfondie pour comprendre pourquoi, avec les alternatives recommandées par Microsoft.
Le problème historique avec .local
Origine du problème
La pratique d’utiliser .local comme suffixe de domaine AD était très courante dans les années 2000 (exemples : entreprise.local, mondomaine.local). À l’époque, cette convention semblait logique car elle indiquait clairement qu’il s’agissait d’un domaine interne, non accessible depuis Internet.
Cependant, deux conflits majeurs ont rendu cette pratique problématique :
Conflit n°1 : mDNS et Bonjour/Zeroconf
Le protocole mDNS (Multicast DNS), standardisé dans la RFC 6762, réserve officiellement le domaine de premier niveau .local pour la résolution de noms locaux sans serveur DNS (zero-configuration networking). Ce protocole est utilisé par :
- Apple Bonjour (macOS, iOS, Apple TV, imprimantes réseau Apple)
- Avahi (implémentation Linux de mDNS)
- Chromecast et autres appareils Google Cast
- De nombreuses imprimantes réseau et NAS modernes
Lorsque vous avez un domaine AD en .local et des appareils Apple ou des imprimantes réseau sur le même réseau, des conflits de résolution DNS se produisent systématiquement. Les appareils Apple tentent de résoudre serveur.mondomaine.local via mDNS au lieu du DNS Active Directory, causant des échecs d’authentification et de résolution de noms.
Conflit n°2 : RFC 2826 et résolution DNS
La RFC 2826 stipule que les noms de domaines .local ne doivent pas être délégués dans le DNS global. Bien que .local 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.
Les recommandations officielles de Microsoft
Microsoft a publié des recommandations claires dans sa documentation sur la conception d’Active Directory :
Microsoft recommande explicitement de ne PAS utiliser .local pour les nouveaux déploiements AD DS (Active Directory Domain Services).
Les recommandations officielles préconisent les approches suivantes :
Option 1 : Sous-domaine d’un nom de domaine enregistré (recommandé)
Exemple : Si votre domaine public est entreprise.fr, utilisez corp.entreprise.fr ou ad.entreprise.fr pour votre AD interne.
Avantages :
- Cohérence totale avec les standards DNS
- Pas de conflits avec mDNS
- Facilite la mise en place de Split-DNS (résolution différente en interne et en externe)
- Compatible avec les certificats SSL/TLS (y compris les certificats wildcard)
- Préparation facilitée pour les scénarios hybrides Azure AD
Option 2 : Domaine interne distinct mais non enregistré
Exemple : entreprise.internal, corp.lan
Bien que meilleure que .local, cette approche a ses propres limitations liées aux certificats SSL/TLS (les autorités de certification publiques refusent d’émettre des certificats pour des TLD non enregistrés depuis 2015).
Option 3 : Même nom que le domaine public (déconseillé sauf cas spécifiques)
Exemple : Le domaine AD est entreprise.fr (même que le domaine public)
Nécessite une configuration Split-DNS rigoureuse et peut créer des confusions, mais est techniquement viable.
Tableau comparatif des options de nommage AD
| Convention |
Exemple |
Compatibilité mDNS |
Certificats SSL |
Recommandé Microsoft |
.local |
corp.local |
Conflits |
Non (depuis 2015) |
Non |
| Sous-domaine enregistré |
ad.entreprise.fr |
Aucun conflit |
Oui |
Oui (option 1) |
| TLD interne personnalisé |
corp.internal |
Aucun conflit |
Non (depuis 2015) |
Acceptable |
| Même domaine que public |
entreprise.fr |
Aucun conflit |
Oui |
Conditionnel |
Impact sur les certificats SSL/TLS
Depuis novembre 2015, les autorités de certification publiques (DigiCert, Let’s Encrypt, Sectigo, etc.) refusent d’émettre des certificats pour des noms internes non qualifiés et des TLD non enregistrés, conformément aux Baseline Requirements du CA/Browser Forum.
Cela signifie que si vous avez un domaine AD en .local, vous ne pouvez pas obtenir de certificats SSL publics valides pour vos services internes (Exchange, SharePoint, RDS, etc.). Vous devez soit :
- Utiliser une PKI interne (Microsoft ADCS) avec vos propres certificats
- Accepter les avertissements de sécurité sur les certificats non approuvés
- Migrer vers un nommage de domaine conforme
Problèmes pratiques observés avec .local
Symptômes courants en environnement mixte Windows/Apple
Erreur : Impossible de joindre le domaine corp.local
DNS lookup failed for corp.local
Kerberos authentication error: Cannot find KDC for realm CORP.LOCAL
Configuration DNS problématique sur macOS
Sur macOS, pour contourner le problème avec un domaine .local existant, il faut modifier /etc/resolver/ :
# 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
Cette solution de contournement est fragile et doit être appliquée sur chaque appareil Apple individuellement.
Migration d’un domaine .local existant
Si vous avez déjà un domaine AD en .local et souhaitez migrer, voici les étapes de haut niveau :
Étape 1 : Inventaire et planification
# 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
Étape 2 : Renommage du domaine (option risquée)
Microsoft fournit l’outil rendom.exe pour renommer un domaine AD, mais cette opération est extrêmement risquée et nécessite :
- Un plan de rollback détaillé
- Une fenêtre de maintenance étendue
- Des tests approfondis en environnement de laboratoire
- La recréation de toutes les approbations de forêt
Étape 3 : Migration vers une nouvelle forêt (option recommandée)
Dans la plupart des cas professionnels, il est préférable de créer une nouvelle forêt AD avec le nommage correct et de migrer les objets progressivement avec des outils comme ADMT (Active Directory Migration Tool).
Recommandations pour les nouveaux déploiements
Si vous démarrez un nouveau déploiement AD, voici les bonnes pratiques :
- Enregistrez un nom de domaine si ce n’est pas encore fait
- Choisissez un sous-domaine :
corp.votre-entreprise.fr ou ad.votre-entreprise.fr
- Configurez le Split-DNS pour que le sous-domaine interne soit résolu différemment en interne et en externe
- Planifiez la PKI en conséquence pour les certificats SSL
# 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
Conclusion
L’utilisation de .local pour un domaine Active Directory est une pratique déconseillée 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 sous-domaine d’un nom de domaine enregistré (ex : corp.entreprise.fr).
Si vous disposez déjà d’un domaine .local 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.