Supervision DNS Windows via SNMP : pourquoi DNS‑SERVER‑MIB échoue (NXDOMAIN) et quelles alternatives fiables

Vous interrogez un serveur DNS Windows par SNMP et les OID du DNS‑SERVER‑MIB renvoient « No Such Object » ? Ce guide explique clairement pourquoi, et propose des méthodes éprouvées pour superviser DNS Windows sans vous battre avec un MIB… qui n’est pas implémenté.

Sommaire

Vue d’ensemble du problème

Dans de nombreux environnements, un NMS (Network Management System) interroge les serveurs via SNMP pour collecter des compteurs. Pour le rôle DNS Windows, il est tentant de viser la branche mib‑2.32 dite DNS‑SERVER‑MIB (par exemple l’OID 1.3.6.1.2.1.32.1.1.3.2, souvent associé aux réponses « no such name »/NXDOMAIN). Pourtant, la réponse est systématique : No Such Object.

Diagnostic : le service SNMP de Microsoft n’expose pas le module DNS‑SERVER‑MIB. Il propose par défaut MIB‑II, Host‑Resources‑MIB et LAN Manager MIB‑II (éventuellement DHCP/WINS si ces rôles et modules sont présents), mais aucun MIB DNS. De plus, SNMP est déprécié côté Windows Server depuis longtemps ; la couverture fonctionnelle n’évolue plus.

Conséquence directe

Vous n’avez rien oublié dans la configuration : sur Windows, les OID du DNS‑SERVER‑MIB ne peuvent pas répondre.
Le message No Such Object sur 1.3.6.1.2.1.32.* est attendu et signifie : « cet objet n’existe pas dans l’agent ».
Pour DNS Windows, il faut choisir une autre voie pour collecter les métriques (PowerShell/WMI/PerfMon, agent tiers, exporters modernes).

Rappel utile : lire correctement les erreurs SNMP

No Such Object : la branche/OID n’est pas implémentée dans l’agent.
No Such Instance : le MIB existe, mais l’instance (index) demandée n’existe pas.
End of MIB View : fin des objets disponibles dans le contexte de la requête.

Dans notre cas, il s’agit bien d’un No Such Object : le DNS‑SERVER‑MIB est absent.

Ce que l’agent SNMP Windows expose réellement

Sans ajout tiers, voici la carte d’identité SNMP du serveur Windows :

Famille MIB	Branche OID	Exemples d’objets	État	Remarques
MIB‑II (RFC 1213)	`1.3.6.1.2.1`	`system`, `interfaces`, `ip`, `tcp`, `udp`	Implémenté	Par ex. `sysName`, `ifTable`, `udpTable`
Host‑Resources‑MIB (RFC 2790)	`1.3.6.1.2.1.25`	`hrSystem`, `hrSWRunTable`, `hrStorage`	Implémenté	Permet de voir les processus (`dns.exe`), CPU, mémoire, volumes
LAN Manager MIB‑II	`1.3.6.1.4.1.77`	Comptes/partages historiques	Implémenté	Peu utilisé aujourd’hui
DNS‑SERVER‑MIB	`1.3.6.1.2.1.32`	Compteurs DNS (NXDOMAIN, SERVFAIL, etc.)	Non	Absent de l’agent Microsoft

Options de supervision qui fonctionnent (et lesquelles choisir)

Option A — PowerShell / WMI / WinRM (recommandé)

Le rôle DNS sur Windows expose des métriques complètes via PowerShell. Le cmdlet Get-DnsServerStatistics retourne, entre autres, les erreurs NxDomain, ServFail, Refused, les volumes de requêtes/réponses, la distribution UDP/TCP, et des statistiques par zone.

Exemples de commandes

# Statistiques globales (sur le serveur local)
Get-DnsServerStatistics | Format-List *

# Erreurs principales seulement

\$stats = Get-DnsServerStatistics
\$stats.ErrorStatistics | Format-List

