De quoi s’agit-il ?

Comme son nom l’indique, cet article traite des capacités de journalisation de débogage du serveur DNS Windows. En lisant cet article, vous obtiendrez des informations sur la manière d’obtenir des aperçus des processus de résolution de noms dans votre environnement. Cela peut être très utile pour le dépannage et l’analyse des problèmes liés au DNS. Avant d’entrer dans les détails, comprenons d’abord ce qu’est la journalisation de débogage du serveur DNS et pourquoi cela -parfois- est une chose importante et un outil pratique.

Dans de nombreux cas, le serveur DNS est un rôle sur le contrôleur de domaine dans un environnement Active Directory. Dans tous les cas, le serveur DNS est un composant critique de l’infrastructure réseau. La résolution de noms est omniprésente et constitue une partie fondamentale de la manière dont les ordinateurs communiquent sur un réseau.

Mais que se passe-t-il lorsque quelque chose ne va pas, ou si ce composant critique doit être touché pour une raison quelconque ? Cela peut se produire pour diverses raisons, telles que :

  • Dépannage - Quelqu’un signale des problèmes de résolution de noms. De temps en temps, de mauvaises adresses IP sont renvoyées à un client et une application cesse de fonctionner.
  • Migration et gestion des changements - Les serveurs peuvent devoir être migrés ailleurs. Peut-être vers un nouveau segment de réseau, dans un hyperscaler, ou simplement l’organisation a décidé de transférer le DNS d’Active Directory vers des appareils réseau. Les clients peuvent devoir être reconfigurés à ce stade pour cibler le nouveau serveur DNS.
  • Statistiques et analyse (sécurité) - Qui demande quoi ? Quels types de modèles peuvent être observés ? Quels types de requêtes sont effectuées ? Y a-t-il des activités suspectes ?

Dans de tels cas, avoir des aperçus sur les détails de la résolution de noms peut être inestimable. Cet article essaie de couvrir certaines façons d’obtenir ces aperçus. Juste pour mentionner, en parlant d’un “client DNS”, je veux dire tout appareil qui demande une résolution de noms, comme un poste de travail, un serveur, une imprimante, des appareils d’infrastructure informatique, ou même un appareil IoT.

Capacités pour les aperçus du serveur DNS Windows

Lorsqu’il s’agit de la question “Comment obtenir des informations du serveur DNS ?”, plusieurs options sont disponibles. Décisions, Décisions Jetons un œil aux plus courantes :

Capacité - Capture de paquets réseau

Classique et puissant. Peut-être pas la solution à long terme, mais pour un dépannage rapide ou une analyse en temps réel, c’est totalement précieux. J’en ai parlé dans mon dernier article [Capture de trafic réseau dans Windows][captureNetworkTrafficReference], donc je ne vais pas entrer dans les détails ici.

Capacité - Journalisation du pare-feu

Dans le cas où vous avez une segmentation de votre réseau en place et que vous avez accès aux journaux du pare-feu, vous pouvez obtenir des informations sur qui communique pour le DNS - et tous les autres services - à partir de là. Ce n’est pas l’information la plus détaillée, car elle manque de granularité et de détails spécifiques au service, mais cela peut être utile et un gain rapide si c’est déjà en place. Cela peut ne pas être une option si vous avez des réseaux aplatis, il n’y a probablement pas de pare-feu entre les clients DNS et le serveur DNS. Vous pouvez utiliser le pare-feu Windows local de toute façon, mais comme vous le verrez dans les sections suivantes, il existe de meilleures options dans ce cas. Ensuite, il y a malheureusement le cas prohibitif des “silos organisationnels” et du “manque de communication” entre les équipes, où il peut simplement ne pas être faisable d’obtenir les journaux du pare-feu, même s’ils existent.

Capacité - Journaux d’événements

J’espère que vous avez la configuration des journaux d’événements pour enregistrer Tous les événements en place sur votre serveur DNS. Si ce n’est pas le cas, c’est le moment de le mettre en place, car c’est un bon point de départ pour la journalisation opérationnelle dans votre service DNS Windows.

Ce n’est peut-être pas l’information la plus détaillée, mais cela produit des aperçus de base dans les journaux d’événements Windows classiques.

En plus des journaux d’événements Windows classiques, il existe également quelques journaux d’application spécifiques au serveur DNS. Beaucoup connaissent le journal “Serveur DNS” dans la section “Journaux d’application et de services” de l’Observateur d’événements, mais ils ne sont pas si intéressants pour de réels aperçus sur le service.

