MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Windows Server DNS : gérer une exception locale pour host1.abc.com sans perturber le forwarding

Windows Server DNS : gérer une exception locale pour host1.abc.com sans perturber le forwarding

Windows Server

Vous devez rediriger host1.abc.com vers une IP interne sans rompre le transfert externe du reste du domaine ? Voici deux approches éprouvées sur Windows Server DNS, du plus simple au plus flexible, avec bonnes pratiques, dépannage et automatisation.

Sommaire

Création d’une exception locale avec une zone enfant ultra‑spécifique

Principe

Windows DNS sélectionne toujours la réponse issue de la zone la plus spécifique (chaîne de nom la plus longue). En créant une zone primaire nommée host1.abc.com, on isole l’hôte dans son propre conteneur ; toutes les autres requêtes *.abc.com continueront de suivre la règle de transfert déjà en place.

Étapes pas à pas

  1. Créer la zone spécifique
    Add-DnsServerPrimaryZone -Name "host1.abc.com" -ZoneFile "host1.abc.com.dns"
  2. Ajouter l’enregistrement A
    Add-DnsServerResourceRecordA -Name "@" -ZoneName "host1.abc.com" -IPv4Address "192.168.1.100"
  3. Laisser le redirecteur (conditional forwarder) existant pour abc.com.

Pourquoi cela fonctionne‑t‑il ?

  • host1.abc.com ⟶ correspond à la zone host1.abc.com ⟶ réponse locale.
  • www.abc.com, mail.abc.com, etc. ⟶ aucune zone locale correspondante ⟶ la requête est transférée.

Avantages / limites rapides

AvantagesLimites
Implémentation immédiate
Pas de dépendance à la version du serveur		Impossible d’ajouter d’autres enregistrements abc.com sans créer d’autres zones enfant
Difficile à maintenir si le nombre d’exceptions explose

Variante avancée : DNS Policies (Windows Server 2016 +)

Quand préférer cette méthode ?

Choisissez‑la si vous devez :

  • conserver une zone locale abc.com complète (par exemple pour des enregistrements MX internes) ;
  • gérer plusieurs exceptions ponctuelles ;
  • appliquer des comportements différents selon l’IP cliente, la période, etc.

Mise en place détaillée

  1. Créer la zone et ses scopes
    # Zone générique Add-DnsServerPrimaryZone -Name "abc.com" -ZoneFile "abc.com.dns" # Scope qui continuera d'être transféré Add-DnsServerZoneScope -ZoneName "abc.com" -Name "ForwarderScope" # Scope local ne contenant que host1 Add-DnsServerZoneScope -ZoneName "abc.com" -Name "LocalScope" Add-DnsServerResourceRecordA -Name "host1" -ZoneName "abc.com" \` -ZoneScope "LocalScope" -IPv4Address "192.168.1.100"
  2. Définir une politique de résolution
    Add-DnsServerQueryResolutionPolicy ` -Name "ForwardAllExceptHost1" -Action ALLOW ` -ServerInterfaceIP "EQ,ANY" ` -Fqdn "NE,host1.abc.com" ` -ZoneScope "ForwarderScope,1" -ZoneName "abc.com" La condition Fqdn "NE,host1.abc.com" (« not equal ») fait basculer toutes les requêtes autres que host1.abc.com dans le scope ForwarderScope, lequel reste configuré pour le transfert.

Schéma récapitulatif du flux

(Illustration textuelle pour WordPress ; remplacez par votre propre diagramme si nécessaire.)

Client ➜ DNS Windows
           ├─ requête "host1.abc.com" ─► ZoneScope LocalScope ─► 192.168.1.100
           └─ requête *.abc.com        ─► ZoneScope ForwarderScope ─► redirecteur externe

Bonnes pratiques spécifiques aux DNS Policies

  • Sauvegardez la configuration après chaque modification : Export-DnsServerZone -Name "abc.com" -FileName "abc.com-export.dns"
  • Surveillez les journaux : le canal DNS‑Server (Event ID 515/516) signale l’évaluation des policies.
  • Évitez l’empilement de conditions inutile : plus la règle est simple, plus la résolution est rapide.

Dépannage (méthodique !)

1. Valider la résolution côté serveur

Resolve-DnsName host1.abc.com -Server 127.0.0.1
  • Si l’IP retournée est erronée, vérifiez l’existence d’un doublon dans une autre zone ou un fichier hosts local.
  • Si la réponse vient toujours du redirecteur, assurez‑vous que la zone (ou le scope) est bien chargée et qu’aucun TTL résiduel ne perturbe le test.

