DNS intégré à Active Directory : zones, reverse lookup et scavenging pas à pas

Active Directory et DNS sont indissociables. Aucun client ne trouve un contrôleur de domaine sans résoudre des enregistrements SRV ; aucune réplication ne s’opère sans résolution de noms cohérente ; aucun ouverture de session ne se complète si le DNS ment ou se tait. Pourtant, le service DNS de Windows Server reste l’un des plus mal configurés en PME : zones non sécurisées, scavenging absent, reverse lookup manquant, forwarders aberrants.

Ce tutoriel pose une configuration DNS propre, complète et durable pour un domaine AD : zone primaire intégrée, zone de reverse lookup, scavenging activé, sécurité renforcée. Le résultat : un DNS qui répond vite, qui s’auto-nettoie, et qui résiste à la plupart des attaques courantes.

Prérequis : domaine AD opérationnel (cf. Promouvoir le premier contrôleur de domaine Active Directory). Vue d’ensemble : Windows Server 2025 et Active Directory pour PME.

Prérequis

• Un DC Windows Server 2025 avec le rôle DNS Server installé (automatique à la promotion).
• Un compte Domain Admin ou DnsAdmins.
• Le plan d’adressage IPv4 du LAN (par exemple 10.10.0.0/24).
• Si la PME a un nom de domaine public possédé, les identifiants du registrar pour configurer un éventuel sous-domaine de délégation.
• Niveau attendu : intermédiaire.
• Temps estimé : 30 minutes.

Étape 1 — Comprendre les types de zones DNS sous Windows

Le serveur DNS de Windows Server gère trois types de zones, qu’il faut distinguer avant de configurer quoi que ce soit :

• Zone primaire standard — la zone est stockée dans un fichier texte (%SystemRoot%\System32\dns\). Une seule machine peut éditer la zone. Réplication via zone transfer classique.
• Zone primaire intégrée à AD — la zone est stockée dans la base AD. Toutes les modifications sont multimaîtres : n’importe quel DC du domaine peut mettre à jour la zone, et la modification se propage via la réplication AD. C’est le mode recommandé pour les zones internes.
• Zone secondaire — copie en lecture seule d’une zone primaire externe, mise à jour par zone transfer. Utile pour héberger une zone publique en backup, rarement utilisée en PME.

Pour le domaine AD ad.entreprise.com, la zone est créée automatiquement comme primaire intégrée à AD à la promotion. On la conserve ainsi.

Étape 2 — Inspecter la zone existante

La console DNS Manager (dnsmgmt.msc) montre la zone ad.entreprise.com, son contenu et son mode. En PowerShell :

Get-DnsServerZone | Where-Object IsAutoCreated -eq $false |
  Format-Table ZoneName, ZoneType, IsDsIntegrated, ReplicationScope, IsReverseLookupZone

La sortie attendue : ad.entreprise.com en Primary, IsDsIntegrated: True, ReplicationScope: Domain. La portée Domain signifie que la zone se réplique sur tous les DC de ce domaine. Pour une forêt mono-domaine, c’est le bon choix.

Si la zone n’est pas intégrée à AD (par exemple sur un déploiement manuel ancien), on la convertit :

ConvertTo-DnsServerPrimaryZone -Name 'ad.entreprise.com' `
  -ReplicationScope 'Domain' -Force

Étape 3 — Créer la zone de reverse lookup

La zone de reverse lookup traduit une IP en nom (l’inverse du A record). Microsoft ne la crée pas automatiquement. Sans elle, beaucoup d’outils diagnostiquent un DNS incomplet : nslookup 10.10.0.10 renvoie un nom inconnu, les journaux d’audit Kerberos sont moins clairs, et certains services (SQL, Exchange en hybride) refusent des opérations.

Pour un LAN en 10.10.0.0/24 :

Add-DnsServerPrimaryZone -NetworkID '10.10.0.0/24' `
  -ReplicationScope 'Domain' -DynamicUpdate 'Secure'