# Extraction de quelques compteurs pour ingestion dans un NMS

\$stats = Get-DnsServerStatistics
\[pscustomobject]@{
Timestamp   = (Get-Date).ToString("s")
NxDomain    = \$stats.ErrorStatistics.NxDomain
ServFail    = \$stats.ErrorStatistics.ServerFailure
Refused     = \$stats.ErrorStatistics.Refused
FormErr     = \$stats.ErrorStatistics.FormatError
TotalQuery  = \$stats.QueryStatistics.TotalQueries
UdpQuery    = \$stats.QueryStatistics.UdpQueries
TcpQuery    = \$stats.QueryStatistics.TcpQueries
RespSent    = \$stats.ResponseStatistics.TotalResponses
} | ConvertTo-Json -Compress

Sur un serveur distant :

# Prérequis côté cible&nbsp;: WinRM activé et HTTPS recommandé
# Côté poste d'admin&nbsp;:
$session = New-PSSession -ComputerName DNS01 -UseSSL
Invoke-Command -Session $session -ScriptBlock {
  $s = Get-DnsServerStatistics
  [pscustomobject]@{
    NxDomain = $s.ErrorStatistics.NxDomain
    ServFail = $s.ErrorStatistics.ServerFailure
    Refused  = $s.ErrorStatistics.Refused
    TotalQ   = $s.QueryStatistics.TotalQueries
  }
}
Remove-PSSession $session

Bonnes pratiques de sécurité

Privilégiez WinRM sur HTTPS (certificat serveur, canaux chiffrés).
Utilisez des comptes de service à privilèges minimaux (lecture DNS suffit).
Consommer les données via une API d’ingestion ou un agent légitime (ex. un collecteur WMI/WinRM de votre NMS).

Intégration type (ex. Zabbix/Nagios/PRTG/Centreon)

Créez un script PowerShell qui écrit un JSON minimal, puis un item/sonde qui appelle ce script :

# C:\Monitoring\Get-DnsNxDomain.ps1
$s = Get-DnsServerStatistics
$s.ErrorStatistics.NxDomain

Dans votre NMS : ajoutez une commande qui exécute ce script et collecte la valeur retournée (compteur cumulatif). Créez un « calculated item » pour la dérivée par seconde si vous souhaitez un taux (NXDOMAIN/s).

Option B — Compteurs de performance Windows (PerfMon)

L’objet « DNS Server » dans PerfMon expose de nombreux compteurs (requêtes, réponses, mises à jour dynamiques, cache). La plupart des NMS savent interroger PerfMon via WMI ou un agent Windows.

Exemples de compteurs utiles

Catégorie	Nom de compteur (exemple)	Usage typique
Charge	Total Query Received/sec	Tendance charge globale (toutes sources)
Transport	UDP Queries Received/sec / TCP Queries Received/sec	Répartition UDP vs TCP (ex. transferts de zone, grandes réponses)
Réponses	Total Response Sent/sec	Sortant ; corrélé aux requêtes
Recursion	Recursive Queries/sec	Superviser le résolveur (si activé)
Cache	Cache Hits/sec / Cache Misses/sec	Efficacité de cache
Mises à jour	Dynamic Update Received/sec / Rejected/sec	Flux d’updates dynamiques

Les noms exacts peuvent varier légèrement selon la version de Windows Server ; le principe reste identique. Pour les comptes d’erreurs DNS (NXDOMAIN, SERVFAIL…), préférez Get-DnsServerStatistics.

Option C — SNMP impératif ? Utilisez un agent tiers

Si la politique interne impose SNMP pour la télémétrie, installez un agent SNMP tiers qui expose les compteurs PerfMon en SNMP. Le mapping se fait vers des OID privés de l’éditeur. Avantages : intégration SNMP homogène, parfois SNMPv3, pas de dépendance WinRM. Inconvénients : licence éventuelle, OID non standard, maintenance de l’agent.