Effectivement, il existe deux autres journaux d’événements du serveur DNS disponibles dans la structure des dossiers. Le journal d’audit qui fournit des informations opérationnelles sur le type d’opérations qui se produisent dans le serveur DNS : Journal d’événements d’audit du serveur DNS D’autre part, il existe un journal analytique moins connu qui peut être activé à la demande. Il fournit des informations très détaillées sur les processus de résolution de noms en cours, comme le type de requêtes effectuées, le type de réponses envoyées, et ainsi de suite. Journal d’événements analytiques du serveur DNS Ce journal n’est pas actif par défaut, mais il peut être activé à des fins de dépannage et d’analyse. Malheureusement, autant que je sache, le journal “Analytique” n’est pas capable de se rouler dans plusieurs fichiers, donc il peut être délicat de l’utiliser pour une approche à long terme. Pour un dépannage ou une analyse à court terme, cela peut être un choix.

Capacité - EventTracing

Le traçage d’événements Windows (ETW) est probablement l’option la plus puissante lorsque vous souhaitez plonger dans les internals de Windows. Malheureusement, c’est aussi la plus complexe, et elle n’est pas très conviviale. Je pourrais couvrir ETW explicitement dans un futur article, mais pour l’instant, je ne vais pas entrer dans les détails ici.

Capacité - DebugLogFile

Le serveur DNS Windows dispose également d’une journalisation de débogage intégrée basée sur du texte qui peut être configurée facilement. Cette fonctionnalité vous permet de journaliser les mêmes détails que le journal d’événements “Analytique”, mais elle écrit dans des fichiers texte et fournit des capacités de roulement, ce qui peut être utilisé pour une approche à long terme.

Cela peut être un peu plus convivial que l’ETW, car cela fournit un texte lisible sans avoir besoin de PerfMon et des autres outils ETW. Le format du fichier journal, cependant, n’est pas parfaitement structuré, mais il est tout de même possible de consommer l’information avec un certain effort.of DNS-specific opcodes and flags.

Il existe deux façons d’activer le fichier de journalisation de débogage, soit via l’interface graphique (GUI), soit via PowerShell.

L’interface graphique est “classique Windows”, assez simple, vous pouvez trouver les paramètres dans le Gestionnaire DNS sous la section “Journalisation de débogage” des propriétés du serveur.

Conseil pratique : Si vous avez plus d’un serveur DNS (et je suppose que c’est le cas), il est très judicieux d’utiliser les mêmes paramètres sur tous les serveurs, afin d’obtenir des données cohérentes dans votre environnement.

De plus, je recommande d’inclure le nom du serveur dans le nom du fichier journal, afin de pouvoir facilement identifier la source des données de journalisation.

Même si l’interface graphique semble conviviale et simple, elle présente certains inconvénients et faiblesses. En effet, elle ne fournit pas l’ensemble des options de configuration, et elle n’est pas très évolutive si vous avez plus qu’une petite poignée de serveurs. Par exemple, si vous souhaitez activer le fichier de journalisation de débogage sur 10 serveurs ou plus, vous devez être très concentré pour appliquer les mêmes paramètres et écrire correctement sur tous les serveurs encore et encore. Lorsqu’il s’agit de chiffres supérieurs à quatre, je préfère généralement une approche “Dev-Ops” plutôt qu’une méthode “Click-Ops”.

Mon expérience avec ma propre paresse humaine et mes défauts d’exactitude dans les tâches répétitives m’a obligé à apprendre : PowerShell est la solution

Donc, sans surprise, il existe des cmdlets PowerShell disponibles pour “Obtenir” et “Définir” les paramètres de journalisation de débogage pour le serveur DNS :

# Obtenir les paramètres de journalisation de débogage du serveur DNS
Get-DnsServerDiagnostic

# Définir les paramètres de journalisation de débogage du serveur DNS
Set-DnsServerDiagnostic

La commande Get renvoie toutes les options de l’interface graphique ainsi que quelques options supplémentaires qui ne sont pas disponibles dans l’interface graphique, comme les paramètres de rotation pour le journal et la capacité d’ajouter plus d’informations opérationnelles internes spécifiques au serveur DNS dans le journal de débogage.

