Sur Windows Server 2016–2022, une panne DNS peut figer le service SNMP : si vos règles de sécurité utilisent des FQDN, le service refuse les requêtes jusqu’à son redémarrage. Voici pourquoi cela arrive, comment le diagnostiquer rapidement et les solutions éprouvées (avec scripts et GPO).
Vue d’ensemble
Lorsque la résolution DNS tombe en panne, SNMP continue de tourner, mais rejette toute requête entrante dont l’autorisation repose sur des FQDN définis dans l’onglet Sécurité (« Accepter les paquets SNMP en provenance de ces hôtes »). Une fois DNS rétabli, le service ne re-résout pas ces noms : il reste verrouillé jusqu’à un redémarrage manuel du service SNMP. Aucune erreur explicite n’apparaît généralement dans l’Observateur d’événements.
Cause technique : au démarrage, le service SNMP charge la liste des hôtes autorisés et met en cache la résolution de chaque FQDN. Il ne réinterroge plus le DNS tant qu’il n’est pas relancé. Il s’agit d’une limitation historique d’un composant considéré comme hérité, pas d’un bogue récent.
Symptômes typiques
- Les collectes SNMP depuis vos NMS/NOC (Zabbix, Centreon, SolarWinds, etc.) échouent soudainement (timeouts), alors que le serveur répond au ping.
- Le service
SNMPest Running (Get-Service snmp) et les ports UDP 161/162 sont ouverts, mais aucune réponse SNMP n’est renvoyée. - Les règles de l’onglet Sécurité utilisent des FQDN (ex.
nms01.corp.local). - Événements DNS client « Name resolution for the name … timed out » (ID 1014) pendant l’incident, mais pas d’erreur SNMP explicite.
- Un redémarrage du service (
Restart-Service snmpou via Services.msc) rétablit immédiatement la collecte.
Pourquoi cela arrive (en détail)
Le service SNMP de Windows (v1/v2c) évalue l’accès sur la base de :
- Communautés (community strings) : clé en clair v1/v2c.
- Liste d’hôtes autorisés (PermittedManagers) : FQDN ou adresses IP.
Au lancement, il résout chaque FQDN en adresse IP et conserve ce mapping en mémoire. S’il perd la résolution DNS, il ne recalcule pas les mappings lorsque le DNS revient ; il faut relancer le service pour recharger la liste et refaire les résolutions. Cette conception statique est cohérente avec le statut « fonctionnalité héritée » de SNMP sur Windows.
Diagnostic éclair (5 minutes)
| Vérification | Commande | Interprétation |
|---|---|---|
| État du service SNMP | Get-Service snmp sc.exe query snmp | Doit être Running. S’il l’est mais que la collecte échoue, suspectez la cache FQDN figée. |
| Entrées autorisées | # Communautés reg query HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities # Hôtes autorisés reg query HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\PermittedManagers | Présence de FQDN ? Si oui, forte probabilité d’être affecté par le problème décrit. |
| Résolution DNS | Resolve-DnsName nms01.corp.local Get-WinEvent -LogName "Microsoft-Windows-DNS Client/Operational" | ? Id -eq 1014 | Select -First 5 | Confirme l’incident DNS (ID 1014) et l’état de la résolution après retour à la normale. |
| Test rapide de rétablissement | Restart-Service -Name snmp -Force | Si la collecte repart, le diagnostic « cache FQDN non rafraîchi » est validé. |
Options de remédiation (vue synthétique)
| Option | Description | Avantages | Inconvénients | Commandes / pistes concrètes |
|---|---|---|---|---|
| Remplacer les FQDN par des adresses IP | Configurer les restrictions SNMP avec des IP statiques (ou mieux : contrôler par pare‑feu Windows une plage d’IP autorisées). | Supprime toute dépendance au DNS. | Moins souple si les IP changent ; maintenance manuelle. | GUI SNMP → Sécurité. Pare‑feu : netsh advfirewall firewall add rule name="SNMP Allow NMS" dir=in action=allow protocol=UDP localport=161 remoteip=10.10.50.0/24 |
| Automatiser le redémarrage du service | Tâche planifiée déclenchée par un événement DNS (ex. ID 1014) qui redémarre snmp après retour de la résolution. | Conserve les FQDN ; rétablissement sans intervention. | Très bref temps mort (< 2 s) pendant le restart. | Restart-Service -Name snmp -Force (voir tutoriel plus bas) |
| Allonger le TTL DNS | Augmenter le TTL des enregistrements A/AAAA utilisés par SNMP pour limiter l’expiration en cas de micro‑coupure. | Réduit la fréquence d’incidents. | N’aide pas si la panne dépasse le TTL ; n’élimine pas la limitation SNMP. | Ex. (DNS Windows) ajuster le TTL du RR correspondant. |
| Appliquer les derniers correctifs Windows | Tenir à jour la pile réseau et le composant SNMP. | Écarte des bugs adjacents. | Ne modifie pas la conception de cache du service. | Install-WindowsUpdate (WSUS/sconfig) Get-WindowsUpdateLog |
| Surveiller proactivement DNS & SNMP | Alertes dès qu’un test SNMP échoue ou qu’un événement DNS critique survient. | Détection rapide, MTTR réduit. | Ajoute une brique de supervision / règles. | SCOM, Zabbix, règles WMI/PowerShell ; voir exemples ci‑dessous. |
| Migrer vers des alternatives modernes | Remplacer SNMP v1/v2c (hérité) par WMI/CIM, WinRM/PowerShell Remoting, ou un agent SNMPv3 tiers. | Sécurité forte (auth + chiffrement), pérennité. | Projet de migration, parfois licences. | Exemples : agents SNMPv3 tiers, ou bascule vers CIM (PowerShell). |
Important : l’interface « Accepter les paquets SNMP en provenance de ces hôtes » n’accepte pas la notation réseau (CIDR) de type 10.10.50.0/24. Pour autoriser une plage, utilisez Windows Defender Firewall (champ « Adresses IP distantes ») ou regénérez une liste d’IP via GPO/Script.
Tutoriel : Option 1 (supprimer la dépendance DNS)
Contrôler par le pare‑feu Windows
- Dans Windows Defender Firewall avec fonctions avancées de sécurité, créez une règle entrante UDP 161 (et 162 si vous recevez des traps).
- Port local :
161(et162pour les traps). Port distant : Any. - Portée → Adresses IP distantes : ajoutez les IP/plages de vos NMS (ex.
10.10.50.0/24,2001:db8::/64). - Action : Autoriser la connexion (et limitez aux profils réseau pertinents).
- Dans le service SNMP, cochez « Accepter les paquets SNMP depuis n’importe quel hôte » pour éviter le contrôle redondant côté service. L’accès est alors entièrement piloté par le pare‑feu (et n’est plus sensible à DNS).
En script :
netsh advfirewall firewall add rule name="SNMP Allow from NMS (UDP 161)" dir=in action=allow protocol=UDP localport=161 remoteip=10.10.50.0/24
netsh advfirewall firewall add rule name="SNMP Traps from NMS (UDP 162)" dir=in action=allow protocol=UDP localport=162 remoteip=10.10.50.0/24Paramétrer par GPO (SNMP & Firewall)
- GPO SNMP : Computer Configuration → Policies → Administrative Templates → Network → SNMP :
- « Specify permitted managers » : renseignez uniquement des IP.
- « Specify community name » : définissez la/les communautés et leurs droits (Readonly recommandé).
- GPO Pare‑feu : Computer Configuration → Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security : créez des règles entrantes UDP 161/162 avec la Portée (plages IP).
Tutoriel : Option 2 (redémarrage automatique après panne DNS)
Principe : détecter une panne de résolution (événement 1014), attendre le retour du DNS, puis redémarrer snmp. Le script ci‑dessous est idempotent et journalise l’action.
Script PowerShell (%ProgramData%\SNMP\Restart-SNMP-After-DNS.ps1)
#requires -Version 5.1
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
$LogSource = 'SNMP-AutoRestart'
if (-not [System.Diagnostics.EventLog]::SourceExists($LogSource)) {
New-EventLog -LogName Application -Source $LogSource | Out-Null
}
# Récupère les hôtes autorisés (registry) et filtre les FQDN
$regPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\PermittedManagers'
$fqdns = @()
if (Test-Path $regPath) {
$key = Get-Item -Path $regPath
foreach ($name in $key.GetValueNames()) {
if ($name -ne '(Default)') {
$val = [string]$key.GetValue($name)
# Détecte si ce n'est PAS une IP (donc probablement un FQDN)
$isIp = [System.Net.IPAddress]::TryParse($val, [ref]([System.Net.IPAddress]::Any))
if (-not $isIp -and $val) { $fqdns += $val }
}
}
}
# Si aucun FQDN n'est utilisé, on s'assure que DNS revient, puis on sort proprement.
$timeoutSec = 180
$deadline = (Get-Date).AddSeconds($timeoutSec)
function Test-DnsHealthy {
param([string[]]$Names)
if (-not $Names -or $Names.Count -eq 0) {
# sans FQDN, on teste la racine du resolver sur un nom public robuste
$Names = @('microsoft.com','windowsupdate.com')
}
foreach ($n in $Names) {
try {
Resolve-DnsName -Name $n -ErrorAction Stop | Out-Null
} catch {
return $false
}
}
return $true
}
Start-Sleep -Seconds 10 # backoff court après l'événement
while (-not (Test-DnsHealthy -Names $fqdns)) {
if (Get-Date -gt $deadline) {
Write-EventLog -LogName Application -Source $LogSource -EntryType Warning -EventId 5000 `
-Message "DNS pas stable après ${timeoutSec}s ; abandon du redémarrage SNMP."
exit 0
}
Start-Sleep -Seconds 5
}
# Redémarre SNMP proprement
try {
Restart-Service -Name snmp -Force -ErrorAction Stop
Write-EventLog -LogName Application -Source $LogSource -EntryType Information -EventId 5001 ` -Message "SNMP redémarré automatiquement après rétablissement DNS."
} catch {
Write-EventLog -LogName Application -Source $LogSource -EntryType Error -EventId 5002`
-Message "Échec du redémarrage SNMP: $($_.Exception.Message)"
exit 1
}Créer la tâche planifiée (déclencheur : événement DNS 1014)
- Créez le dossier et le script :
mkdir -Force "C:\ProgramData\SNMP" notepad "C:\ProgramData\SNMP\Restart-SNMP-After-DNS.ps1" - Créez une tâche ONEVENT lancée par SYSTEM :
schtasks /create /tn "\Ops\Restart SNMP on DNS Error" /ru SYSTEM /sc ONEVENT ^ /ec "Microsoft-Windows-DNS Client/Operational" ^ /mo "*[System[(EventID=1014)]]" ^ /tr "powershell.exe -NoProfile -ExecutionPolicy Bypass -File \"C:\ProgramData\SNMP\Restart-SNMP-After-DNS.ps1\"" - (Optionnel) Ajoutez un second déclencheur lors du retour réseau pour robustesse :
schtasks /create /tn "\Ops\Restart SNMP on Network Up" /ru SYSTEM /sc ONEVENT ^ /ec "Microsoft-Windows-NetworkProfile/Operational" ^ /mo "*[System[(EventID=10000)]]" ^ /tr "powershell.exe -NoProfile -ExecutionPolicy Bypass -File \"C:\ProgramData\SNMP\Restart-SNMP-After-DNS.ps1\""
Dans les environnements bruyants (beaucoup d’événements 1014), le backoff et l’attente de résolution intégrés au script évitent les redémarrages inutiles.
Option 3 : augmenter le TTL des enregistrements DNS
Relevez le TTL des A/AAAA des hôtes utilisés par SNMP (ex. NMS) pour qu’une micro‑panne n’expire pas aussitôt le cache. Exemple sur un serveur DNS Windows (simplifié) :
# Exemple conceptuel : ajuster le TTL lors de la mise à jour du RR
# (Adapter à votre environnement et à l'objet RR retourné par Get-DnsServerResourceRecord)
$ttl = New-TimeSpan -Hours 24
# Set-DnsServerResourceRecord -NewData <...> -TimeToLive $ttlCette mesure réduit la probabilité d’incident mais ne corrige pas la conception côté SNMP.
Option 4 : tenir le système à jour
Maintenez Windows Server à jour (mises à jour cumulatives, pilotes réseau, pile TCP/IP). Le composant SNMP restant « hérité », cela n’introduit pas le re‑résolveur, mais limite d’autres effets de bords.
Option 5 : supervision proactive (exemples)
- Sonde SNMP synthétique depuis votre NMS : interroger
sysUpTime.0toutes les minutes. Si > N échecs, alerter. - Alerte Windows :
Get-WinEvent -LogName "Microsoft-Windows-DNS Client/Operational" | ? Id -eq 1014 | Where TimeCreated -gt (Get-Date).AddMinutes(-10)et création d’un Task correctif pointant vers le script ci‑dessus. - SCOM/Zabbix : règle qui écoute l’événement 1014 et lance une récupération automatique.
Option 6 : envisager la modernisation
Le service SNMP natif Windows ne supporte pas SNMPv3 (authentification/chiffrement). Deux voies courantes :
- Remplacer SNMP par CIM/WMI : accès sécurisé via WinRM/HTTPS, contrôles RBAC, chiffrement TLS.
- Déployer un agent SNMPv3 tiers : maintenu, avec re‑résolution dynamique et sécurité renforcée. Définissez un plan de migration progressive (double publication SNMP le temps de la bascule).
Procédure de test/reproduction en labo
- Dans l’onglet Sécurité de SNMP, ajoutez un FQDN dans « Accepter les paquets SNMP… », redémarrez
snmp. - Simulez une panne DNS (ex. blocage UDP 53 ou arrêt de la VM DNS du labo).
- Constater l’échec des requêtes SNMP depuis le NMS.
- Rétablir DNS : les requêtes continuent d’échouer.
Restart-Service snmp: tout repart.
Bonnes pratiques et aspects sécurité
- Éviter les FQDN dans les PermittedManagers : préférez IP + pare‑feu (le plus robuste).
- Limiter par réseau côté pare‑feu (IPv4 & IPv6), pas dans SNMP (pas de CIDR).
- Communautés en lecture seule (readonly) et spécifiques par environnement (PROD/PRÉ‑PROD).
- NAT/Proxy : l’IP vue par le serveur est souvent l’IP NATée du collecteur ; autorisez cette IP.
- Traps (UDP 162) : si vous en émettez, ajustez aussi vos règles pare‑feu sortantes et destinations autorisées.
- Résilience DNS : au moins deux résolveurs différents par serveur, sur sous‑réseaux/locations distincts.
FAQ express
Un redémarrage du service SNMP coupe‑t‑il la production ?
Le restart du service est très bref (typiquement < 2 s) et n’impacte pas les autres rôles. Les pollings en cours peuvent échouer mais les cycles suivants réussissent.
Pourquoi ne pas utiliser des sous‑réseaux directement dans SNMP ?
Le service n’accepte qu’une liste d’hôtes (FQDN/IP). La portée réseau se gère mieux au pare‑feu, qui comprend CIDR/ranges.
Y a‑t‑il un journal d’erreur côté SNMP ?
Généralement non. Appuyez‑vous sur les journaux DNS client, les tests réseau et la preuve par redémarrage.
Une mise à jour résout‑elle définitivement le problème ?
Non : c’est une caractéristique de conception. Les mises à jour améliorent la fiabilité globale, mais le re‑résolveur dynamique n’est pas introduit.
Checklist opérationnelle
- Inventorier les serveurs avec SNMP activé et repérer ceux qui utilisent des FQDN en PermittedManagers.
- Choisir la stratégie : (A) IP+Pare‑feu, (B) restart automatisé, (C) les deux.
- Mettre en place la règle pare‑feu UDP 161/162 (portée IP précise, IPv4/IPv6).
- Si option (B) : déployer le script et la tâche ONEVENT, puis tester.
- Documenter le temps d’arrêt attendu (< 2 s) et prévenir les équipes de supervision.
- Planifier la modernisation (WMI/CIM ou agent SNMPv3) à moyen terme.
Annexes : snippets utiles
Afficher la configuration SNMP (communautés et hôtes)
# Communautés (noms et droits)
reg query HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities
# Hôtes autorisés (FQDN/IP)
reg query HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\PermittedManagersActiver SNMP (Serveur 2016–2022)
# Installation par rôle/fonctionnalité
Install-WindowsFeature SNMP-Service -IncludeManagementTools
# Démarrage et démarrage auto
Set-Service snmp -StartupType Automatic
Start-Service snmpJournaliser une action de redémarrage
$src='SNMP-AutoRestart'
if (-not [System.Diagnostics.EventLog]::SourceExists($src)) { New-EventLog -LogName Application -Source $src }
Write-EventLog -LogName Application -Source $src -EntryType Information -EventId 5001 -Message 'Redémarrage SNMP déclenché'Conclusion
Le comportement « SNMP figé après panne DNS » sur Windows Server 2016–2022 provient d’une cache de résolutions FQDN non rafraîchie entre deux redémarrages du service. La voie la plus robuste consiste à supprimer la dépendance DNS dans le contrôle d’accès (IP + pare‑feu) ou, à défaut, à automatiser un redémarrage intelligent du service piloté par les journaux DNS. Les autres mesures (TTL, correctifs, supervision) améliorent la résilience, mais n’éliminent pas entièrement la limitation de conception du service SNMP.
Informations complémentaires utiles
- Limitation confirmée : la liste d’hôtes autorisés est résolue au démarrage du service et conservée en mémoire.
- Impact sécurité : éviter les FQDN limite le risque de détournement par empoisonnement DNS ; privilégiez IP + pare‑feu ou SNMPv3 via agent tiers.
- Temps d’arrêt : un
Restart-Service snmpprend typiquement moins de deux secondes. - Bonnes pratiques réseau : si les IP changent (DHCP/SDN), couplez l’option IP avec des réservations DHCP ou un pool statique.