Option D — Voie moderne : Prometheus + windows_exporter

Le windows_exporter (anciennement wmi_exporter) expose les métriques Windows pour Prometheus. Activez le collector dns pour exporter les statistiques DNS (issues de WMI/PerfMon). Vous récupérez alors des séries time‑series consommables par Prometheus/Grafana, éventuellement reliées à votre NMS via un pont ou des webhooks.

Exemple de lancement de l’exporter (service)

# Exemple : activer quelques collectors dont dns
&amp; 'C:\Program Files\windows_exporter\windows_exporter.exe' `
  --collectors.enabled="dns,logical_disk,net,os,system" `
  --telemetry.addr=":9182"

Définition de job Prometheus

scrape_configs:
  - job_name: 'windows-dns'
    scrape_interval: 30s
    static_configs:
      - targets: ['dns01.corp.local:9182','dns02.corp.local:9182']

Supervision de disponibilité via SNMP malgré tout

Même si les métriques DNS ne sont pas publiées en SNMP standard, vous pouvez contrôler la disponibilité de base via MIB‑II et Host‑Resources‑MIB :

Processus : vérifier que dns.exe est présent dans hrSWRunTable (1.3.6.1.2.1.25.4.2.1). Nom du process : hrSWRunName (…1.2).
Ports : valider l’accessibilité UDP/53 et TCP/53 au niveau réseau (via vos sondes actives ou via udpTable/tcpTable si votre NMS le supporte).

Exemples snmpwalk

# Tenter la branche DNS-SERVER-MIB (échec attendu)
snmpwalk -v2c -c <community> <ip_dns> 1.3.6.1.2.1.32
# > No Such Object

# Rechercher dns.exe dans hrSWRunTable

snmpwalk -v2c -c \ \ 1.3.6.1.2.1.25.4.2.1.2 | grep -i dns.exe

Arbre de décision : quelle méthode pour quel besoin ?

Besoin	Méthode recommandée	Protocole	Avantages	Limites
Toutes les erreurs DNS (NXDOMAIN, SERVFAIL, REFUSED…), débit requêtes/réponses	`Get-DnsServerStatistics` via script	WinRM/PowerShell	Couverture complète, support natif, granularité par zone	Nécessite WinRM (HTTPS conseillé), parsing côté NMS
Charge et IO DNS à haute fréquence	PerfMon « DNS Server »	WMI/Agent	Faible latence, robuste, support NMS large	Pas d’erreurs détaillées (NXDOMAIN…) selon version
Politique SNMP stricte	Agent SNMP tiers (mapping PerfMon → OID)	SNMPv2c/v3	Intégration SNMP homogène, v3 disponible	Coût/licence, OID propriétaires
Observabilité cloud‑native	windows_exporter + Prometheus/Grafana	HTTP/Prometheus	Time‑series, alerting flexible, écosystème riche	Stack supplémentaire à maintenir
Vérification de vie/état	hrSWRunTable + checks réseau	SNMP + TCP/UDP	Simple, fonctionne partout	Pas de métriques DNS métier

Mise en œuvre pas‑à‑pas : collecte via PowerShell

Sécuriser WinRM
- Générer/installer un certificat serveur (émis par votre AC).
- Configurer WinRM pour HTTPS et limiter l’accès réseau (ACL, pare‑feu, bastion).
# Sur le serveur DNS Enable-PSRemoting -Force winrm quickconfig # Basculer en HTTPS (schéma & ports adaptés à votre politique) # Voir "winrm create winrm/config/Listener?Address=*+Transport=HTTPS"
Écrire un collecteur minimal # C:\Monitoring\Collect-DnsStats.ps1 param( [string]$ComputerName = $env:COMPUTERNAME ) try { $s = Get-DnsServerStatistics -ComputerName $ComputerName -ErrorAction Stop [pscustomobject]@{ host = $ComputerName ts = (Get-Date).ToUniversalTime().ToString("o") nxDomain = $s.ErrorStatistics.NxDomain servFail = $s.ErrorStatistics.ServerFailure refused = $s.ErrorStatistics.Refused formatError = $s.ErrorStatistics.FormatError totalQueries = $s.QueryStatistics.TotalQueries udpQueries = $s.QueryStatistics.UdpQueries tcpQueries = $s.QueryStatistics.TcpQueries totalResponses = $s.ResponseStatistics.TotalResponses } | ConvertTo-Json -Compress } catch { Write-Error $_.Exception.Message exit 2 }
Ingestion dans le NMS
- Configurer un item « exécuter commande » (ou équivalent) qui lance le script.
- Créer des items dérivés (taux/s, pourcentages) et des seuils d’alerte.

