Comment relier proprement deux forêts Active Directory (AWS et on‑premises) pour une résolution DNS fiable ? Ce guide pas‑à‑pas explique les méthodes éprouvées, leurs avantages, et propose des checklists de déploiement, de test et de dépannage.
Contexte et architecture cible
Vous disposez de deux forêts indépendantes : une forêt hébergée dans AWS (contrôleurs de domaine et service DNS Windows Server ou AWS Managed Microsoft AD), et une forêt on‑premises. Les utilisateurs on‑premises doivent atteindre des applications dont les enregistrements sont publiés dans la zone DNS de la forêt AWS, et parfois l’inverse. Sans configuration spécifique, la résolution croisée échoue, car chaque forêt n’a autorité que sur ses zones locales.
L’architecture cible consiste à rout(er) les requêtes DNS portant sur le suffixe de la forêt distante vers un résolveur capable de répondre autoritativement. Trois approches dominent : redirecteurs conditionnels, zones secondaires et zones stub. Le choix dépend du niveau d’isolation souhaité, du volume de trafic, des contraintes de sécurité et de la présence (ou non) d’une relation d’approbation entre forêts.
Problématique
- Les postes on‑premises ne parviennent pas à résoudre les FQDN
.aws.corp(ou tout autre suffixe utilisé par la forêt AWS). - Éventuellement, les serveurs en AWS doivent aussi résoudre les FQDN
.onprem.corp. - Aucune confiance inter‑forêts n’est en place au départ et l’on souhaite éviter la co‑administration ou la modification des zones existantes.
Approche recommandée
Dans la plupart des cas, commencez par les redirecteurs conditionnels pour leur simplicité et leur réversibilité. En cas de besoins spécifiques (cache local, réduction du trafic, autonomie en cas de rupture de lien), évaluez les zones secondaires ou les zones stub.
| Méthode | Principe | Quand l’utiliser | Étapes clefs |
|---|---|---|---|
| Redirecteur conditionnel (Conditional Forwarder) | Le DNS A relaie toute requête visant le suffixe DNS de la forêt B directement vers les IP des DC/DNS de B. | Solution la plus simple en l’absence de trust entre forêts. | 1) Ouvrir DNS Manager sur chaque serveur DNS. 2) Clic droit → Propriétés → onglet Redirecteurs conditionnels (ou Forwarders). 3) Ajouter le suffixe DNS de la forêt distante (ex. : ad.aws.corp).4) Renseigner les IP des serveurs DNS distants. 5) Répéter côté inverse si une résolution bidirectionnelle est requise. |
| Zone secondaire | Copie en lecture seule de la zone distante via transfert de zone. | Besoin d’une copie locale à jour pour limiter la latence/le trafic, ou fonctionner lors d’une coupure temporaire. | – Autoriser le transfert de zone dans la forêt source (liste d’IP autorisées). – Créer une zone secondaire dans la forêt cible en indiquant les maîtres de zone. – Vérifier la réplication et l’actualisation régulière des enregistrements. |
| Zone stub | Ne conserve que les enregistrements NS et A de la zone parente ; plus léger qu’une zone secondaire. | Quand on veut l’auto‑mise à jour des serveurs faisant autorité en limitant le volume recopié. | – Activer le transfert des enregistrements NS/A coté source si nécessaire.– Créer une zone stub dans la forêt cible et valider la résolution récursive. |
Bonne pratique : dans Active Directory 2008 R2 et versions ultérieures, les redirecteurs conditionnels peuvent être intégrés AD pour être répliqués automatiquement entre contrôleurs de domaine d’un même domaine/site/forêt.
Port et pare‑feu : ouvrir
TCP/UDP 53entre les deux réseaux (généralement via VPN ou AWS Direct Connect). Pour les transferts de zone,TCP 53est requis.Test rapide :
nslookup nomduserveur.aws.corp IP_DNS_onprem nslookup nomduserveur.onprem.corp IP_DNS_AWS
Procédures détaillées
Configuration des redirecteurs conditionnels
Depuis la console graphique (Windows Server DNS) :
- Ouvrir DNS Manager sur un DC/DNS on‑premises.
- Cliquer droit sur le nom du serveur → Propriétés → Redirecteurs conditionnels → Nouveau.
- Saisir le nom de domaine de la zone distante (ex.
ad.aws.corp). - Ajouter les adresses IP des DC/DNS hébergeant la zone (ou l’endpoint Route 53 Resolver, voir plus bas).
- Activer Stocker ce redirecteur dans Active Directory et choisir le Scope de réplication (site/domaine/forêt) si vous souhaitez une réplication automatique.
- Valider et répéter l’opération côté AWS si nécessaire.
Depuis PowerShell (plus rapide et industrialisable) :
# On-premises vers AWS
Add-DnsServerConditionalForwarderZone `
-Name "ad.aws.corp" `
-MasterServers 10.10.10.10,10.10.10.11 `
-ReplicationScope Forest `
-PassThru
# AWS vers on-premises
Add-DnsServerConditionalForwarderZone ` -Name "onprem.corp"`
-MasterServers 172.16.0.10,172.16.0.11 ` -ReplicationScope Forest`
-PassThru
# Vérification
Get-DnsServerConditionalForwarderZone
Resolve-DnsName app01.ad.aws.corp -Server 172.16.0.10 Points d’attention :
- Fournissez plusieurs adresses pour la tolérance de panne.
- Assurez‑vous qu’aucun redirecteur global ou root hints non désiré ne capte vos requêtes internes ; l’ordre de résolution doit privilégier les conditionnels.
- Sur les serveurs DNS exposés à Internet, évitez la récursivité ouverte et interdisez le transfert de zone vers des hôtes non autorisés.
Création d’une zone secondaire
La zone secondaire est pertinente pour diminuer la latence côté on‑premises, économiser la bande passante (les réponses sont locales) et tolérer des coupures temporaires de liaisons. Elle introduit cependant une copie des données ; soignez la gouvernance et la sécurité.
- Autoriser le transfert : sur la zone source (ex.
ad.aws.corp), spécifier les IP des serveurs secondaires autorisés. - Créer la zone secondaire sur le serveur cible : type Secondary zone, nom de zone
ad.aws.corp, Master DNS servers = IP des hôtes faisant autorité. - Valider la mise à jour : la première synchronisation peut prendre quelques minutes selon la taille de la zone et le TTL des enregistrements.
- Superviser les transferts : surveiller les journaux DNS (événements d’échec de transfert) et le compteur DNS\Zone Transfer Requests/sec.
Sécurité : restreignez le transfert par liste d’IP ; si la liaison traverse un réseau non maîtrisé, encapsulez le trafic DNS dans un tunnel VPN (ou un lien Direct Connect) déjà chiffré.
Création d’une zone stub
La zone stub stocke seulement les enregistrements NS et leurs A associés pour atteindre les serveurs faisant autorité. Elle se met à jour automatiquement quand les NS changent côté source, tout en restant légère en stockage.
- Dans DNS Manager, créer une Zone Stub nommée
ad.aws.corp. - Indiquer les Master DNS servers de la zone parente.
- Vérifier que la résolution récursive aboutit pour les noms applicatifs.
Considérations spécifiques à AWS
Deux options fréquentes dans AWS :
- Contrôleurs de domaine Windows Server déployés dans des sous‑réseaux privés (VPC), exécutant le service DNS Microsoft.
- AWS Managed Microsoft AD intégré à Route 53 Resolver.
Lorsque vous utilisez Route 53 Resolver, préférez des Outbound Endpoints pour relayer vers on‑premises et des Inbound Endpoints pour recevoir les requêtes en provenance du site. Côté on‑premises, vos DNS Windows envoient les requêtes conditionnelles vers l’IP de l’endpoint au lieu d’adresser directement les DC/DNS. Avantages : haute disponibilité managée, filtrage par security groups, séparation des flux et absence d’exposition directe des DC.
Bonnes pratiques AWS :
- Déployer au moins deux endpoints par type (inbound/outbound) dans des AZ différentes.
- Valider les route tables, NACL et security groups : autoriser
TCP/UDP 53entre les IP des serveurs DNS on‑premises et les endpoints. - Documenter les rules de Route 53 Resolver : un préfixe mal ciblé (
corp.localvsad.corp.local) peut provoquer des boucles ou des échecs.
Intégration avec une confiance inter‑forêts
Si vous établissez ultérieurement un trust inter‑forêts (transitif ou sélectif), l’Assistant de création de relations d’approbation peut proposer la configuration automatique des redirecteurs conditionnels. Même avec un trust, il est recommandé de garder des redirecteurs explicites pour garantir que la résolution suive les chemins réseau maîtrisés (VPN/Direct Connect) et pour un contrôle fin des suffixes concernés.
Résolution côté clients et suffixes DNS
Même avec un routage DNS parfait côté serveurs, une résolution côté poste peut échouer si le FQDN n’est pas complet. Quelques leviers :
- Imposer les FQDN (ex.
app01.ad.aws.corp) dans les configurations applicatives, scripts et URL. - Liste de suffixes de recherche DNS via GPO (Computer Configuration → Policies → Administrative Templates → Network → DNS Client → DNS Suffix Search List) pour tenter
ad.aws.corpetonprem.corpsi un nom court est saisi. - DHCP Option 119 (Domain Search List) pour les clients non‑Windows.
Performance et disponibilité
- TTL : Ajustez les TTL des enregistrements en fonction de la fréquence de changement. Un TTL trop long ralentit la prise en compte des mises à jour ; trop court augmente la charge.
- Cache côté serveurs : Surveillez la taille et la durée du cache (paramètres du service DNS Windows) pour prévenir les réponses obsolètes.
- Haute disponibilité : Publiez au moins deux cibles par redirecteur. Testez l’ordre de tentative et le comportement en panne (failover).
- Isolation : Les redirecteurs limitent l’exposition (pas de transfert de données de zone). Les zones secondaires accroissent la résilience locale mais requièrent une maîtrise stricte des transferts.
Tests et validation
Avant l’ouverture en production, déroulez un plan de validation bout‑en‑bout.
| Test | Commande/Action | Résultat attendu |
|---|---|---|
| Résolution simple on‑prem → AWS | nslookup app01.ad.aws.corp IP_DNS_onprem | Réponse A/AAAA avec l’IP attendue, Server = DNS on‑prem. |
| Résolution inverse | nslookup 10.10.10.50 IP_DNS_onprem | PTR retourné si la zone reverse est déléguée ou relayée. |
| Chemin de résolution PowerShell | Resolve-DnsName app01.ad.aws.corp -Server IP_DNS_onprem -DnsOnly -NoIdn | Détails de l’autorité, temps de réponse, section Answer. |
| Bidirectionnel AWS → on‑prem | nslookup srv01.onprem.corp IP_DNS_AWS | Résolution correcte. |
| Zone secondaire actualisée | Créer/modifier un A dans la zone source, attendre le prochain SOA serial. | La zone secondaire affiche le nouvel enregistrement après transfert. |
Surveillance et dépannage
Activez temporairement la journalisation détaillée durant les tests, puis revenez à un niveau standard.
- Journal DNS : Applications and Services Logs → DNS Server, évènements d’échec de transfert, de timeouts, d’erreurs de signature.
- Outils AD/DNS :
dcdiag /test:dnspour les vérifications d’intégrité DNS des DC.repadmin /showreplpour la réplication AD (utile si redirecteurs intégrés AD).- Compteurs de perf : DNS\Recursive Queries/sec, DNS\Zone Transfer Requests/sec, DNS\Secure Update Failure.
- Traces réseau : Wireshark ou Message Analyzer pour vérifier le transit sur
TCP/UDP 53, la présence de réponses REFUSED ou SERVFAIL, et le bon aiguillage des requêtes conditionnelles.
Erreurs fréquentes et remèdes
| Symptôme | Cause probable | Correction |
|---|---|---|
REQUEST TIMED OUT dans nslookup | Port 53 filtré (pare‑feu/NACL/Security Group) ou IP cible incorrecte | Ouvrir TCP/UDP 53, vérifier la route et les IP des serveurs cibles |
| Non‑existent domain | Suffiх erroné (aws.corp vs ad.aws.corp) ou enregistrement absent | Corriger le redirecteur vers le suffixe précis et vérifier la présence du record |
| Boucle de résolution | Règles de forward incohérentes des deux côtés | Documenter la topologie et supprimer les forwarders « globaux » interférents |
| Zone secondaire jamais à jour | Transfert de zone non autorisé ou blocage TCP | Autoriser explicitement l’IP du secondaire et ouvrir TCP 53 |
| Résolution ok sur serveur, KO sur client | Suffix Search List absente, cache client, DNS du client mal configuré | Déployer la GPO de suffixes, vider le cache (ipconfig /flushdns), vérifier le DHCP |
Sécurité et conformité
- Canal chiffré : privilégiez des liens VPN IPSec ou Direct Connect pour transporter le trafic DNS entre forêts.
- Principe du moindre privilège : pour les zones secondaires, restreignez le transfert aux IP explicitement autorisées. N’exposez jamais un serveur DNS AD directement à Internet.
- Mises à jour sécurisées : sur les zones AD‑intégrées, laissez Secure only pour les updates dynamiques.
- Journalisation : conservez des traces de changement de configuration DNS (GPO, scripts PowerShell versionnés).
Modèle d’implémentation rapide
Avant de commencer
- Recensez les suffixes à résoudre (ex.
ad.aws.corp,apps.aws.corp). - Identifiez les cibles (IP des DC/DNS ou endpoints Route 53 Resolver).
- Validez la connectivité (routes, ACL,
TCP/UDP 53).
Sur le DNS on‑premises
- Créer un redirecteur conditionnel vers
ad.aws.corppointant vers les IP AWS. - Activer l’intégration AD et la réplication au scope adapté.
- Déployer une GPO de suffixes si des noms courts sont utilisés.
Dans AWS
- Avec DC/DNS Windows : configurer le redirecteur conditionnel vers
onprem.corp(si besoin). - Avec Route 53 Resolver : créer des Outbound/Inbound Endpoints et des rules ciblant les suffixes distants.
Validation
Resolve-DnsName app01.ad.aws.corp -Server IP_DNS_onprem
Resolve-DnsName srv01.onprem.corp -Server IP_DNS_AWS
FAQ
Faut‑il une confiance inter‑forêts pour que le DNS fonctionne ?
Non. Le DNS inter‑forêts fonctionne très bien avec des redirecteurs conditionnels, des zones secondaires ou des zones stub. Un trust facilite l’expérience utilisateur (authentification) mais n’est pas requis pour la résolution.
Redirecteur ou zone secondaire ?
Le redirecteur est simple et non intrusif. La zone secondaire apporte des réponses locales et une meilleure résilience, au prix d’une copie (et d’une gouvernance) supplémentaire.
Et si la zone distante change souvent ?
Utilisez des TTL raisonnables (par ex. 300–900 s pour les enregistrements « app »), et préférez le redirecteur (pas de transfert complet) ou une zone stub si seuls les NS évoluent.
Peut‑on mélanger les approches ?
Oui : redirecteurs pour la plupart des suffixes, et zone secondaire pour une zone critique à forte volumétrie. Documentez l’ensemble pour éviter les boucles.
Comment auditer facilement ?
Centralisez un script PowerShell listant les Get-DnsServerConditionalForwarderZone, les zones Secondary/Stub, et comparez avec l’inventaire attendu.
Exemples de scripts utiles
Rapport des redirecteurs conditionnels :
$servers = @("dns-onprem-01","dns-onprem-02")
$result = foreach ($s in $servers) {
Get-DnsServerConditionalForwarderZone -ComputerName $s |
Select-Object @{n="Server";e={$s}}, ZoneName, MasterServers, ReplicationScope
}
$result | Format-Table -Auto
Création d’une zone secondaire :
Add-DnsServerSecondaryZone `
-Name "ad.aws.corp" `
-ZoneFile "ad.aws.corp.dns" `
-MasterServers 10.10.10.10,10.10.10.11
Checklist de fin de mise en œuvre
- Redirecteurs conditionnels créés et répliqués sur tous les DC/DNS pertinents.
- Règles de pare‑feu actives (
TCP/UDP 53), testsnslookupconcluants dans les deux sens. - Suffix Search List déployée si nécessaire.
- Supervision mise en place : journaux DNS, alertes sur échec de transfert et sur latence anormale.
- Documentation à jour : schémas, IP cibles, règles Resolver, procédures de reprise.
Conclusion
En environnement hybride, la résolution DNS inter‑forêts est un prérequis à toute authentification et à la consommation d’applications cross‑sites. Les redirecteurs conditionnels constituent le levier le plus rapide et le plus sûr pour démarrer, sans refonte des zones ni licences supplémentaires. Selon vos objectifs de latence, de résilience et de gouvernance, complétez par des zones secondaires ou stub. En appliquant les bonnes pratiques réseau (VPN/Direct Connect, contrôle des transferts), la journalisation et les tests proposés ici, vous obtiendrez une résolution robuste, observable et évolutive entre votre forêt AWS et votre forêt on‑premises.
Rappels essentiels :
- Redirecteurs conditionnels bidirectionnels = gains rapides et faible surface d’attaque.
- Zones secondaires = résilience locale, penser
TCP 53et autorisations de transfert. - Zones stub = légèreté + auto‑actualisation des serveurs faisant autorité.
- Outils :
dcdiag /test:dns,repadmin /showrepl,Resolve-DnsName, journaux DNS.