DNSSEC et redirecteurs Windows Server : corriger les erreurs SERVFAIL dues aux ancres de confiance obsolètes

Vous rencontrez des SERVFAIL avec un DNS Windows Server 2019/2022 lorsque DNSSEC et des redirecteurs sont activés ? Voici une analyse approfondie, la cause réelle (ancres de confiance obsolètes) et une procédure fiable pour rétablir une résolution saine.

Sommaire

Contexte et périmètre

Sur Windows Server (2019 et 2022), on observe des échecs de résolution (code SERVFAIL) lorsque le rôle DNS est configuré en même temps avec la validation DNSSEC et un ou plusieurs redirecteurs (par ex. 8.8.8.8, 1.1.1.1, 9.9.9.9). Le comportement problématique touche notamment des noms situés sous des domaines non signés — exemple représentatif : xwkm5qky.r.eu-west-1.awstrack.me.

Symptômes typiques côté client et côté serveur

Les clients reçoivent des réponses SERVFAIL pour certains noms, pas pour tous.
Les noms incriminés résident sous des zones non signées (aucune chaîne de confiance complète jusqu’à la racine).
Sans redirecteur, le même serveur DNS répond correctement ; avec redirecteur, SERVFAIL réapparaît.

# Exemple côté client
Resolve-DnsName xwkm5qky.r.eu-west-1.awstrack.me -Server &lt;IP_DNS_Windows&gt; -DnssecOk

# Sortie typique
# Resolve-DnsName : xwkm5qky.r.eu-west-1.awstrack.me : SERVFAIL

Ce qui se passe réellement sur le fil

Un examen des échanges réseau met en évidence :

Le serveur interroge des enregistrements DS pour plusieurs sous‑zones.
Avec redirecteur, il omet les parents me et awstrack.me dans la chaîne et suppose à tort que la zone descendante est signée.
Il reçoit des réponses NSEC3 indiquant « insecure », mais ne dispose pas de la preuve attendue et conclut à une signature invalide → SERVFAIL.
Sans redirecteur, il remonte correctement jusqu’à awstrack.me, constate l’absence de signature et retourne une réponse valide non signée.

Lecture simplifiée de la chaîne de confiance
Avec redirecteur : les requêtes DS ne couvrent pas les parents requis → hypothèse « zone signée » → incohérence NSEC3 → SERVFAIL.
Sans redirecteur : remontée complète → parent non signé établi → réponse valide (non signée).

Diagnostic terrain pas à pas

Avant toute action, vérifiez que le serveur est récursif et que la validation DNSSEC est activée.

# Afficher les paramètres importants
Get-DnsServerSetting -All | Select-Object ListenAddresses,NoRecursion,EnableDnsSec

# Liste des redirecteurs configurés

Get-DnsServerForwarder

Ensuite, ciblez un nom problématique (ex. xwkm5qky.r.eu-west-1.awstrack.me) :

# Test de résolution avec indicateur DNSSEC
Resolve-DnsName xwkm5qky.r.eu-west-1.awstrack.me -Server &lt;IP_DNS_Windows&gt; -DnssecOk -Type A -Detailed

Inspectez l’état des ancres de confiance :

# Affiche l'ancre de confiance racine (KSK)
Get-DnsServerTrustAnchor -Name .

Un symptôme révélateur : l’ancre de confiance . remonte un statut Bogus ou un état non valide alors que la validation globale est activée.

Cause racine

Le dysfonctionnement provient d’ancres de confiance (trust anchors) obsolètes ou marquées « BOGUS » dans le cache DNS du serveur. En présence de redirecteurs, ces enregistrements ne sont pas rafraîchis comme attendu ; le serveur reste persuadé que la zone descendante doit être signée, ce qui rompt la logique de validation lorsque le parent n’est pas signé.

Solution opérationnelle et fiable

Supprimez l’ancre racine pour forcer une reconstruction propre de la chaîne de confiance. Procédure recommandée :

Étape 1 : sauvegarder l’état actuel (facultatif mais conseillé)

# Sauvegarde rapide de l'ancre racine (représentation JSON)
Get-DnsServerTrustAnchor -Name . | ConvertTo-Json -Depth 5 | Out-File C:\Temp\ta-root-backup.json -Encoding UTF8

Étape 2 : supprimer l’ancre de confiance racine

Get-DnsServerTrustAnchor -Name . | Remove-DnsServerTrustAnchor -Force

Étape 3 : vider le cache DNS et/ou redémarrer le service

# Vider le cache
Clear-DnsServerCache -Force

# OU redémarrer le service DNS

Restart-Service -Name DNS -Force