Le paramètre NetworkID calcule automatiquement le nom de zone correct (0.10.10.in-addr.arpa). Le mode Secure de mise à jour dynamique impose que seul un client authentifié AD puisse créer ses enregistrements. Vérifier :

Get-DnsServerZone -Name '0.10.10.in-addr.arpa'

Forcer les DC à s’auto-inscrire dans la nouvelle reverse zone :

ipconfig /registerdns

Quelques minutes plus tard, Resolve-DnsName 10.10.0.10 -Server 127.0.0.1 doit renvoyer dc01.ad.entreprise.com.

Étape 4 — Activer le scavenging

Le scavenging (récupération automatique) supprime les enregistrements DNS dont la machine source ne s’est plus inscrite depuis longtemps. Sans scavenging, un poste portable qui change de réseau ou un serveur déprommu laisse traîner son A record indéfiniment, ce qui pollue la résolution. Le scavenging est désactivé par défaut et c’est un réflexe à corriger sur tout DNS AD.

Activer le scavenging au niveau du serveur :

Set-DnsServerScavenging -ScavengingState $true `
  -ScavengingInterval 7.00:00:00 -ApplyOnAllZones

L’intervalle 7.00:00:00 signifie sept jours : le serveur lance un cycle de nettoyage hebdomadaire. Activer également sur chaque zone individuelle :

Set-DnsServerZoneAging -Name 'ad.entreprise.com' -Aging $true `
  -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00

Set-DnsServerZoneAging -Name '0.10.10.in-addr.arpa' -Aging $true `
  -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00

Avec ces réglages, un enregistrement non rafraîchi pendant 14 jours est considéré stale et candidate au nettoyage. Les clients Windows se réinscrivent toutes les 24h par défaut, donc seuls les enregistrements vraiment orphelins disparaissent.

Étape 5 — Configurer les forwarders DNS

Pour résoudre les domaines externes (google.com, microsoft.com), deux options : laisser le DNS Windows interroger directement les serveurs racine via les root hints, ou lui imposer de transférer les requêtes externes à un DNS récursif rapide. La deuxième approche est plus rapide, plus stable et plus simple à filtrer en cas de problème.

On configure typiquement deux forwarders publics :

Set-DnsServerForwarder -IPAddress 1.1.1.1, 1.0.0.1 -UseRootHint $false

1.1.1.1 et 1.0.0.1 sont Cloudflare DNS, neutres et rapides. Alternatives selon les contraintes : 9.9.9.9 pour Quad9 (filtrage de domaines malicieux intégré), 8.8.8.8 pour Google. Désactiver les root hints (-UseRootHint $false) garantit que les requêtes externes passent toujours par les forwarders.

Vérifier :

Resolve-DnsName google.com -Server 127.0.0.1

La réponse doit revenir en moins de 50 ms après le premier appel (le cache local stocke les TTL).

Aparté — Comprendre la délégation _msdcs

Quand on inspecte une zone AD-intégrée, on remarque toujours une sous-zone _msdcs.ad.entreprise.com séparée. Cette sous-zone héberge tous les enregistrements SRV des services AD (LDAP, Kerberos, Global Catalog) et fait l’objet d’une délégation explicite par AD lors de la promotion du premier DC. Pourquoi cette complication ? Parce que le suffixe DNS d’un poste client peut différer du domaine AD (cas d’un poste joint à un domaine enfant), et la délégation _msdcs à la racine de la forêt permet à tout client de trouver les DC d’un domaine enfant sans configuration manuelle.

En PME mono-domaine, on n’a presque jamais à toucher à _msdcs. Mais si une migration de domaine ou un renommage est tenté un jour, cette zone est l’une des premières à corrompre. La connaître permet de reconnaître les symptômes : ouvertures de session lentes, erreurs Kerberos cryptiques, comptes machine qui n’arrivent plus à mettre à jour leur secret. En cas de doute, dcdiag /test:DNS /v teste la santé complète des enregistrements DNS critiques d’un DC.

Étape 6 — Sécuriser les transferts de zone et l’écoute

Par défaut, le DNS Windows autorise des transferts de zone vers n’importe quel serveur secondaire — un risque de fuite d’information (toute la cartographie interne lisible). En zone AD-integrated, les transferts sont peu utiles puisque la réplication passe par AD. On les désactive :

Set-DnsServerPrimaryZone -Name 'ad.entreprise.com' `
  -SecureSecondaries 'NoTransfer'