Paramètres de journalisation de débogage du serveur DNS via PowerShell

IMPORTANT : Même si la propriété “MaxMBFileSize” peut suggérer que la taille du fichier est définie en Mo, elle est en réalité définie en octets. Donc, si vous souhaitez définir une taille de fichier de 10 Mo, vous devez définir la valeur à 10485760 (10 * 1024 * 1024).

Faites également attention au caractère de fin du nom pour “LogFilePath”!
Parce que je veux avoir de jolis noms de fichiers et que la propriété “EnableLogFileRollover” est activée, le nom du fichier journal se termine par un underscore. Le serveur ajoute un horodatage comme suffixe au nom de fichier fourni lorsqu’il crée le journal. Avec cette approche, j’ai une séparation claire entre le nom des serveurs et l’horodatage.

L’image suivante montre le comportement différent de la propriété “EnableLogFileRollover” sur le nom de fichier :


IMPORTANT : Il est également TRÈS IMPORTANT de comprendre le comportement du processus de rotation. Il n’y a PAS de paramètres de taille de journal global ! Cela signifie que, si la rotation est activée, le serveur crée un nouveau fichier chaque fois que la taille maximale spécifiée MaxMBFileSize est atteinte, mais il n’y a pas de limite au nombre de fichiers pouvant être créés.

Cela signifie que VOUS DEVEZ PRENDRE SOIN DES FICHIERS JOURNAUX et de l’ESPACE DISQUE SUR VOTRE SERVEUR !

Si vous activez le fichier de journalisation de débogage par une approche “set-and-forget”, et que vous avez une charge productive sur votre serveur, vous risquez de remplir votre disque. En fonction du nombre de requêtes et du niveau de détails, cela peut atteindre plusieurs gigaoctets par jour si vous avez beaucoup de clients DNS.

ENCORE UNE FOIS, NE FAITES PAS DE SET-AND-FORGET ICI !

Vous devez avoir votre propre stratégie pour gérer les fichiers journaux. Il n’y a pas de nettoyage automatique.

Voici un exemple de la façon dont vous pouvez activer le fichier de journalisation de débogage via PowerShell :

# Spécifiez les paramètres de journalisation de débogage DNS souhaités
$dnsDebugLogParameter = @{
    "Queries"                              = $true
    "Answers"                              = $true
    "Notifications"                        = $true
    "Update"                               = $true
    "QuestionTransactions"                 = $true
    "UnmatchedResponse"                    = $true
    "SendPackets"                          = $true
    "ReceivePackets"                       = $true
    "TcpPackets"                           = $true
    "UdpPackets"                           = $true
    "FullPackets"                          = $false
    "FilterIPAddressList"                  = $null
    "EventLogLevel"                        = 4
    "UseSystemEventLog"                    = $false
    "EnableLoggingToFile"                  = $true
    "EnableLogFileRollover"                = $true
    "LogFilePath"                          = "C:\Administration\Logs\DNSServer\DnsDebugLog_$($env:COMPUTERNAME).$((Get-CimInstance -ClassName "win32_computersystem").Domain)_.log"
    "MaxMBFileSize"                        = (10 * 1mb)
    "SaveLogsToPersistentStorage"          = $false
    "WriteThrough"                         = $false
    "EnableLoggingForLocalLookupEvent"     = $false
    "EnableLoggingForPluginDllEvent"       = $false
    "EnableLoggingForRecursiveLookupEvent" = $false
    "EnableLoggingForRemoteServerEvent"    = $false
    "EnableLoggingForServerStartStopEvent" = $false
    "EnableLoggingForTombstoneEvent"       = $false
    "EnableLoggingForZoneDataWriteEvent"   = $false
    "EnableLoggingForZoneLoadingEvent"     = $false
}

# Appliquez les paramètres définis
Set-DnsServerDiagnostics @dnsDebugLogParameter

Dans le prochain chapitre, nous examinerons mes idées sur “comment consommer les informations des journaux de débogage générés”. Dans ce chapitre, je fais référence à mon propre module PowerShell [DNSServer.DebugLogParser][dNSServerDebugLogParserDef] pour analyser les fichiers DebugLog créés par le service Windows.
Le module est disponible dans la PowerShell Gallery, et dans mon [compte GitHub][githubProfile]. Le dépôt GitHub contient également [une documentation supplémentaire avec un guide d’utilisation dans un environnement de domaine][dnssLogParserRepository]. Vous y trouverez des scripts à appliquer probablement sur vos serveurs.