Étape 4 : rejouer vos tests

Resolve-DnsName xwkm5qky.r.eu-west-1.awstrack.me -Server &lt;IP_DNS_Windows&gt; -DnssecOk -Type A -Detailed

À ce stade, la résolution revient à la normale, y compris avec redirecteurs et validation DNSSEC activés.

Vérifications post‑remédiation

Échantillon de noms : testez un lot de noms auparavant défaillants et un lot réputé sains (ex. domaines signés bien connus).
Latence : chronométrez la première résolution (miss cache) puis la seconde (hit cache).
Journal DNS : surveillez l’absence de nouveaux événements de validation erronée.

# Exemple d’automatisation de test
$names = @(
  "xwkm5qky.r.eu-west-1.awstrack.me",
  "www.microsoft.com",
  "www.cloudflare.com",
  "example.com"
)
$server = "&lt;IP_DNS_Windows&gt;"

$names | ForEach-Object {
  try {
    $r = Resolve-DnsName $_ -Server $server -DnssecOk -Type A -ErrorAction Stop
    [PSCustomObject]@{
      Name     = $_
      Status   = "OK"
      AnswerIP = ($r | Where-Object {$_.QueryType -eq "A"}).IPAddress -join ","
    }
  } catch {
    [PSCustomObject]@{
      Name     = $_
      Status   = "SERVFAIL/ERREUR"
      AnswerIP = $null
    }
  }
} | Format-Table -AutoSize

Option de re‑durcissement : réimporter des ancres de confiance à jour

Dans les environnements où la validation DNSSEC est exigée, réimportez des trust anchors récents (fichier root.key) après avoir assaini l’état du serveur.

# Réimport d'une ancre de confiance depuis un fichier root.key
Import-DnsServerTrustAnchor -File "C:\Chemin\vers\root.key"

# Vérification

Get-DnsServerTrustAnchor -Name . | Format-List \*

Assurez‑vous que le statut est Valid et que les dates/empreintes correspondent à la dernière clé racine attendue.

Pourquoi cette solution fonctionne

La suppression de l’ancre racine « calme » la logique de validation : le serveur abandonne l’état obsolète associé à la clé racine et reconstruit la chaîne de confiance à partir des informations courantes. En l’absence d’une ancre « BOGUS », il peut classifier correctement les zones insecure (non signées) et renvoyer des réponses non signées légitimes au lieu de SERVFAIL.

Alternative : désactiver la validation DNSSEC côté serveur

Si vous n’avez pas besoin de DNSSEC, la manière la plus simple d’éliminer définitivement ce type d’incident est de désactiver la validation pour les réponses distantes.

Via l’interface : Gestionnaire DNS → clic droit sur le serveur → Propriétés → onglet Avancé → décocher « Activer la validation DNSSEC pour les réponses distantes » → OK.
Via PowerShell :

# Désactiver la validation DNSSEC
Set-DnsServerSetting -EnableDnsSec $false

# Vérifier l'état

(Get-DnsServerSetting -All).EnableDnsSec

Cette option est radicale ; ne l’appliquez que si votre politique de sécurité autorise des résolutions insecure.

Cas d’usage et reproduction contrôlée

Pour documenter l’incident et prévenir les régressions, mettez en place un test reproductible.

Activer la validation DNSSEC et configurer un redirecteur public.
Choisir un nom sous un domaine non signé dont la chaîne de délégations est profonde (ex. <host>.<subzone>.awstrack.me).
Capturer le trafic entre le serveur DNS Windows et le redirecteur (filtre udp.port == 53 || tcp.port == 53).
Observer les requêtes DS et NSEC3 : absence de vérification sur awstrack.me, me., puis SERVFAIL.

Checklist d’analyse rapide

Étape	Commande	Résultat attendu
Validation active ?	`(Get-DnsServerSetting -All).EnableDnsSec`	`True` si activée
Redirecteurs	`Get-DnsServerForwarder`	Liste des IP (8.8.8.8, 1.1.1.1, …)
État des ancres	`Get-DnsServerTrustAnchor -Name .`	`Valid` attendu
Test de résolution	`Resolve-DnsName <nom> -DnssecOk`	Réponse A/AAAA/CNAME sans `SERVFAIL`
Purge cache	`Clear-DnsServerCache -Force`	Cache vidé

Bonnes pratiques de prévention

Hygiène des ancres : vérifiez régulièrement l’état ; tout Bogus doit être traité immédiatement.
Contrôles programmés : script de supervision qui consulte Get-DnsServerTrustAnchor et alerte si statut ≠ Valid.
Journalisation : activez le canal « Microsoft‑Windows‑DNS‑Server/Analytical » pour des traces fines lors des investigations.

