Dans Active Directory, la cohérence de la résolution DNS dépend en partie d’une liste de serveurs racine fiable. Découvrez ici comment identifier la source réelle des root hints, les mettre à jour correctement et maintenir un environnement Windows Server robuste et sécurisé.
Mise à jour des root hints sur un serveur DNS Windows intégré à Active Directory
1. Problématique rencontrée
Après une modification manuelle dans la console DNS Manager, l’administrateur observe :
- Le fichier
%systemroot%\System32\Dns\cache.dnsne reflète aucune modification. - La vue DNS Manager ▸ Root Hints affiche un contenu différent de celui du fichier.
nslookup b.root-servers.netretourne encore d’autres adresses IP.
Le doute s’installe : où Windows stocke‑t‑il exactement ces informations, comment les modifie‑t‑on de façon pérenne, et pourquoi ces divergences existent‑elles ?
2. Où sont réellement stockés les root hints ?
| Élément | Rôle réel | Pourquoi il diffère |
|---|---|---|
cache.dns | Fichier fallback lu une seule fois au démarrage si le contrôleur de domaine n’a pas déjà une copie dans AD. Jamais mis à jour automatiquement. | Une fois les données présentes dans AD, toute modification manuelle de cache.dns est ignorée. |
| DNS Manager ▸ Root Hints | Vue directe des objets stockés dans l’annuaire, sous :CN=MicrosoftDNS,CN=System,DC=<domaine> | Cette liste est donc l’unique source de vérité en environnement AD. |
nslookup | Interroge la résolution normale ; reçoit des réponses anycast et/ou mises en cache. | Les adresses retournées fluctuent (IPv4/IPv6, plusieurs sites anycast), sans lien direct avec le contenu des hints. |
3. Pourquoi mettre à jour les root hints ?
- Fiabilité DNS : la liste officielle évolue (ajout/retrait d’adresses anycast, décommissionnements).
- Performance : pointer vers une IP obsolète rallonge le temps de résolution, ou provoque des échecs.
- Sécurité : une entrée erronée peut être exploitée pour détourner la résolution (homographes, re‑routing).
- Conformité : certaines normes internes exigent une vérification périodique.
4. Méthode recommandée (AD‑intégré)
Étape 1 : obtenir la liste officielle
Téléchargez ou récupérez hors ligne le fichier named.root (également appelé root.hints) fourni par l’IANA/InterNIC. Copiez‑le, par exemple, dans C:\Temp\named.root.
Étape 2 : mettre à jour un seul contrôleur de domaine
Via l’interface graphique
DNS Manager ▸ <Serveur> ▸ Root Hints ▸ Remove ▸ Add ▸ From File…Ou en PowerShell :
Import-DnsServerRootHint -File "C:\Temp\named.root"Étape 3 : laisser la réplication AD faire son travail
La nouvelle liste est stockée comme objets AD et répliquée selon votre topologie.
Pour accélérer :
repadmin /syncall /AdePÉtape 4 : vérifier la cohérence
Get-DnsServerRootHint
nslookup b.root-servers.net5. Scénarios spéciaux et commandes utiles
dnscmd /ResetRootHints: réinitialise la liste AD avec les valeurs par défaut installées par Microsoft.- Environnement non‑AD : copiez le fichier
cache.dnsmis à jour sur chaque serveur, puis redémarrez le service DNS (net stop dns & net start dns). - Contrôleur isolé : si la réplication AD est coupée, veillez à importer manuellement les hints sur le site isolé.
6. Root hints vs. Forwarders : bien choisir
| Caractéristique | Root Hints | DNS Forwarders |
|---|---|---|
| Destination | Serveurs racine publics gérés par l’IANA | DNS spécifiques (ex. serveur ISP ou filtrage corporate) |
| Contrôle interne | Faible : dépend d’Internet | Élevé : vous choisissez le(s) serveur(s) |
| Performance | Direct ; multiples sites anycast | Peut être plus rapide si local ou en cache massif |
| Redondance | Très élevée (13 noms, >400 instances anycast) | Dépend du nombre de forwarders ajoutés |
| Sécurité/Filtrage | Aucun filtrage ; brut | Possible (filtrage contenus, RPZ, DoT/DoH) |
Bonnes pratiques : conservez des root hints même si vous utilisez des forwarders ; ils serviront de repli en cas de panne du forwarder.
7. Automatisation avancée PowerShell
Pour des environnements multi‑forêts ou pour intégrer la mise à jour dans une CI/CD d’infrastructure, un petit script :
# Chemins
$rootHintPath = "C:\Ops\root_hints\named.root"
$dcList = Get-ADDomainController -Filter *
foreach (\$dc in \$dcList) {
Invoke-Command -ComputerName \$dc.HostName -ScriptBlock {
param(\$file)
Import-DnsServerRootHint -File \$file -PassThru
} -ArgumentList \$rootHintPath
}Vous pouvez déclencher ce script via une tâche planifiée mensuelle ou via votre pipeline Azure DevOps/GitHub Actions.
8. Validation périodique : quoi surveiller ?
- Événements DNS (100‑199) dans le journal DNS Server : toute erreur de transmission vers un serveur racine y apparaît.
Get-DnsServerDiagnostics: vérifiez queEnableRootHintsest à$Trueet queBindSecondariesest correctement configuré.Resolve-DnsName . -Server <DC> -NoHostsFile: le point (« . ») interroge directement les racines.- Analyse Wireshark : filtrez
dns && ip.dst == <root hint IP>pour valider les échanges UDP et TCP 53.
9. FAQ
Dois‑je redémarrer le service DNS après Import-DnsServerRootHint ? Non. Le changement est instantané et visible immédiatement dans Get-DnsServerRootHint.
<dt>Comment savoir quand la liste officielle change ?</dt>
<dd>Surveillez le fichier <code>named.root</code> publié par l’IANA ; il est mis à jour à chaque ajout ou retrait d’instance anycast (quelques fois par an).</dd>
<dt>Puis‑je supprimer totalement les <em>root hints</em> et n’utiliser que mes forwarders ?</dt>
<dd>Oui, mais c’est risqué : en cas de panne de vos forwarders, votre résolution externe est bloquée. Laisser les racines en secours est conseillé.</dd>
<dt>Combien de temps un contrôleur de domaine met‑il pour répliquer les nouveaux <em>hints</em> ?</dt>
<dd>Selon votre topologie : intranet gigabit → quelques secondes ; lien WAN lent ou programme de réplication programmé → jusqu’à 180 minutes (valeur par défaut du <em>tombstone interval</em>).</dd>10. Bonnes pratiques de sécurité
- Restreindre l’accès à la console DNS et aux cmdlets PowerShell ; utilisez des groupes AD dédiés (DNSAdmins).
- Activer la journalisation DNS > Advanced Logging pour suivre toute modification inattendue des enregistrements racine.
- Superviser la résolution : un temps de réponse soudainement long vers « . » peut signaler un hint obsolète ou bloqué.
- Signature DNSSEC côté client : elle ne signe pas les hints mais protège la chaîne suivante de résolution, réduisant l’exposition.
11. Quand faut‑il répéter l’opération ?
Les serveurs racine sont stables ; une révision bi‑annuelle suffit dans 95 % des cas. Toutefois, planifiez une vérification immédiate si :
- Vous migrez vers une nouvelle version de Windows Server.
- Des symptômes de résolution aléatoire apparaissent (timeouts, erreurs ServFail).
- Une alerte de sécurité annonce la mise hors service d’un serveur racine.
12. Résumé
Dans un domaine Active Directory, cache.dns n’a plus aucun rôle opérationnel. Les root hints vivent dans l’annuaire, se répliquent automatiquement et se mettent à jour via la console DNS Manager, dnscmd ou PowerShell. Suivez la méthode décrite pour garantir un DNS rapide, fiable et sécurisé sur l’ensemble de vos contrôleurs de domaine.