Set-DnsServerPrimaryZone -Name '0.10.10.in-addr.arpa' `
  -SecureSecondaries 'NoTransfer'

De même, le serveur écoute par défaut sur toutes les interfaces. Sur un DC avec plusieurs cartes réseau (par exemple une carte de management dédiée), on restreint l’écoute aux interfaces internes :

Set-DnsServerSetting -ListeningIPAddress '10.10.0.10'

Étape 7 — Surveiller les enregistrements SRV critiques

Les clients Windows trouvent le DC en interrogeant des SRV bien précis. Si ces SRV disparaissent (mauvaise configuration, scavenging trop agressif sur un DC arrêté), les ouvertures de session échouent silencieusement.

Liste des SRV indispensables :

$names = @(
  '_ldap._tcp.dc._msdcs.ad.entreprise.com',
  '_kerberos._tcp.dc._msdcs.ad.entreprise.com',
  '_ldap._tcp.gc._msdcs.ad.entreprise.com',
  '_gc._tcp.ad.entreprise.com',
  '_kpasswd._tcp.ad.entreprise.com'
)
foreach ($n in $names) {
  Write-Host "=== $n ==="
  Resolve-DnsName $n -Type SRV -Server 127.0.0.1
}

Chaque résolution doit renvoyer au moins un DC avec son port et sa priorité. Si un SRV manque, redémarrer le service Netlogon sur le DC concerné : Restart-Service Netlogon.

Étape 8 — Activer le DNSSEC sur la zone interne (optionnel)

DNSSEC signe cryptographiquement chaque réponse DNS, ce qui empêche un attaquant local d’empoisonner le cache d’un client. Sur une zone interne intégrée à AD, l’activation reste optionnelle : la menace de DNS spoofing en LAN existe mais reste anecdotique en PME. Si la PME héberge un service exposé via cette zone, activer DNSSEC apporte un niveau de protection supplémentaire :

Invoke-DnsServerZoneSign -ZoneName 'ad.entreprise.com' -SignWithDefault

L’opération crée automatiquement les clés KSK et ZSK et signe la zone. Vérifier ensuite avec Get-DnsServerSigningKey -ZoneName 'ad.entreprise.com'. Attention : les clients non-Windows ou anciens (XP, vieux Linux) peuvent ne pas comprendre DNSSEC ; tester avant un déploiement large.

Étape 9 — Configurer un forwarder conditionnel pour Microsoft 365

Si l’entreprise utilise Microsoft 365 avec un domaine personnalisé, on crée un forwarder conditionnel pour que les requêtes vers entreprise.com (le domaine public) soient résolues par les serveurs publics, et non par le DNS interne :

Add-DnsServerConditionalForwarderZone -Name 'entreprise.com' `
  -MasterServers 1.1.1.1, 1.0.0.1 -ReplicationScope 'Forest'

Cela permet aux postes du domaine de résoudre autodiscover.entreprise.com, mail.entreprise.com et autres enregistrements externes sans que le DNS interne héberge une zone entreprise.com potentiellement obsolète.

Étape 10 — Comprendre le DNS Socket Pool

Depuis Windows Server 2008 R2, le serveur DNS utilise un socket pool qui randomise le port source utilisé pour les requêtes sortantes. Cette protection contre les attaques par empoisonnement de cache (Kaminsky 2008) est activée par défaut, mais ses paramètres méritent une vérification. La taille par défaut du pool est de 2 500 ports, ce qui est raisonnable pour une PME.

Get-DnsServerSetting -All | Select-Object SocketPoolSize, SocketPoolExcludedPortRanges