En ce qui concerne l’objectif de l’article, je ne vais pas entrer dans plus de détails sur les aspects opérationnels dans un environnement de production probable. J’espère avoir clairement indiqué ci-dessus que vous devez vous soucier de stratégies supplémentaires avant d’activer de tels journaux.

Consommation des données

D’accord, en suivant ce qui précède, vous avez des données sur vos différents serveurs. Cela signifie que vous avez des déchets éparpillés un peu partout. Dans une étape suivante, vous devez vous occuper du processus de consommation des données et probablement les rassembler dans un endroit central.

Il ne sera sûrement pas surprenant pour vous que PowerShell puisse vous aider en cours de route.

Journaux d’événements

Comme mentionné précédemment, le journal d’événements “Analytique” peut être très utile pour un dépannage rapide. Alors que nous parlions du quoi et du pourquoi dans les sections précédentes, voici un exemple pour une session de dépannage rapide. Cela peut être pratique dans une situation où vous devez faire face à des problèmes comme “Hé, ton serveur DNS ne renvoie rien quand je demande ‘xyz’. Qu’est-ce qui se passe !”

Soyez conscient que l’exemple suivant suppose que vous travaillez sur une station de travail d’administration et que vous avez des politiques de pare-feu appropriées en place pour gérer vos serveurs à distance. Si vous travaillez directement sur le serveur, vous pouvez simplement ignorer le paramètre “-ComputerName” dans les commandes ou utiliser le code dans le paramètre “-ScriptBlock” directement.

Tout d’abord, définissons quelques variables, comme le serveur que nous interrogeons :

$Server = "DC01"

Vous pouvez spécifier un ou plusieurs serveurs directement.

Maintenant que nous avons déclaré quels serveurs surveiller, nous pouvons activer le journal analytique sur ces serveurs. Une fois cela fait, attendez un certain temps ou reproduisez le problème, puis désactivez à nouveau le journal.

# Activer le journal analytique
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:true /q
}

# Attendre un certain temps pour rassembler des données

# Désactiver le journal analytique
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:false
}

Dans l’étape suivante, capturez les enregistrements du journal. En fonction de la quantité de données, cela peut prendre un certain temps, alors soyez patient. Après que les événements ont été capturés, il y a du travail à faire pour rendre les données plus utilisables.
J’utilise la propriété Message des enregistrements EventLog pour extraire les détails, car elle a déjà les ValueNames en place. Cependant, il y a aussi la propriété Properties (🤭 en écrivant cela, cela ressemble à 🤪 des trucs de programmation) avec un tableau de toutes les valeurs mais sans PropertyNames en place. Si vous aimez travailler avec la propriété .Properties, vous devez faire un peu plus de travail pour obtenir les valeurs dans un format utilisable, ce qui vous donnera probablement une meilleure cohérence à travers la localisation et les différentes versions de Windows…

# Obtenir les enregistrements EventLog du(x) serveur(s)
$records = Get-WinEvent -ComputerName $Server -LogName "Microsoft-Windows-DNSServer/Analytical" -Oldest | Where-Object Providername -ne ""

# Traiter les enregistrements pour enrichir les données
$propNames = @("MachineName", "LogName", "TimeCreated", "LevelDisplayName", "RecordId", "Message", "ProviderName", "Id", "Version", "Level", "Task", "Opcode", "Keywords", "ProviderId", "ProcessId", "ThreadId", "ContainerLog", "OpcodeDisplayName", "TaskDisplayName")
$dataRecords = foreach ($record in $records) {
    $hash = [ordered]@{}
    
    $propNames | ForEach-Object { $hash[$_] = $record.$_}
    $record.Message.split(";").trim() | ForEach-Object { $pair = $_.split("="); $hash[$pair[0].replace(":", "").trim()] = $pair[1].trim() }
    
    [PSCustomObject]$hash
    
}

Maintenant que nous avons les données dans un format plus utilisable, nous pouvons faire ce que nous voulons.we want with it.
Nous pouvons l’afficher, l’exporter ou effectuer une analyse PowerShell en direct dessus.

Voici quelques exemples :

# Afficher les données
$dataRecords | Format-Table

$dataRecords | Out-GridView

$dataRecords | Select-Object -First 1 | Format-List

