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é.
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 : WinRM activé et HTTPS recommandé
# Côté poste d'admin :
$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
& '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.exeest présent danshrSWRunTable(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/tcpTablesi 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/udpOutDatagramsettcpCurrEstabsi 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.32renvoie 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)) > seuilETrate(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% > 5% pendant 10 min, et charge >= 100 réponses/s
if rate(totalResponses, 10m) >= 100 and (rate(nxDomain, 10m) / rate(totalResponses, 10m)) * 100 > 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.