Calculs d’indicateurs utiles

À partir des compteurs cumulatifs :

Taux NXDOMAIN (%) = ΔNxDomain / ΔTotalResponses × 100
Taux SERVFAIL (%) = ΔServFail / ΔTotalResponses × 100
Part TCP (%) = ΔTcpQueries / ΔTotalQueries × 100
Cache hit ratio (si exposé) = ΔCacheHits / (ΔCacheHits + ΔCacheMisses)

Supervision via PerfMon : collecte WMI

Vous pouvez interroger les compteurs depuis PowerShell pour validation rapide ou pour les exposer dans votre NMS.

# Exemple : lire quelques compteurs PerfMon DNS
Get-Counter -Counter '\DNS Server\Total Query Received/sec','\DNS Server\UDP Queries Received/sec','\DNS Server\Total Response Sent/sec' -SampleInterval 5 -MaxSamples 3

Pour une collecte continue, appuyez‑vous sur l’agent de votre NMS (sonde WMI/PerfMon) et normalisez les noms de compteurs dans vos modèles.

SNMP tiers : mapping type

Le principe est toujours le même : l’agent lit PerfMon/WMI et expose ensuite des OID propriétaires. Le fournisseur vous livre un fichier MIB privé. Vous rattachez alors les graphes/alertes à ces OID. Vérifiez :

Support SNMPv3 (authPriv) si exigé par la conformité.
Granularité des compteurs DNS (erreurs, cache, recursion, zones).
Politique de mises à jour et charge CPU induite.

Contrôles de santé basés SNMP (sans métriques DNS)

Vérifier le processus `dns.exe` avec Host‑Resources‑MIB

# Lister les noms de processus
snmpwalk -v2c -c <community> <ip_dns> 1.3.6.1.2.1.25.4.2.1.2

# Optionnel : récupérer le chemin du binaire

snmpget  -v2c -c \ \ 1.3.6.1.2.1.25.4.2.1.4.\

Déclenchez une alerte si dns.exe n’est pas trouvé ou si le nombre d’instances chute à 0.

Tester la chaîne réseau

Transport UDP 53 (requêtes usuelles), TCP 53 (zones volumineuses, EDNS0, transferts de zone).
Surveillance active (synthetic) : requête DNS périodique vers le serveur et vérification de la réponse (A/AAAA, reverse, etc.).
Corréler avec udpInDatagrams/udpOutDatagrams et tcpCurrEstab si nécessaire (MIB‑II).

Bonnes pratiques d’exploitation

Comprendre l’effet de cache : une hausse des NXDOMAIN peut être « normale » si des clients tentent des domaines internes/tap‑o‑s.
Surveiller par zone : pour isoler une zone bavarde ou sujette à des erreurs, utilisez Get-DnsServerStatistics -ZoneName <zone> (si pris en charge par votre version).
Échantillonnage : 30 à 60 s suffisent pour la plupart des métriques ; évitez <15 s sauf besoin explicite.
Alertes pragmatiques : privilégiez des seuils relatifs (taux d’erreurs %) vs absolus pour éviter les faux positifs en période creuse.
Journalisation : corrélez avec les journaux DNS (événements, debug si nécessaire) pour l’analyse causale.