Le Format-Table brut peut ne pas être très utile, car la console va envelopper la sortie. Out-GridView est un peu plus convivial, car il fournit un tableau défilable et triable. Avec Format-List, vous pouvez avoir un aperçu des détails d’un seul enregistrement, ce qui vous donne des informations sur la propriété à rechercher et à regrouper lors d’analyses ultérieures.

# Exporter les données pour les utiliser dans d'autres outils comme Excel, PowerBI, ou ce que vous voulez
$dataRecords | Export-Csv -Path "DNSServer-Analytics.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

L’exportation au format CSV et son transfert vers Excel semble être la solution évidente dans de nombreux cas, car cela vous donne le pouvoir d’autres outils pour trancher et découper les données.

D’un autre côté, si vous souhaitez effectuer une analyse rapide directement dans PowerShell pendant que vous êtes en appel de dépannage, cela peut également être fait. Voici quelques idées :

# Trancher et découper... obtenir des informations directement dans PowerShell avec un regroupement de base
$dataRecords | Group-Object TaskDisplayName
$dataRecords | Group-Object QNAME
$dataRecords | Group-Object InterfaceIP
$dataRecords | Group-Object Source

# Quelques exemples de regroupement plus avancés
$dataRecords | Group-Object { "Source '$($_.Source)' sur Interface '$($_.InterfaceIP)'" } | Format-Table Count, Name
$dataRecords | Group-Object { "Source '$($_.Source)' sur Interface '$($_.InterfaceIP)' avec '$($_.QNAME)'" } | Sort-Object Name | Format-Table Count, Name
$dataRecords | Group-Object { "'$($_.QNAME)' - Source '$($_.Source)' ($($_.TaskDisplayName))" } | Sort-Object Name | Format-Table Count, Name
$dataRecords | Group-Object { "'$($_.QNAME)' - Source '$($_.Source)' sur Interface '$($_.InterfaceIP)' ($($_.TaskDisplayName))" } | Sort-Object Name | Format-Table Count, Name

# Regroupement combiné avec filtrage
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Group-Object { "Source '$($_.Source)' - '$($_.QNAME)'" } | Sort-Object Name | Format-Table Count, Name

# Après avoir exploré les valeurs possibles à partir du regroupement de base, nous pouvons filtrer et lister les enregistrements avec leurs détails
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Where-Object Source | Sort-Object TimeCreated | Format-Table MachineName, TimeCreated, Source, InterfaceIP, QNAME, QTYPE
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Where-Object Source -like "10.1.1.1" | Sort-Object QNAME | Format-Table MachineName, TimeCreated, Source, InterfaceIP, QNAME, QTYPE

En montrant cela, j’espère vous donner quelques idées sur la façon d’obtenir des informations à partir des données et comment utiliser PowerShell pour cela.
Bien sûr, il existe de nombreuses autres options disponibles et cela peut ne pas être évolutif pour des ensembles de données très volumineux ou sur de longues périodes. Par conséquent, jetons un œil au chapitre suivant…

DebugLogFile

Jeter un œil sur l’option de fichier de journal de débogage DNS apporte une solution pour traiter l’approche non surveillée et à long terme. Cela peut également mieux évoluer sur de grands ensembles de données dans des environnements plus vastes. Le fichier lui-même est basé sur du texte, donc il peut être lu en l’ouvrant dans Notepad. Fichier de journal de débogage DNS dans Notepad

Malheureusement, le format n’est pas parfaitement structuré, donc il y a besoin d’un certain traitement des données pour obtenir les données dans un format plus utilisable. Donc, comme nous l’avons fait avec les journaux d’événements auparavant, allons dans PowerShell pour faire un peu de magie de parsing.


En faisant des recherches et du travail d’IA sur le format du fichier DebugLogFile, de manière amusante, l’IA s’est plainte que le format n’est pas parfaitement structuré pour un parsing facile. 🤪


Pour faire face à ce défi, j’ai créé un module PowerShell appelé [DNSServer.DebugLogParser][dNSServerDebugLogParserDef].
Le module fournit une logique de parsing complète au sein d’une seule cmdlet. C’est essentiellement un “guichet unique” pour convertir le “fichier journal difficile à analyser” en un fichier CSV valide et facile à utiliser. Le module s’occupe de toutes les étapes nécessaires. Dans le [dossier des actifs][dnssLogParserRepositoryExampleFolder] du [dépôt GitHub du module][dnssLogParserRepository], vous pouvez trouver quelques fichiers journaux d’exemple et leurs CSV convertis à consulter. Évidemment, vous pouvez et devriez utiliser vos propres fichiers de votre environnement aussi !