# Activer/consulter le journal analytique DNS
wevtutil sl "Microsoft-Windows-DNS-Server/Analytical" /e:true
wevtutil qe "Microsoft-Windows-DNS-Server/Analytical" /c:20 /f:text /rd:true

Astuces d’exploitation

Limiter l’impact : si l’incident est en cours de traitement, basculez temporairement vers la récursion directe (sans redirecteur) pour éviter les SERVFAIL côté clients.
Isoler : testez avec un redirecteur différent pour confirmer la dépendance au chemin avec redirecteur.
Documentation : consignez la date de l’incident, la liste des zones affectées et la version précise de Windows Server/KB.

Questions fréquentes

Pourquoi seuls certains noms échouent‑ils ?
Parce qu’ils se situent sous des délégations où Windows déduit (à tort, dans ce contexte) qu’une signature doit exister ; l’absence de preuve côté parent entraîne la validation négative.

Pourquoi l’ajout d’un redirecteur change‑t‑il tout ?
Le code de résolution avec redirecteur modifie la stratégie d’interrogation DS/NSEC3 ; combiné à une ancre « BOGUS », on obtient un biais conduisant à SERVFAIL.

Supprimer l’ancre racine n’est‑il pas risqué ?
Ce n’est pas un abandon de DNSSEC : c’est une remise à zéro d’un état corrompu/obsolète. Ensuite, vous pouvez (et devez, si requis) réimporter une ancre propre (root.key) et valider de nouveau.

Existe‑t‑il un correctif système ?
Au moment du signalement (novembre 2024), aucun correctif cumulatif n’avait été publié. Il est recommandé de surveiller les mises à jour Windows Server/KB pertinentes et de valider en pré‑production.

Modèle de procédure de changement

Pré‑checks : état DNS, fenêtrage maintenance, sauvegarde de l’ancre existante.
Actions : suppression ancre racine → purge cache → redémarrage service (si nécessaire) → tests.
Post‑checks : statut Valid des ancres (si réimportées), absence d’événements d’erreur, métriques de succès de résolution.
Rollback : réimporter le root.key sauvegardé/validé et restaurer la configuration d’origine.

Pièges à éviter

Modifier la zone publique : inutile (et impossible) d’« ajouter » des DS côté tiers pour contourner SERVFAIL ; le souci est local au résolveur.
Forcer des entrées collantes : éviter d’injecter des enregistrements statiques pour masquer le problème ; vous créeriez des incohérences.
Confondre cache client et cache serveur : le ipconfig /flushdns côté client ne corrige pas un état « BOGUS » côté serveur.

Conclusion

Les SERVFAIL observés sur Windows Server DNS, lorsque DNSSEC et des redirecteurs coexistent, sont le plus souvent dus à des ancres de confiance corrompues/obsolètes. La remise à zéro de l’ancre racine, suivie d’un nettoyage du cache et d’éventuels tests de réimport (root.key), rétablit une politique de résolution saine, y compris pour des domaines non signés comme awstrack.me. Si DNSSEC n’est pas requis, la désactivation de la validation côté serveur est une alternative pragmatique qui élimine définitivement cette classe d’erreurs.

Annexe : récapitulatif commandes utiles

# Voir si la validation est active
(Get-DnsServerSetting -All).EnableDnsSec

# Lister/contrôler les redirecteurs

Get-DnsServerForwarder

# État des ancres de confiance

Get-DnsServerTrustAnchor -Name .

# Suppression ancre racine (contournement fiable)

Get-DnsServerTrustAnchor -Name . | Remove-DnsServerTrustAnchor -Force

# Purge cache serveur

Clear-DnsServerCache -Force

# Redémarrage service DNS

Restart-Service DNS

# Réimporter un root.key validé

Import-DnsServerTrustAnchor -File "C:\Chemin\vers\root.key"

Scénario	Action	Effet attendu
SERVFAIL sélectif sur domaines non signés	Supprimer ancre racine + purge cache	Résolution rétablie (réponses non signées légitimes)
Environnement exigeant DNSSEC	Réimporter `root.key` à jour	Ancres `Valid` et validation opérationnelle
Aucun besoin de DNSSEC	Désactiver la validation	Plus d’échec lié à la validation

Note : consignez systématiquement la date, la version de Windows Server, la configuration des redirecteurs et l’état des ancres avant/après. Ces éléments accélèrent l’analyse lors de futures investigations.

DNSSEC et redirecteurs Windows Server : corriger les erreurs SERVFAIL dues aux ancres de confiance obsolètes