FAQ

Q : Puis‑je « activer » le DNS‑SERVER‑MIB sur Windows ?
R : Non. L’agent SNMP Microsoft ne l’implémente pas. Vous pouvez seulement installer un agent tiers qui expose des OID privés mappés sur PerfMon/WMI.

Q : SNMPv3 est‑il possible ?
R : Le service SNMP natif de Windows est limité et considéré comme déprécié. Pour SNMPv3 (authPriv), passez par un agent tiers ou évitez SNMP pour la télémétrie applicative et utilisez WinRM/HTTPS.

Q : Les OID 1.3.6.1.2.1.32.x sont pourtant définis dans les RFC ?
R : Oui, les RFC 1611/1612 normalisent un MIB pour les serveurs DNS. Mais implémentation ≠ obligation : Microsoft n’a pas inclus ce MIB dans son agent.

Q : Quelle différence entre PerfMon et PowerShell pour DNS ?
R : PerfMon offre des compteurs temps réel à haute fréquence (débit, cache, recursion). PowerShell Get-DnsServerStatistics expose en plus des compteurs d’erreurs métier (NXDOMAIN/SERVFAIL/REFUSED). Ils sont complémentaires.

Checklist de déploiement

✅ Confirmer que snmpwalk <server> 1.3.6.1.2.1.32 renvoie No Such Object (attendu).
✅ Choisir la voie de collecte : PowerShell/WMI (recommandé), PerfMon, agent SNMP tiers ou exporter Prometheus.
✅ Sécuriser les canaux (HTTPS pour WinRM, SNMPv3 si agent tiers, filtrage réseau).
✅ Normaliser les métriques (taux/s, pourcentages), définir des seuils pertinents et des dashboards.
✅ Mettre en place des tests actifs DNS (résolution attendue, temps de réponse, reachabilité TCP/UDP 53).
✅ Documenter les procédures d’escalade (hausse NXDOMAIN, récursivité anormale, échecs d’updates dynamiques).

Exemples d’alertes prêtes à l’emploi

NXDOMAIN anormal : alerte si avg_over_5m(rate(NXDOMAIN)) > seuil ET rate(TotalResponses) > 50/s (éviter les faux positifs en période creuse).
ServFail : alerte si ServFail% > 1 % pendant 10 min.
Part TCP : alerte si TCP% > 20 % (hors transferts de zone planifiés) ; peut indiquer des réponses fragmentées/EDNS bloqué.
Mises à jour dynamiques rejetées : détection d’un problème d’ACL/DDNS.
Process DNS absent : hrSWRunName != dns.exe (SNMP) ou service arrêté (WMI/SCM).

Modèles de données (pour un NMS)

Nom logique	Source	Chemin/Commande	Type	Commentaire
dns.nxdomain.total	PowerShell	`(Get-DnsServerStatistics).ErrorStatistics.NxDomain`	Counter	Calculer le taux/s
dns.servfail.total	PowerShell	`(Get-DnsServerStatistics).ErrorStatistics.ServerFailure`	Counter	Calculer le taux/s
dns.query.total	PowerShell	`(Get-DnsServerStatistics).QueryStatistics.TotalQueries`	Counter	Charge entrante
dns.response.total	PowerShell	`(Get-DnsServerStatistics).ResponseStatistics.TotalResponses`	Counter	Sortant
dns.perf.udp_qps	PerfMon	`\DNS Server\UDP Queries Received/sec`	Gauge	Réactivité
dns.perf.tcp_qps	PerfMon	`\DNS Server\TCP Queries Received/sec`	Gauge	Surveiller les gros flux
proc.dns.running	SNMP	`hrSWRunTable → dns.exe`	Boolean	Disponibilité de base

Points d’attention sur l’installation SNMP sous Windows