Donc, pour vous donner un exemple rapide du processus de conversion, voici un exemple simple sur la façon d’utiliser le module pour convertir un fichier DebugLogFile en un fichier CSV :

# Importer le module (assurez-vous de l'installer d'abord)
Import-Module DNSServer.DebugLogParser

# Analyser le DebugLogFile et exporter en CSV
Convert-DNSDebugLogFile "DnsDebugLog_DC01.log"

En faisant cela avec tous les paramètres par défaut de la commande, vous obtenez 3 fichiers CSV en sortie du processus de conversion.

FichierDescription
DnsDebugLog_DC01.csvC’est le fichier journal converti avec ses détails dans un format de style CSV
DnsDebugLog_DC01_Statistic.csvUn CSV avec une statistique résumant tous les types d’enregistrements dans le journal par jour
DnsDebugLog_DC01_PacketStatistic.csvUn CSV avec une statistique pour le type “Packet” et un résumé sur tous les clients par jour

Comme déjà souligné dans les sections précédentes, les CSV peuvent être utilisés pour une analyse ultérieure dans Excel, PowerBI, ou ce que vous voulez. L’intention de produire plusieurs fichiers est de faire face aux défis des grands ensembles de données dans des environnements plus vastes.

En fonction de votre cas d’utilisation, vous ne voudrez probablement avoir que des statistiques d’utilisation. Avec cette approche, vous n’avez pas besoin d’inspecter tous les détails dans le journal complet. Cela peut réduire considérablement la quantité de stockage, car cela résume déjà les données et ignore tous les détails bruyants.
Dans le cas où vous souhaitez approfondir la recherche et l’analyse des détails, vous voudrez peut-être utiliser le journal complet et ignorer les statistiques, car elles ne fournissent pas suffisamment de détails.


Mais ne serait-il pas agréable d’avoir un paramètre pour spécifier lequel des fichiers de sortie vous souhaitez avoir ?
Dites bonjour au paramètre -OutputType !

Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -OutputType Statistic

Avec cela, vous pouvez spécifier si vous souhaitez uniquement le journal, uniquement les statistiques, ou les deux. Cela vous donne plus de flexibilité et peut potentiellement vous faire économiser beaucoup d’espace de stockage.


En inspectant les fichiers CSV générés, vous pourriez réaliser qu’il y a une colonne vide appelée “ComputerName” dans les CSV.

C’est parce que le journal de débogage DNS ne contient pas le nom du serveur. 🤷‍♂️

Vous pouvez donner vie à cette colonne en passant le nom du serveur au paramètre -ComputerName dans la commande.

# Spécifier manuellement le nom de l'ordinateur
Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -ComputerName "DC01"

Vous souvenez-vous de mon conseil dans la section Configurer le DebugLogFile sur mettre le nom du serveur dans le nom des fichiers journaux ? Avec de la pratique, vous pouvez mettre le nom du serveur dans le fichier CSV à la volée en divisant le nom du fichier.

# Extraire automatiquement le nom de l'ordinateur à partir du nom du fichier
$files = Get-ChildItem c:\logs\*.log

foreach($file in $files) {
    Convert-DNSDebugLogFile -InputFile $file.FullName -ComputerName $file.BaseName.split("_")[1]
}

C’est particulièrement utile si vous avez plusieurs serveurs et souhaitez avoir le nom du serveur dans le CSV pour une meilleure identification et analyse.

Une autre chose à laquelle vous voudrez probablement faire attention est le format de date dans le CSV généré. Par défaut, le format du fichier journal sous-jacent est utilisé.
Cela peut poser des défis lorsque vous avez un environnement international avec des serveurs localisés. Probablement, le format de date peut varier d’un serveur à l’autre. Cela créera des défis lorsque vous voudrez effectuer une analyse sur la date dans des outils comme Excel ou PowerBI, car ils peuvent ne pas reconnaître correctement le format de date. Pour faire face à cela, vous pouvez utiliser un autre paramètre dans la commande… bienvenue au paramètre -OutputCulture.