Si le pool est inférieur à 2 500 ou si des ports sont exclus sans raison, on rétablit la configuration de référence :

dnscmd /Config /SocketPoolSize 2500
Restart-Service dns

Ce paramétrage prend effet au prochain redémarrage du service DNS. Vérifier qu’aucun service tiers (un antivirus mal configuré, par exemple) ne réserve les ports UDP éphémères, ce qui réduirait l’efficacité de la randomisation.

Étape 11 — Bloquer les requêtes vers les domaines internes connus

Une bonne pratique de durcissement consiste à empêcher le serveur DNS de répondre à des requêtes pour des noms internes depuis l’extérieur. Si le DC est exposé au-delà du LAN par erreur de configuration réseau, un attaquant pourrait énumérer la structure interne en testant des noms communs (sccm.ad.entreprise.com, backup.ad.entreprise.com…). Le mécanisme Response Rate Limiting de Windows Server 2025 ralentit les énumérations automatisées :

Set-DnsServerResponseRateLimiting -Mode 'Enable' `
  -ResponsesPerSec 5 -ErrorsPerSec 5 -WindowInSec 5 -IPv4PrefixLength 24

Avec ces réglages, un même /24 ne reçoit pas plus de 5 réponses par seconde sur les types de requêtes ratées. Les utilisateurs légitimes ne sont jamais limités, mais une énumération brute force devient impraticable.

Compléter par un audit des requêtes pour détecter les anomalies :

Set-DnsServerDiagnostics -EventLogLevel 4 `
  -QueryFailureEvent $true -ServerLevelPluginDll $null

Les requêtes échouées s’inscrivent dès lors dans le journal DNS Server. Un volume soudain de requêtes ratées pour des noms inexistants est un signal classique de reconnaissance ou de DNS tunneling.

Étape 12 — Sauvegarder la configuration DNS

La zone est dans AD, donc protégée par la sauvegarde System State. Les forwarders et paramètres globaux du serveur DNS, eux, sont dans le registre. Exporter pour permettre une restauration rapide en cas de drift :

$d = Get-Date -Format 'yyyyMMdd'
mkdir 'C:\Admin\backup-dns' -ErrorAction SilentlyContinue

Get-DnsServerForwarder | Export-Clixml "C:\Admin\backup-dns\forwarders-$d.xml"
Get-DnsServerScavenging | Export-Clixml "C:\Admin\backup-dns\scavenging-$d.xml"
Export-DnsServerZone -Name 'ad.entreprise.com' -FileName "ad-$d.dns"

Programmer cette routine dans une tâche planifiée hebdomadaire, et faire pivoter les exports sur quatre semaines pour avoir un historique exploitable en cas d’incident. Stocker les exports sur un volume distinct de la base AD : un disque dur de sauvegarde dédié, un share réseau monté en lecture/écriture pour ce seul script, ou un bucket S3-compatible (Wasabi, OVH Object Storage, MinIO auto-hébergé) avec versioning activé. La taille des exports reste modeste — quelques centaines de kilo-octets par fichier — donc le coût de stockage est négligeable face à la valeur du retour rapide en cas de drift.

Erreurs fréquentes

Vérification finale

Le serveur DNS du DC est désormais : intégré à AD, équipé d’une reverse zone, scavenging activé avec des intervalles raisonnables, forwarders publics fiables, transferts de zone fermés, SRV en place, et configuration sauvegardée. Toutes les ouvertures de session, les jointures de poste et les recherches Kerberos vont passer par cette infrastructure.

La suite logique : déployer le DHCP redondé en failover pour distribuer ces serveurs DNS aux postes, puis joindre les premiers postes Windows 11. Pour le panorama complet : Windows Server 2025 et Active Directory pour PME.

Ressources officielles

• DNS Server overview — Microsoft Learn
• DnsServer PowerShell module reference — Microsoft Learn
• DNS namespace planning for AD DS — Microsoft Learn
• Scavenging stale DNS records — Microsoft Learn