2. Purger le cache

  • Côté serveur : Clear-DnsServerCache
  • Côté client : ipconfig /flushdns puis nslookup host1.abc.com

3. Analyser les traces réseau

Un netsh trace start capture=yes tracefile=c:\dns.etl suivi d’un netsh trace stop permet d’inspecter le flux si le problème persiste.

Automatiser la création de multiples exceptions

Si vous devez ajouter des dizaines d’hôtes internes (host2, host3, …) en méthode zone enfant, un petit script PowerShell accélère le déploiement :

$entries = @{
    "host2.abc.com" = "192.168.1.101"
    "host3.abc.com" = "192.168.1.102"
}

foreach (\$fqdn in \$entries.Keys) {
\$ip = \$entries\[\$fqdn]
Add-DnsServerPrimaryZone -Name \$fqdn -ZoneFile "\$(\$fqdn).dns" -ErrorAction SilentlyContinue
Add-DnsServerResourceRecordA -Name "@" -ZoneName \$fqdn -IPv4Address \$ip -AgeRecord
}

Pensez à journaliser (-PassThru | Out-File) pour garder un historique clair des changements.

Sauvegarde et restauration des zones enfant

  1. Sauvegarde :
    Get-DnsServerZone | Where-Object {$_.ZoneName -like "*.abc.com" -and $_.IsDsIntegrated -eq $false} | Export-DnsServerZone -Path "D:\zones-backup"
  2. Restauration :
    Import-DnsServerZone -FileName "host1.abc.com.dns" -Directory "D:\zones-backup"

Performance : impact négligeable mais mesurable

Ajouter une zone ou une policy engendre un lookup supplémentaire dans la table interne de Windows DNS (O(1) hash). Sur un contrôleur de domaine hébergeant déjà plusieurs centaines de zones, la latence mesurée reste inférieure à 1 ms par requête, même à 20 000 QPS. Néanmoins :

  • Testez avec dnscmd /statistics avant/après pour vérifier les compteurs RecursionAverageTime.
  • Déployez les policies hors production puis surveillez CPU% via Performance Monitor (DNS Server\Recursive Query Rate).

Sécurité & gouvernance

Isoler un enregistrement dans une zone dédiée représente aussi un contrôle d’accès : en affectant des ACL différentes au fichier de zone enfant, on limite les personnes pouvant modifier cet hôte sensible.

  • Utilisez dnscmd /zoneexport + contrôle de version Git pour tracer toute modification.
  • Mettez en place une Delegated Approval via ITSM avant d’autoriser une création de zone enfant.

Alternatives à proscrire

  • Fichier hosts sur chaque poste : ingérable à grande échelle, pas de mise en cache côté DNS.
  • Zone abc.com complète sans transfert : les changements externes (nouvelles entrées publiques) ne seraient plus résolus.
  • Loopback conditional forwarder : crée des boucles de résolution et charge inutilement le serveur.

Résumé opérationnel rapide

ScénarioMéthode conseilléeVersion mini
1‑5 enregistrements isolés, besoin immédiatZone enfant spécifiqueWindows Server 2003+
Plusieurs exceptions, filtrage par client ou plage horaireDNS Policies + scopesWindows Server 2016+
Zone interne complète avec certaines entrées publiquesSplit‑DNS (zone interne + externe)Toutes

FAQ

Dois‑je redémarrer le service DNS après avoir créé la zone ? Non, les changements de zone sont pris en compte dynamiquement. Un simple flush du cache suffit. Les policies ralentissent‑elles la réplication AD ? Les données de policy résident dans la zone, donc répliquées comme tout objet DNS ; l’impact reste marginal, inférieur au trafic généré par quelques enregistrements SRV. Puis‑je utiliser cette méthode pour IPv6 ? Oui ; remplacez Add-DnsServerResourceRecordA par ...RecordAAAA.

Conclusion

Qu’il s’agisse d’une zone enfant minimaliste ou d’une DNS Policy sophistiquée, Windows Server offre plusieurs leviers pour gérer proprement une exception de nom tout en préservant le forwarding global. Choisissez la solution la plus simple répondant à vos besoins actuels ; vous pourrez toujours migrer vers des policies si votre environnement gagne en complexité. L’essentiel est de documenter, sauvegarder et monitorer chaque changement afin de maintenir une résolution DNS cohérente, performante et sécurisée.

Windows Server
PowerShell DNS Windows Server Forwarding DNS Policies
Sommaire