
Contexte 📚
Lors d’une restauration d’un environnement AD à des fins de test, la résolution DNS renvoyait des adresses IP anciennes et périmées pour les contrôleurs de domaine (DC). En examinant la zone DNS intégrée à AD, des enregistrements A pointant vers les anciennes IP ont été découverts. La suppression manuelle de ces entrées a résolu le problème.


Pourquoi une restauration AD peut laisser des enregistrements DNS périmés ? 🧐
- Les zones DNS intégrées à AD sont répliquées avec le catalogue AD. Si la sauvegarde restaurée contient des objets
dnsNodeobsolètes, ils sont réimportés. - Les contrôleurs de domaine s’enregistrent automatiquement via le service
Netlogon. Après une restauration, les anciennes entrées peuvent rester tant que le nouveau DC ne rafraîchit pas son enregistrement. - Si le scavenging DNS n’est pas activé, les enregistrements avec un timestamp expiré ne sont jamais purgés.
Quand cela arrive ? ⚠️
Vous observez les symptômes suivants :
- nslookup d’un DC renvoie une adresse IP qui n’est plus utilisée.
- Ping ou RDP échoue vers le DC même si l’adresse IP actuelle est correcte.
- Les journaux d’événements DNS indiquent des conflits d’enregistrements.
Étapes pour identifier et nettoyer les enregistrements DNS obsolètes 🔹
-
Vérifier la résolution DNS actuelle avec nslookup
nslookup dc01.mondomaine.localNotez l’adresse IP retournée et comparez‑la avec l’adresse réelle du serveur.
-
Lister les enregistrements A du DC dans la zone AD
Get-DnsServerResourceRecord -ZoneName "mondomain.local" -Name "dc01" -RRType "A" | Format-Table HostName,RecordData,TimestampLe champ
Timestampindique la dernière mise à jour. -
Identifier les enregistrements périmés
- Si le
Timestampest très ancien (ex. > 30 jours) ou si l’adresse ne correspond plus, c’est suspect.
- Si le
-
Supprimer l’enregistrement obsolète via PowerShell
# Exemple : suppression d'un enregistrement A erroné Remove-DnsServerResourceRecord -ZoneName "mondomain.local" ` -RRType "A" -Name "dc01" -RecordData "192.168.1.55" -ForceUtilisez
-Forcepour éviter la confirmation interactive. -
Vérifier la mise à jour
nslookup dc01.mondomaine.localL’adresse IP retournée doit maintenant correspondre à l’adresse réelle du DC.
-
Forcer le rafraîchissement de l’enregistrement du DC
ipconfig /registerdnsCette commande force le service Netlogon à ré‑enregistrer le DC dans DNS.
Méthodes alternatives ou explications techniques 🛠️
- Utilisation de dnscmd (outil en ligne de commande) :
dnscmd /enumrecords mondomain.local dc01 /type A
dnscmd /recorddelete mondomain.local dc01 @ /A 192.168.1.55 /f
- Via le Gestionnaire DNS (GUI) :
- Ouvrez DNS Manager sur un serveur DNS.
- Développez
mondomain.local → Zones de recherche directe → _msdcs(ou la zone principale). - Cliquez droit sur l’enregistrement
dc01→ Supprimer. - Confirmez la suppression.
Bonnes pratiques pour éviter le problème à l’avenir ✅
- Activer le scavenging DNS :
# Activer le scavenging sur la zone Set-DnsServerZoneAging -Name "mondomain.local" -Aging $true -Scavenging $true # Configurer les intervalles (ex. 7 jours) Set-DnsServerScavenging -ScavengingInterval 7.00:00:00 - Vérifier que les enregistrements dynamiques ont l’attribut
SecureOnlyafin que seuls les contrôleurs autorisés puissent les modifier. - Planifier une tâche hebdomadaire pour afficher les enregistrements avec
Timestampdépassé :
Get-DnsServerResourceRecord -ZoneName "mondomain.local" |
Where-Object {$_.Timestamp -lt (Get-Date).AddDays(-30)} |
Format-Table HostName,RecordData,Timestamp
ipconfig /registerdns sur tous les DC et vérifier le bon fonctionnement avec nslookup.Conclusion ✅
Une restauration d’Active Directory peut réintroduire des enregistrements DNS qui ne sont plus valides, entraînant des résolutions erronées. En suivant les étapes ci‑dessus – identification avec nslookup ou PowerShell, suppression sécurisée des entrées et activation du scavenging – vous garantissez un environnement DNS propre et fiable. N’oubliez pas d’automatiser les contrôles post‑restauration pour éviter que le problème ne se reproduise.