Ma préférence personnelle en matière de format de date est le format ISO, donc je règle généralement la culture de sortie suédoise ("sv-SE"), car elle utilise le format ISO pour la date et l’heure. Avec cela, je peux m’assurer que le format de date dans le CSV généré est cohérent, triable et facilement reconnaissable, quel que soit les paramètres régionaux.

Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -OutputCulture "sv-SE"

À titre de note, il existe également un paramètre -InputCulture si vous êtes au courant du format explicitement utilisé sur le serveur source. Ce paramètre fonctionne de la même manière que le paramètre -OutputCulture, mais il est utilisé pour spécifier la culture pour analyser la date à partir du fichier journal source.


Dernier point mais non le moindre, deux conseils pratiques pour une utilisation en production :
Après la conversion du fichier journal original en CSV, vous voudrez peut-être le supprimer pour économiser de l’espace de stockage. Le CSV devrait contenir toutes les informations dans un format plus utilisable. Avec le paramètre -RemoveSourceFile, vous pouvez le faire sans effort supplémentaire.
Et comme les fichiers journaux sont du texte brut et peuvent être assez volumineux, vous voudrez peut-être les compresser après la conversion. Avec le paramètre -CompressOutput, vous pouvez également le faire à la volée.

Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -OutputCulture "sv-SE" -RemoveSourceFile -CompressOutput

En combinant tout cela, vous pouvez avoir un outil assez puissant et flexible pour obtenir des données pour une analyse ultérieure à partir des journaux de débogage DNS, tout en prenantprendre soin de l’espace de stockage et de la gestion des fichiers. En guise d’exemple final, je souhaite évoquer un exemple plus complet que vous pouvez utiliser dans un environnement de production :

# obtenir les fichiers journaux entièrement écrits (roulés) du dossier de journaux
$files = Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Sort-Object lastwritetime, Name -Descending | Select-Object -Skip 1

# Passer les fichiers en conversion avec tous les paramètres pratiques pour une utilisation en production
foreach($file in $files) {
    $file | Convert-DNSDebugLogFile -ComputerName $file.BaseName.split("_")[1] -Delimiter ';' -OutputType 'Both' -ContextFilter Packet -OutputCulture sv-SE -CompressOutput -RemoveSourceFile
}

Cet exemple, en particulier avec le filtrage dans le processus de sélection des fichiers, est destiné à être exécuté directement sur les serveurs DNS. Mais il est également acceptable de l’exécuter sur une machine dédiée pour économiser des ressources sur les serveurs DNS. S’il est exécuté sur une machine dédiée, vous n’avez pas besoin d’utiliser Select-Object -Skip 1 dans le processus de sélection des fichiers.


Dans tous les cas, vous devez vous occuper de la collecte des fichiers, qu’il s’agisse des fichiers traités ou des fichiers journaux originaux. Avec l’exemple montré, l’avantage est que vous ne transporterez que des fichiers ZIP déjà compressés. Cela peut être une bonne approche pour économiser la bande passante réseau, surtout si vous avez des serveurs largement répartis avec beaucoup de données de journaux.

Créer des rapports

Après la configuration et la collecte des données, vous voudrez probablement les utiliser pour créer des informations et des rapports précieux. En fonction de votre cas d’utilisation, différents outils sont disponibles pour cela. Jetons un œil à quelques options.

Je suis pleinement conscient qu’il existe de nombreux autres outils et approches disponibles, donc considérez les sections suivantes comme de simples exemples de base pour avoir un aperçu des possibilités.

PowerShell - le coup rapide

Comme déjà décrit dans la section Consommation des données - Journaux d’événements, vous pouvez effectuer une analyse rapide directement dans PowerShell en important les données. Cela peut être pratique lors de sessions de dépannage rapides, où vous souhaitez simplement obtenir rapidement quelques informations de base. Bien sûr, ce n’est pas la solution de premier choix pour une analyse complexe ou des rapports à long terme, mais c’est possible.

Je ne vais pas entrer dans trop de détails ici, car nous avons déjà couvert les options de regroupement et de filtrage de base dans la section Consommation des données - Journaux d’événements. Juste comme un autre exemple, la même approche avec Group-Object peut être appliquée aux fichiers CSV du DebugLogFile également :

# Importer les données du fichier CSV généré
$dataRecords = Get-ChildItem C:\Administration\Logs\DNSServer\*_PacketStatistic.csv -File -Recurse | Import-Csv -Delimiter ";" -Encoding utf8

