Installer un serveur DNS Windows Server et maîtriser la réplication DNS

Dans un domaine Active Directory, le DNS n'est pas un service à part : il vit dans l'annuaire et se réplique avec lui. Installation du rôle, création des zones, choix de l'étendue de réplication et contrôles, sur un lab à deux contrôleurs.

Par la rédaction de Pixelabs · 12 octobre 2026

Le serveur DNS de Windows Server traduit les noms en adresses pour tout le réseau, et Active Directory en dépend entièrement : un contrôleur de domaine se localise par des enregistrements DNS. La procédure ci-dessous suit le guide de démarrage rapide de Microsoft, valable de Windows Server 2016 à Windows Server 2025, et l'applique à un lab.

La topologie du lab

Toutes les adresses sont dans une plage privée RFC 1918. Le client interroge uniquement les deux serveurs internes : c'est eux qui iront chercher les noms extérieurs.

Prérequis

Microsoft liste trois conditions :

• une version de Windows Server prise en charge ;
• une adresse IP statique sur le serveur DNS ;
• un compte membre du groupe Administrateurs ou équivalent.

Montez ce lab dans des machines virtuelles et prenez un instantané avant chaque étape ; en production, sauvegardez l'état système des contrôleurs avant de modifier une zone. Pour partir d'un système à jour, voyez l'installation de Windows Server 2025.

Installer le rôle DNS

Deux cas se présentent.

Sur un futur contrôleur de domaine, l'assistant d'installation d'AD DS propose d'installer et de configurer le serveur DNS en même temps. Microsoft précise que la zone obtenue est alors intégrée à l'espace de noms du domaine. C'est le cas de dc01 et dc02.

Sur un serveur DNS autonome, installez le rôle en PowerShell, dans une session élevée. Selon Microsoft, aucun redémarrage n'est nécessaire :

Install-WindowsFeature -Name DNS

Le même rôle s'ajoute par le Gestionnaire de serveur, en cochant Serveur DNS dans l'assistant d'ajout de rôles.

Limiter les interfaces d'écoute

Par défaut, le serveur répond sur toutes ses adresses IP. Sur une machine à plusieurs cartes, restreignez l'écoute à l'adresse du LAN, comme le montre Microsoft :

$DnsServerSettings = Get-DnsServerSetting -ALL
$DnsServerSettings.ListeningIpAddress = @("192.168.10.10")
Set-DNSServerSetting $DnsServerSettings

Zones : où sont stockés les enregistrements

Microsoft distingue trois types de zones :

Une zone principale peut être stockée dans un fichier ou dans AD DS. Dans le second cas, on parle de zone intégrée à Active Directory. Microsoft précise qu'elle n'existe que sur les contrôleurs de domaine qui portent le rôle DNS, et que seules ces zones acceptent les mises à jour dynamiques sécurisées.

Créer une zone intégrée

Une zone de recherche directe et une zone de recherche inversée pour le lab :

Add-DnsServerPrimaryZone -Name "app.lab.local" -ReplicationScope "Domain" -DynamicUpdate "Secure"
Add-DnsServerPrimaryZone -NetworkID "192.168.10.0/24" -ReplicationScope "Domain"

Puis un premier enregistrement A :

Add-DnsServerResourceRecordA -Name "srv-web01" -ZoneName "app.lab.local" -IPv4Address "192.168.10.20"

La réplication DNS dans Active Directory

C'est le point qui distingue Windows Server d'un serveur DNS classique. Une zone intégrée ne se réplique pas par transfert de zone : elle voyage avec la réplication d'Active Directory, vers tous les contrôleurs concernés.

D'après Microsoft, la zone créée au déploiement d'AD DS se réplique par défaut vers tous les autres contrôleurs du domaine configurés comme serveurs DNS. Le paramètre -ReplicationScope choisit la partition d'annuaire où vit la zone :

L'étendue d'une zone existante se change sans la recréer :

Set-DnsServerPrimaryZone -Name "app.lab.local" -ReplicationScope "Forest"

Comme la zone dépend de la réplication AD, un enregistrement absent sur dc02 est presque toujours un problème de réplication de l'annuaire, pas de DNS. Les commandes repadmin et dcdiag /test:DNS sont détaillées dans la page sur les outils de dépannage Active Directory.

Et les transferts de zone ?

Ils restent utiles pour alimenter une zone secondaire hors de l'annuaire, par exemple un serveur BIND 9. Microsoft distingue le transfert complet (AXFR) et le transfert incrémentiel (IXFR), et rappelle que, par défaut, un serveur secondaire interroge le principal toutes les 15 minutes selon l'intervalle d'actualisation du SOA. Côté sécurité, n'autorisez les transferts que vers les serveurs listés en NS ou nommés explicitement : sinon, n'importe quel hôte peut obtenir la carte de votre réseau interne. Le pendant Linux est décrit dans la page sur BIND 9 en primaire et secondaire.

Résoudre les noms extérieurs : redirecteurs

Sans configuration, le serveur interroge les serveurs racine. Pour passer plutôt par les résolveurs de votre fournisseur ou de votre pare-feu, déclarez des redirecteurs :

Set-DnsServerForwarder -IPAddress "192.168.10.1"

Microsoft précise que les indications de racine ne servent plus que si les redirecteurs ne répondent pas.

Vérifier

Depuis cli01, interrogez chaque serveur explicitement :

Resolve-DnsName -Name srv-web01.app.lab.local -Server 192.168.10.10
Resolve-DnsName -Name srv-web01.app.lab.local -Server 192.168.10.11

Les deux doivent renvoyer 192.168.10.20. Sur chaque contrôleur, Get-DnsServerZone liste les zones hébergées : les deux listes doivent être identiques pour les zones de l'étendue Domain.

D'autres tutoriels sont rassemblés dans la rubrique Windows Server et sur l'accueil des tutoriels Linux et Windows.

Questions fréquentes