Le composant « Services SNMP » est déprécié. Il reste installable comme fonctionnalité sur de nombreuses versions, mais la sécurité et la maintenance ne sont plus prioritaires.
SNMP natif est historiquement v1/v2c. Si votre conformité exige SNMPv3 (authPriv), choisissez un agent tiers.
N’ouvrez pas SNMP à tout vent : filtrez par IP, segmentez, consignez.

# Exemple (serveur) : installer la fonctionnalité SNMP si nécessaire
Install-WindowsFeature -Name SNMP-Service -IncludeManagementTools

# Exemple (poste client) : utilitaire snmpwalk (net-snmp) pour tester

snmpwalk -v2c -c \ \ 1.3.6.1.2.1.1 # system

Pourquoi Microsoft n’a pas inclus DNS‑SERVER‑MIB ?

Historiquement, Microsoft a privilégié WMI/PerfMon pour l’observabilité des rôles Windows, puis PowerShell. Avec le temps, SNMP a été mis en maintenance minimale (dépréciation), sans ajout majeur de MIBs applicatifs. DNS n’y fait pas exception. Résultat : l’outillage natif moderne (WMI/PowerShell) est le chemin supporté.

En résumé

Le DNS‑SERVER‑MIB (1.3.6.1.2.1.32) n’est pas implémenté par l’agent SNMP Microsoft ; d’où No Such Object sur les OID DNS (dont NXDOMAIN).
La supervision efficace de DNS Windows passe par PowerShell (Get-DnsServerStatistics) et/ou PerfMon.
Si vous tenez à SNMP, installez un agent tiers (mapping PerfMon → OID, SNMPv3 possible).
En complément, surveillez la disponibilité via Host‑Resources‑MIB (processus dns.exe) et des checks réseau (TCP/UDP 53).
Pensez sécurité (WinRM HTTPS, filtrage SNMP, comptes dédiés) et télémétrie utile (taux d’erreurs, QPS, cache, recursion).

Annexe : commandes de test rapides

# 1) Vérifier que la branche DNS-MIB n'existe pas (No Such Object attendu)
snmpwalk -v2c -c <community> <ip_dns> 1.3.6.1.2.1.32

# 2) Process DNS (hrSWRunTable)

snmpwalk -v2c -c \ \ 1.3.6.1.2.1.25.4.2.1.2 | grep -i dns.exe

# 3) PowerShell : statistiques DNS (local)

Get-DnsServerStatistics | fl \*

# 4) PowerShell : extraire et imprimer NxDomain

(Get-DnsServerStatistics).ErrorStatistics.NxDomain

# 5) PerfMon : lire rapidement 3 échantillons

Get-Counter -Counter '\DNS Server\Total Query Received/sec' -SampleInterval 5 -MaxSamples 3

Modèle d’alerte (pseudo‑langage)

# Alerte si NXDOMAIN% &gt; 5% pendant 10 min, et charge &gt;= 100 réponses/s
if rate(totalResponses, 10m) &gt;= 100 and (rate(nxDomain, 10m) / rate(totalResponses, 10m)) * 100 &gt; 5:
    alert("Anomalie DNS : NXDOMAIN élevé")
    annotate("Corélez avec journaux DNS et récursivité")

Conclusion

Inutile de forcer un carré à entrer dans un rond : sur Windows, le DNS‑SERVER‑MIB n’existe pas côté agent. En revanche, l’écosystème Windows fournit toutes les métriques nécessaires via PowerShell/PerfMon, avec une meilleure granularité et un meilleur support. Adoptez la méthode adaptée à votre contrainte (WinRM, PerfMon, agent SNMP tiers, Prometheus), standardisez vos indicateurs (taux d’erreurs, QPS, cache, recursion) et sécurisez le canal de collecte. Vous obtiendrez une supervision DNS fiable, exploitable, durable—sans dépendre d’un MIB absent.

Supervision DNS Windows via SNMP : pourquoi DNS‑SERVER‑MIB échoue (NXDOMAIN) et quelles alternatives fiables