# Résumer combien de requêtes DNS ont été effectuées
$dataRecords | Measure-Object Count -Sum

# Quels serveurs sont dans les données
$dataRecords | Group-Object ComputerName -NoElement

# Quel type de requêtes DNS a été collecté
$dataRecords | Group-Object QuestionType -NoElement

# Quelles adresses IP de clients DNS sont en contact avec le(s) serveur(s)
$dataRecords | Group-Object ClientIP -NoElement

# Quels clients DNS parlent à quel serveur distinctement
$dataRecords | Group-Object { "$($_.ClientIP) --> $($_.ComputerName)" } | Format-Table Name -AutoSize

Surtout le dernier exemple sur le regroupement pour ClientIP peut être très utile pour construire un tableau de corrélation pour l’IP et le nom respectif du système. Cela nécessite bien sûr une infrastructure DNS appropriée avec tous les appareils enregistrés en place. Voici comment vous pouvez le faire avec PowerShell :

# Obtenir la liste des IPs clients uniques à partir des enregistrements de données
$clientIPList = $dataRecords | Group-Object ClientIP -NoElement | Select-Object -ExpandProperty Name

# Résoudre les IPs clients en noms d'hôtes et créer un tableau de correspondance
$clientMapping = foreach ($clientIP in $clientIPList) {
    if ($clientIP -in ("127.0.0.1", "0.0.0.0", "::1", ".")) {
        [pscustomobject]@{
            ClientIP = $clientIP
            Name     = "Localhost sur le serveur DNS"
        }
    } else {
        $result = Resolve-DnsName -Name $clientIP -Type PTR -QuickTimeout -ErrorAction SilentlyContinue 
        
        if (([array]$result).count -ge 1) {
            [pscustomobject]@{
                ClientIP = $clientIP
                Name     = (($result.NameHost | Sort-Object) -join "; ")
            }
        } else {
            [pscustomobject]@{
                ClientIP = $clientIP
                Name     = "<nom non résolvable par DNS>"
            }
        }
    }
}

# Sortir le tableau de correspondance des clients
$clientMapping | Format-Table -AutoSize

# Exporter la correspondance des clients dans un fichier CSV pour une utilisation ultérieure
$clientMapping | Export-Csv -Path "ClientIP_Mapping.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Une telle correspondance des clients peut être pratique et utile. Les résultats peuvent ressembler à ceci :
refreshed on a regular basis and are easily accessible by multiple users without knowing how to deal with the underlying data.

In case you still want to have a look on the PowerBI file with the examples, here is the [PowerBI file with the data and the examples][pbiStatisticsFile].

Conclusion

Avec tout cela, vous êtes maintenant bien équipé pour plonger dans le monde de la journalisation de débogage des serveurs DNS.


Vous avez les connaissances nécessaires pour activer et configurer la journalisation de débogage, ainsi que pour consommer et analyser les données générées. Que vous choisissiez de faire une analyse rapide dans PowerShell ou de créer des rapports détaillés dans Excel ou PowerBI, le choix vous appartient. N’oubliez pas, avec un grand pouvoir vient une grande responsabilité, alors soyez conscient de la quantité de données que vous collectez et de la manière dont vous les utilisez.

🚀 Bonne journalisation et analyse ! 🚀



Liens connexes

  • [Microsoft Docs : Journalisation de débogage dans le serveur DNS][msDebugLoggingInDnsServer] - Documentation officielle sur l’activation et l’utilisation de la journalisation de débogage dans le serveur DNS.
  • [PowerShell Gallery : DNSServer.DebugLogParser][dNSServerDebugLogParserDef] - Module PowerShell pour analyser les fichiers journaux de débogage du serveur DNS.
  • [GitHub Repository : DNSServer.DebugLogParser][dnssLogParserRepository] - Répertoire GitHub pour le module DNSServer.DebugLogParser, y compris la documentation et des exemples de scripts.
  • [Documentation PowerQuery][powerQueryDocLink] - Documentation officielle pour PowerQuery, un puissant outil de transformation et d’analyse de données qui peut être utilisé avec Excel et PowerBI.
  • [Documentation PowerBI][powerBIDocLink] - Documentation officielle pour PowerBI, un puissant outil d’analyse commerciale qui peut être utilisé pour créer des rapports et des tableaux de bord interactifs.

Autres liens

Mèmes de [makeameme.org][makeAMemeLink]