À propos de cette documentation

• 1: Vue d'ensemble
• 2: Formats de sortie
• 3: Paramètres et options
• 4: Performance
• 5: Intégration avec les outils d’analyse
• 6: Bonnes pratiques opérationnelles
• 7: Dépannage
• 8: Référence des commandes du module
• 8.1: Convert-DNSDebugLogFile
• 9: Exemples d'utilisation
• 9.1: Flux de travail d'analyse de sécurité avec SQL Server
• 9.2: Utilisation pratique dans un environnement de domaine (collection et conversion pilotées par GPO)
• 9.3: Exemple de tâche planifiée

1 - Vue d'ensemble

Le serveur DNS Windows peut écrire un journal de débogage. C’est un fichier texte brut, destiné à être lu par un humain, et qui peut grossir de plusieurs centaines de mégaoctets par jour sur un contrôleur de domaine très sollicité. Cette combinaison le rend presque inutilisable dès que vous voulez répondre à une question comme « quel client a demandé ce domaine 40 000 fois la nuit dernière ? »

DNSServer.DebugLogParser transforme ce fichier texte en tableau CSV. Une ligne de journal devient une ligne avec des colonnes nommées, que vous pouvez ouvrir dans Excel, charger dans Power BI, insérer en masse dans SQL Server, ou envoyer à votre SIEM.

Le module contient une seule commande :

Convert-DNSDebugLogFile -InputFile "C:\Windows\System32\dns\dns.log"

C’est tout le point d’entrée. Tout le reste sur ce site concerne comment le faire à grande échelle, selon un planning, et sur plusieurs serveurs.

À quoi ressemble un journal de débogage DNS

Une entrée brute est une ligne unique avec des champs positionnels, certains entre crochets :

2026-01-20 23:00:16 0FE0 PACKET 000002C53117D990 UDP Rcv 10.0.0.2 c049 Q [0001 D NOERROR] A (3)odc(9)officeapps(4)live(3)com(0)

Après conversion, le même événement devient une ligne CSV que vous pouvez filtrer et trier :

DateTime;ThreadId;Context;PacketId;Protocol;Direction;ClientIP;Xid;Type;Opcode;FlagsHex;FlagsChar;ResponseCode;QuestionType;QuestionName;Information;Details;ComputerName
2026-01-20 23:00:16;0FE0;Packet;000002C53117D990;UDP;Rcv;10.0.0.2;c049;Query;Standard;0001;RecursionDesired;NOERROR;A;"odc.officeapps.live.com";"";"";dc01

Notez deux choses que le format brut rend difficiles et que le parseur gère pour vous :

• Le nom interrogé est stocké en notation DNS wire, (3)odc(9)officeapps(4)live(3)com(0), et devient un FQDN normal.
• Un événement unique n’est pas toujours une ligne unique. Les blocs de détails PACKET et les messages d’événement continuent sur des lignes suivantes indentées. Le parseur les rattache à l’enregistrement auquel ils appartiennent au lieu de les ignorer ou de créer des lignes orphelines.

Chaque entrée contient jusqu’à 16 champs natifs — horodatage, protocole, direction, IP client, type de requête, nom interrogé, code de réponse, flags, et plus. La liste complète des colonnes est décrite dans Formats de sortie.

Pourquoi convertir

Dépannage

• Comprendre pourquoi un nom ne se résout pas, et si la requête a même atteint le serveur
• Identifier les clients ou applications mal configurés qui saturent le serveur
• Tracer l’origine réelle d’une requête problématique
• Vérifier les transferts de zone et le comportement général du DNS

Performance et capacité

• Classer les clients par volume de requêtes et repérer les plus bruyants
• Voir quels types d’enregistrements dominent votre trafic
• Détecter les erreurs de configuration qui causent des recherches inutiles
• Suivre la charge du serveur dans le temps au lieu de deviner

Analyse de sécurité

• Détecter le tunneling DNS et l’exfiltration de données (visible typiquement comme un trafic TXT excessif — voir l’exemple d’analyse SQL Server)
• Trouver les recherches vers des domaines de malwares et de commande et contrôle
• Reconnaître les schémas de requêtes d’un hôte compromis
• Surveiller les abus d’amplification DNS
• Reconstituer ce qui s’est passé lors d’un incident

Conformité et audit

• Respecter les obligations de journalisation et de conservation
• Garder une trace d’audit de l’activité réseau
• Produire des rapports pour la direction ou les auditeurs

Comment fonctionne le module

Convert-DNSDebugLogFile lit le journal en flux et écrit le CSV en flux. Le fichier n’est jamais chargé entièrement en mémoire, donc un journal de 100 Mo consomme à peu près autant de RAM qu’un de 10 Mo. Les détails sont dans Performance.

Ce qu’il vous offre :

Journal actif vs journal archivé

Le schéma pratique est d’activer la rotation des journaux sur le serveur DNS et de laisser la conversion planifiée ignorer le fichier le plus récent :

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME

Une implémentation complète basée sur une stratégie de groupe est documentée dans l’exemple de collecte pilotée par GPO.

Où aller ensuite

• Formats de sortie — ce que signifient les colonnes, avec des fichiers exemples réels
• Paramètres et options — les réglages, expliqués simplement
• Performance — pourquoi c’est rapide et comment le rester
• Intégration — Excel, Power BI, SQL, SIEM, Python
• Bonnes pratiques opérationnelles — l’utilisation en production
• Exemples d’utilisation — tâches planifiées, déploiement GPO, analyses SQL
• Référence des commandes — la liste officielle des paramètres

Licence et support

Licence MIT. Le support communautaire se fait via GitHub Issues ; les rapports de bugs et demandes de fonctionnalités sont les bienvenus.

• Dépôt GitHub : AndiBellstedt/DNSServer.DebugLogParser
• PowerShell Gallery : DNSServer.DebugLogParser

2 - Formats de sortie

Convert-DNSDebugLogFile produit jusqu’à trois fichiers par fichier journal d’entrée :

Both est la valeur par défaut. La sortie est placée à côté du fichier d’entrée sauf si tu définis -OutputFile.

Les fichiers exemples liés sur cette page sont des résultats de conversion réels, pas des maquettes. Télécharge-en un et ouvre-le dans Excel avant de te lancer dans la conception d’un pipeline.

Le fichier de données CSV

Exemple de sortie :

Deux lignes issues d’une conversion réelle — une requête DNS et une note interne au serveur :

DateTime;ThreadId;Context;PacketId;Protocol;Direction;ClientIP;Xid;Type;Opcode;FlagsHex;FlagsChar;ResponseCode;QuestionType;QuestionName;Information;Details;ComputerName
2026-01-20 23:00:16;0FE0;Packet;000002C53117D990;UDP;Rcv;10.0.0.2;c049;Query;Standard;0001;RecursionDesired;NOERROR;A;"odc.officeapps.live.com";"";"";dc01
2026-01-20 23:00:16;DF0;Note;;;;;;;;;;;;"";"got GQCS failure on a dead socket context status=995, socket=904";"";dc01

Colonnes

Toujours 18 colonnes, toujours dans cet ordre :

Deux points à prévoir :

• Toutes les colonnes ne sont pas remplies pour chaque ligne. Seules les entrées Packet ont une IP client, un nom de question et un code de réponse. Les lignes Note et Event portent leur texte dans Information et laissent les colonnes protocole vides. Conçois ton schéma de base de données et tes filtres de tableau de bord en conséquence.
• ComputerName est toujours la dernière colonne, même si tu n’utilises pas -ComputerName. Elle est alors simplement vide. Cela garantit une mise en page identique sur tous les serveurs pour concaténer des fichiers de plusieurs serveurs DNS sans étape de mappage des colonnes.

La colonne Détails

Les blocs de détails n’apparaissent que si le serveur DNS est configuré pour enregistrer les détails complets des paquets. Lorsqu’ils existent, le parseur les convertit en une seule valeur JSON pour que la ligne reste unique :

{
  "Socket": "848",
  "Remote": "addr 10.10.0.11, port 60580",
  "Buflength": "0x10000 (65536)",
  "Message": {
    "XID": "0x0001",
    "OPCODE": "0 (QUERY)",
    "RCODE": "0 (NOERROR)",
    "QUESTION": [ { "Name": "berlin.de", "QTYPE": "A (1)", "QCLASS": "1" } ],
    "ANSWER": []
  }
}

Analyser ces blocs prend du temps et rend le CSV beaucoup plus volumineux. Si tu n’en as pas besoin, utilise -NoDetailsParsing — la colonne reste présente mais vide, et la conversion est plus rapide. Voir Performance.

Les fichiers statistiques

Les statistiques sont des agrégats quotidiens. Utilise-les quand tu veux une tendance ou un résumé et que tu ne veux pas manipuler l’ensemble complet des enregistrements — ils sont des ordres de grandeur plus petits que le fichier de données.

Statistiques par contexte (*_Statistic.csv)

Répondent à la question : quelle quantité de quel type d’activité s’est produite par jour ?

Date;Context;Count;ComputerName
2026-01-20;Event;2;dc01
2026-01-20;Note;2;dc01
2026-01-20;Packet;12;dc01

Fichiers exemples : en-US WithComputerName, en-US NoComputerName, de-DE WithComputerName, de-DE NoComputerName

Statistiques par paquet (*_PacketStatistic.csv)

Répondent à la question : qui a interrogé quoi, combien de fois, par jour ?

Date;ClientIP;Protocol;Direction;QuestionType;Count;ComputerName
2026-01-20;10.0.0.1;UDP;Rcv;A;3;dc01
2026-01-20;10.0.0.1;UDP;Snd;A;3;dc01
2026-01-20;10.0.0.2;UDP;Rcv;A;3;dc01

Fichiers exemples : en-US WithComputerName, en-US NoComputerName, de-DE WithComputerName, de-DE NoComputerName

Délimiteur et format de date

Les deux types de sortie respectent -Delimiter (par défaut ;) et -OutputCulture. Pour tout ce qui sera importé par une machine, écris des horodatages au format ISO-like :

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -OutputCulture 'sv-SE'

Cela produit 2026-01-20 23:00:16, que SQL Server, Power BI et pandas lisent sans indication de format. Détails dans Paramètres et options.

3 - Paramètres et options

Cette page explique les options en langage clair et dans l’ordre où vous en aurez généralement besoin. C’est un guide, pas une spécification — la liste autoritaire et toujours à jour des paramètres se trouve dans la référence de commande et dans :

Get-Help Convert-DNSDebugLogFile -Full

La version courte

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log"

Cette seule ligne vous donne déjà un comportement sensé : fichiers de données et de statistiques, délimiteur point-virgule, format de date de votre machine, validation de l’en-tête activée, journal source intact. Tout ce qui suit est du réglage fin.

Entrée et sortie

-InputFile

Chemin vers le journal à convertir. Accepte un tableau et l’entrée par pipeline — c’est pourquoi ceci fonctionne :

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Convert-DNSDebugLogFile

Get-ChildItem émet des objets avec une propriété FullName, et -InputFile l’accepte par nom de propriété (ses alias incluent FullName, Path, FilePath). Pas besoin de ForEach-Object.

Les chemins locaux et SMB/UNC fonctionnent tous les deux :

Convert-DNSDebugLogFile -InputFile "\\dc01\C$\Administration\Logs\DNSServer\dns.log"

La commande peut aussi ouvrir un journal que le serveur DNS a actuellement ouvert. Voir journaux actifs ci-dessous avant de vous y fier.

-OutputFile

Sans cette option, le CSV est créé à côté du fichier d’entrée, même nom de base, extension .csv. Avec, vous contrôlez la destination.

-Delimiter

Par défaut, c’est un point-virgule, car dans les locales où la virgule est le séparateur décimal, c’est ce qu’Excel attend. Utilisez -Delimiter "," pour les outils et bases de données qui attendent des valeurs séparées par des virgules classiques, ou -Delimiter "`t" pour une tabulation.

Quelle que soit votre sélection, utilisez la même valeur à l’import. Un décalage est la cause numéro un de “tout est dans une seule colonne”.

Étiquetage et filtrage

-ComputerName

Remplit la colonne ComputerName. La colonne existe de toute façon ; cela lui donne juste une valeur.

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -ComputerName $env:COMPUTERNAME

Mettez-le toujours quand plusieurs serveurs alimentent un même jeu de données — sinon vous ne pourrez pas dire ensuite de quel DC vient une ligne.

-OutputType

• CSV — fichier de données uniquement
• Statistic — les deux fichiers agrégés seulement, pas les données ligne par ligne
• Both — les trois fichiers (par défaut)

Statistic est l’option rapide et légère quand vous ne voulez que les tendances journalières. CSV est adapté quand un système en aval fait sa propre agrégation.

-ContextFilter

Un journal de débogage DNS mélange le trafic réel des requêtes avec le bavardage interne du serveur. -ContextFilter décide ce qui survit dans la sortie.

# uniquement le trafic DNS réel
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -ContextFilter Packet

# trafic plus événements serveur, mais pas les notes de diagnostic
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -ContextFilter Packet, Event

D’autres types de contexte (DSPoll, Init, Lookup, Recurse, Remote, Tombstone) apparaissent sous All.

Filtrer sur Event ou Note remplit seulement DateTime, ThreadId, Context et Information — les colonnes de protocole restent vides car ces entrées ne portent pas cette information.

-ContextFilter Packet est le choix habituel pour les pipelines de sécurité et de reporting : il enlève le bruit et réduit nettement la sortie.

Journaux internationaux

Le serveur DNS écrit les horodatages dans la locale Windows de la machine où il tourne. Un DC allemand écrit 20.01.2026 23:00:16 ; un serveur US écrit 1/20/2026 11:00:16 PM. Si la locale de votre poste diffère de celle du serveur, l’analyse échoue — ou pire, échange silencieusement jour et mois.

-InputCulture

Indiquez au parseur la locale utilisée par le journal source :

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns-berlin.log" -InputCulture 'de-DE'

Par défaut, c’est la culture de la session qui exécute la commande. Dans un environnement à locales mixtes, définissez-la explicitement plutôt que de compter sur ce défaut — et souvenez-vous qu’une tâche planifiée lancée en tant que SYSTEM peut ne pas avoir la culture que vous avez testée en interactif.

-OutputCulture

Contrôle comment les horodatages sont écrits dans le CSV :

# sortie de type ISO que SQL Server, Power BI et pandas comprennent tous
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -OutputCulture 'sv-SE'

# même effet, culture invariante explicite
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" `
    -OutputCulture ([System.Globalization.CultureInfo]::InvariantCulture)

Règle générale : si un humain ouvre le fichier dans Excel, adaptez à la culture locale. Si une machine le lit, utilisez sv-SE ou la culture invariante et ne vous souciez plus des paramètres régionaux à l’import.

Les deux paramètres sont indépendants — vous pouvez lire un journal suédois et écrire une sortie au format US.

Vitesse et stockage

-NoDetailsParsing

Si le serveur DNS journalise les détails complets des paquets, le parseur transforme chaque bloc de détails en JSON dans la colonne Details. C’est utile, mais c’est aussi la partie la plus coûteuse du traitement et cela gonfle le CSV.

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -NoDetailsParsing

La colonne reste présente mais vide ; la ligne d’en-tête des détails TCP/UDP est toujours disponible dans Information. Sur des journaux riches en blocs de détails, cela peut réduire le temps de traitement de 30 à 50 %. Utilisez-le dès que les informations au niveau des requêtes suffisent.

-CompressOutput

Compresse les fichiers CSV générés en ZIP et supprime les fichiers non compressés. dns.log produit dns.zip au lieu de dns.csv.

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput

Un CSV de cette forme se compresse typiquement à 90 % ou plus, donc c’est presque un gain de stockage gratuit pour les archives et pour l’envoi des fichiers sur le réseau.

-RemoveSourceFile

Supprime le fichier source .log après une conversion réussie — le journal n’est supprimé que si tous les fichiers de sortie ont été créés.

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput -RemoveSourceFile

Filets de sécurité

-SkipHeaderValidation

Par défaut, la commande vérifie que le fichier est bien un journal de débogage DNS Server avant de le parser. Cela évite la classique erreur de pointer la tâche vers le mauvais dossier.

Désactivez-le uniquement pour des cas vraiment inhabituels : journaux édités à la main, extraits pré-filtrés, formats personnalisés. Gardez-le activé partout ailleurs — c’est peu coûteux et c’est ce qui vous protège d’une faute de frappe et d’une montagne de lignes inutiles.

-WhatIf et -Confirm

La commande supporte les deux. -WhatIf est la bonne façon de voir ce qu’une nouvelle tâche par lot toucherait :

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Convert-DNSDebugLogFile -RemoveSourceFile -WhatIf

-Confirm demande une confirmation avant de traiter chaque fichier, avant de supprimer un fichier source, et avant d’écraser une sortie existante.

Journaux actifs

Convert-DNSDebugLogFile peut lire un fichier que le serveur DNS a ouvert. Pratique pour un coup d’œil ad hoc sur ce qui se passe en ce moment.

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME

Mise en pratique

Une invocation typique en production sur un contrôleur de domaine :

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile `
        -ComputerName $env:COMPUTERNAME `
        -Delimiter ';' `
        -OutputType Both `
        -ContextFilter Packet `
        -OutputCulture 'sv-SE' `
        -CompressOutput

À lire comme : prenez chaque journal tourné sauf l’actif, ne gardez que le trafic DNS, étiquetez chaque ligne avec le nom du serveur, écrivez des horodatages lisibles par machine, et laissez des archives compressées. La version complète pour tâche planifiée et stratégie de groupe est dans l’exemple de collecte pilotée par GPO.

4 - Performance

Les journaux de débogage DNS sur un contrôleur de domaine très actif sont volumineux. Convert-DNSDebugLogFile est conçu pour ce cas : il a été testé avec des journaux de 100 Mo et plus, et les traite en quelques minutes sur du matériel serveur ordinaire.

Pourquoi c’est rapide

Vous n’avez pas besoin de connaître tout cela pour utiliser le module, mais cela explique le comportement que vous observerez.

La conséquence importante : le journal complet n’est jamais chargé en mémoire. Un journal de 500 Mo ne nécessite pas 500 Mo de RAM. C’est la différence entre le module et l’approche « lire le fichier, le découper, construire des objets » que la plupart des scripts maison utilisent — cette approche fonctionne bien sur un échantillon de 5 Mo mais plante sur un vrai DC.

Tirer le meilleur parti d’une exécution

Convertir des morceaux tournés, pas un fichier géant

Configurez le serveur DNS pour faire tourner le journal à une taille gérable — 50 à 200 Mo est une bonne plage. Plusieurs fichiers moyens se convertissent en un temps prévisible et permettent à une tâche planifiée de finir dans sa fenêtre. Un fichier qui ne cesse de grossir finit par ne plus y arriver.

La rotation vous donne aussi des fichiers fermés avec lesquels travailler, ce que vous voulez de toute façon :

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME

Sauter l’analyse détaillée quand ce n’est pas nécessaire

Si le serveur DNS écrit les détails complets des paquets, transformer ces blocs en JSON est la partie la plus coûteuse de la conversion.

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -NoDetailsParsing

Attendez-vous à des exécutions 30 à 50 % plus rapides sur les journaux contenant beaucoup de blocs détaillés, plus un CSV beaucoup plus petit. Vous obtenez toujours les données au niveau des requêtes et la ligne d’en-tête détaillée TCP/UDP dans Information. Voir Paramètres et Options.

Filtrer tôt

-ContextFilter Packet élimine les notes et événements du serveur avant qu’ils ne soient écrits. Moins de sortie signifie moins d’E/S, des fichiers plus petits, et moins de travail en aval.

Demander uniquement ce dont vous avez besoin

-OutputType Statistic évite complètement d’écrire le CSV ligne par ligne. Si votre tableau de bord affiche seulement des comptes journaliers, c’est de loin l’option la moins coûteuse.

Convertir localement, déplacer les résultats

Le module lit les chemins SMB/UNC, mais transférer un journal brut de 200 Mo sur le réseau pour le parser centralement est la méthode lente. Convertissez sur le serveur DNS, puis déplacez le CSV (compressé) — c’est généralement un dixième des octets. C’est le principe derrière l’exemple de collecte pilotée par GPO.

Compresser pour le transfert et l’archivage

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput

Un CSV de cette forme se réduit typiquement de 90 % ou plus. La compression coûte un peu de CPU à la fin de l’exécution et économise beaucoup d’espace disque et de bande passante ensuite.

Quand une exécution est plus lente que prévu

Vérifiez ces points dans l’ordre :

1. Disque, pas CPU. La conversion est gourmande en E/S. Un journal sur un volume très occupé, ou lu via un lien lent, domine le temps d’exécution.
2. Blocs détaillés. Si le journal contient les détails complets des paquets et que vous n’avez pas utilisé -NoDetailsParsing, c’est là que le temps se passe.
3. Taille du fichier. Un seul journal de plusieurs gigaoctets prendra du temps quoi qu’il arrive. Réglez cela avec la rotation, pas avec des paramètres.
4. Antivirus. L’analyse en temps réel du journal source et du CSV généré peut doubler le coût effectif des E/S. Une exclusion pour le répertoire des journaux est une mesure courante et raisonnable.
5. Pression mémoire. Le module utilise le streaming, donc ce ne devrait pas être la cause — mais un serveur déjà en swap ralentira tout.

D’autres symptômes et solutions sont rassemblés dans Dépannage.

5 - Intégration avec les outils d’analyse

Le but de la conversion d’un journal de débogage DNS est ce qui se passe ensuite. Le CSV a été choisi parce que tout le monde le lit — mais « tout le monde lit le CSV » cache deux réglages qui décident si l’import est simple ou une après-midi de bidouillage.

Deux réglages qui décident de tout

Délimiteur. Par défaut ;. Gardez-le pour Excel dans les locales qui utilisent la virgule comme séparateur décimal. Passez à , pour la plupart des bases de données et outils de data science. Quel que soit votre choix, indiquez-le à la partie qui importe.

Format de date. -OutputCulture contrôle la façon dont les horodatages sont écrits. Pour tout ce qui est lu par une machine, utilisez sv-SE (ou culture invariante) pour que DateTime sorte sous la forme 2026-01-20 23:00:16 :

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -OutputCulture 'sv-SE'

Tous les consommateurs ci-dessous comprennent ce format sans indice. Une sortie spécifique à une locale comme 20.01.2026 sera importée en texte ou, pire, mal interprétée comme mois/jour.

Microsoft Excel

Le moyen le plus rapide pour consulter un journal converti unique.

• Avec le délimiteur par défaut ; et une locale qui l’attend, un double-clic ouvre le fichier avec les colonnes correctement séparées.
• Si tout atterrit dans la colonne A, le délimiteur ne correspond pas à votre réglage Excel. Relancez avec -Delimiter "," ou importez via Données → À partir du texte/CSV et choisissez le délimiteur là.
• Transformez la plage en tableau (Ctrl+T) et créez un tableau croisé dynamique sur ClientIP, QuestionName ou QuestionType. Les principaux clients et domaines prennent environ une minute.
• Pour plus de quelques centaines de milliers de lignes, utilisez plutôt Power Query ou une des autres options ci-dessous.

Les fichiers *_Statistic.csv et *_PacketStatistic.csv sont généralement de meilleures cibles pour Excel — ils sont pré-agrégés et restent petits. Voir Formats de sortie.

Power BI

Importez les fichiers CSV et créez des tableaux de bord pour l’activité DNS, les principaux clients, les tendances des requêtes et les taux d’erreur.

• Pointez Power Query vers le dossier contenant vos fichiers convertis plutôt qu’un seul fichier. La structure est identique entre serveurs et jours, donc les fichiers s’additionnent simplement.
• La colonne ComputerName permet de faire un rapport multi-serveurs — définissez -ComputerName lors de la conversion sinon vous ne pourrez pas filtrer par serveur.
• ResponseCode et QuestionType sont des filtres naturels ; DateTime devient votre axe temporel.
• Alimenter Power BI avec *_PacketStatistic.csv au lieu du fichier complet garde le modèle léger quand vous avez seulement besoin des tendances journalières.

Bases de données SQL

Chargez en masse le CSV dans SQL Server, PostgreSQL ou tout autre système SQL, pour une conservation à long terme et des requêtes répétables.

Un tutoriel prêt à l’emploi — définition de table, conversion, import SqlBulkCopy et requête de détection d’activité TXT suspecte — est documenté dans Workflow d’analyse de sécurité avec SQL Server.

Points à planifier avant la première charge :

• Utilisez -OutputCulture 'sv-SE' pour que les horodatages arrivent dans une colonne datetime2 sans astuces de conversion.
• Information et Details peuvent être longs ; donnez-leur nvarchar(max).
• Indexez ce que vous interrogez réellement — typiquement DateTime, ClientIP et QuestionName.
• Gardez -ComputerName renseigné pour que les lignes restent attribuables après fusion.

Systèmes SIEM

Splunk, Elastic, Sentinel et plateformes similaires ingèrent le CSV pour corrélation avec d’autres télémétries de sécurité et pour les alertes.

• Envoyez la sortie compressée (-CompressOutput) — elle fait environ un dixième de la taille et la plupart des collecteurs la décompressent eux-mêmes.
• Définissez le mapping des champs une fois ; la disposition des colonnes ne change jamais entre les exécutions ou serveurs, y compris la colonne ComputerName toujours présente à la fin.
• Faites dédupliquer votre collecteur, ou archivez les fichiers .log traités. Un job de conversion qui retraiterait les mêmes logs tournés renverrait sinon des lignes identiques.
• -ContextFilter Packet limite le volume d’ingestion (et le coût de licence) quand les notes serveur ne font pas partie de vos cas d’usage.

Python, R et outils de data science

La sortie structurée est prête pour la détection d’anomalies, la mise en référence et les analyses personnalisées.

import pandas as pd

df = pd.read_csv(
    r"C:\Administration\Logs\DNSServer\dns.csv",
    sep=";",
    parse_dates=["DateTime"],
)

# top 20 des noms interrogés, uniquement les requêtes
top = (
    df[df["Direction"] == "Rcv"]
    .groupby("QuestionName")
    .size()
    .sort_values(ascending=False)
    .head(20)
)
print(top)

parse_dates fonctionne directement quand vous avez exporté avec -OutputCulture 'sv-SE'. À partir de là, pandas, scikit-learn ou R gèrent le clustering, la saisonnalité et la détection d’anomalies comme d’habitude.

Rester dans PowerShell

Pas besoin de quitter PowerShell pour une réponse rapide :

$dns = Import-Csv "C:\Administration\Logs\DNSServer\dns.csv" -Delimiter ';'

# clients les plus bruyants
$dns | Where-Object Direction -eq 'Rcv' |
    Group-Object ClientIP |
    Sort-Object Count -Descending |
    Select-Object -First 10 Count, Name

# recherches échouées
$dns | Where-Object ResponseCode -eq 'NXDOMAIN' |
    Group-Object QuestionName |
    Sort-Object Count -Descending |
    Select-Object -First 10 Count, Name

Import-Csv lit tout le fichier en mémoire, donc c’est bien pour un fichier tourné mais pas adapté à un export de plusieurs gigaoctets — c’est là que les bases de données et SIEM entrent en jeu.

6 - Bonnes pratiques opérationnelles

Convertir un journal à la main est facile. Le faire tourner chaque nuit sur chaque contrôleur de domaine, pendant des années, sans que personne ne le regarde, c’est la partie qui demande un peu de conception. Voici les points qui comptent en pratique.

1. Convertir les journaux archivés, pas celui en cours

Activez la rotation des journaux sur le serveur DNS et ne convertissez que les fichiers fermés. Le module peut lire le journal sur lequel le serveur DNS écrit actuellement, mais ce fichier change pendant la conversion : les entrées les plus récentes peuvent manquer et le dernier enregistrement peut être tronqué. Deux exécutions produisent deux résultats différents.

Le modèle standard ignore le fichier le plus récent :

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME

Compromis à garder en tête : sur un serveur à faible volume, la rotation peut prendre plus d’un jour, donc les données du jour en cours restent non converties jusqu’à la rotation du fichier. Ajustez le seuil de rotation en conséquence.

2. Planifiez-le, et donnez au travail une identité qui fonctionne

Le Planificateur de tâches est l’endroit habituel — une exécution quotidienne est un bon choix par défaut. Une implémentation complète via GPO pour les contrôleurs de domaine est documentée dans l’exemple de collecte pilotée par GPO, et une tâche autonome dans l’exemple de tâche planifiée.

Trois pièges courants :

• Découverte du module. Une tâche exécutée en tant que SYSTEM avec -NoProfile ne voit que les chemins de modules machine-wide. Installez le module pour toute la machine, ou ajoutez un Import-Module explicite dans l’action de la tâche.
• Culture. Le compte qui exécute la tâche peut ne pas avoir la locale avec laquelle vous avez testé en interactif. Spécifiez explicitement -InputCulture et -OutputCulture au lieu de compter sur la valeur par défaut.
• Accès réseau. Si la source ou la destination est un chemin UNC, SYSTEM s’authentifie en tant que compte ordinateur. Accordez les droits de partage et NTFS au compte ordinateur (ou au groupe Domain Controllers), ou exécutez la tâche avec un compte de service dédié.

3. Faites tourner la rotation à une taille que vous pouvez traiter

50 à 200 Mo par fichier maintiennent les conversions prévisibles et permettent à un travail nocturne de finir dans sa fenêtre. Un fichier qui grandit sans fin ne le permet pas. Voir Performance.

4. Validez les premiers résultats avant d’automatiser

Lancez la conversion manuellement sur deux ou trois vrais journaux et ouvrez vraiment le CSV :

• Les horodatages sont-ils corrects — pas d’inversion jour/mois ? (Si oui, définissez -InputCulture.)
• Le délimiteur correspond-il à ce que votre consommateur attend ?
• Le champ ComputerName est-il rempli ?
• Les contextes dont vous avez besoin sont-ils présents, et ceux dont vous n’avez pas besoin sont-ils filtrés ?

-WhatIf vous montre quels fichiers un lot toucherait avant de les toucher :

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Convert-DNSDebugLogFile -RemoveSourceFile -WhatIf

5. Décidez ce qu’il advient des journaux traités

Un travail qui convertit simplement « tous les journaux sauf le plus récent » retraitera les mêmes fichiers chaque nuit. C’est robuste et simple, mais cela écrase les sorties et peut injecter des lignes dupliquées dans ce qui les ingère.

Choisissez une option :

• déplacer les fichiers .log traités dans un dossier d’archive
• les supprimer avec -RemoveSourceFile une fois que vous avez confiance dans la chaîne
• faire dédupliquer le collecteur en aval

Quelle que soit votre décision, notez-la — c’est ce détail qui embrouille le prochain administrateur.

6. Planifiez le stockage et la rétention

La compression (-CompressOutput) réduit généralement le CSV de 90 % ou plus, mais le volume s’accumule quand même. Estimez à partir de votre taux de requêtes réel et de votre obligation de rétention, et fixez une date de fin pour les données au lieu de les laisser croître indéfiniment.

-OutputType Statistic mérite d’être envisagé pour une rétention longue : les agrégats quotidiens sont minuscules et répondent souvent aux questions de tendance pour lesquelles les données détaillées anciennes étaient conservées.

7. Traitez la sortie comme sensible

Les journaux DNS analysés décrivent votre structure de noms interne et qui a cherché quoi. C’est plus révélateur que la plupart des journaux d’infrastructure, et selon votre juridiction cela peut être considéré comme des données personnelles.

• Restreignez les permissions NTFS et de partage sur les dossiers de sortie.
• Ne déposez pas les CSV sur un partage de fichiers généraliste « temporairement ».
• Incluez les données des journaux DNS dans votre politique de rétention et de suppression, pas seulement dans votre politique de sauvegarde.
• La sortie compressée est plus petite, pas protégée — utilisez le chiffrement ou le contrôle d’accès là où c’est important.

8. Gardez la validation d’en-tête activée

La vérification par défaut qu’un fichier est bien un journal de débogage DNS ne coûte rien et évite qu’un chemin mal tapé produise des milliers de lignes absurdes. Utilisez -SkipHeaderValidation uniquement pour des formats vraiment inhabituels — et notez que la commande refuse de le combiner avec -RemoveSourceFile pour cette raison précise.

9. Surveillez le travail, pas seulement le serveur

Une conversion sans surveillance qui s’arrête silencieusement est pire qu’aucune conversion, car le trou n’est remarqué que lorsqu’on a besoin des données.

• Surveillez la sortie d’erreur non nulle ; l’implémentation de référence GPO lance volontairement une erreur quand $Error.Count -gt 0 pour que la tâche signale un échec.
• Alertez sur le dernier code de résultat de la tâche planifiée, pas seulement sur son existence.
• Vérifiez que les fichiers de sortie apparaissent bien avec des horodatages récents.
• Surveillez l’espace disque libre sur le volume des journaux et sur la cible de sortie.

Les causes courantes d’échec — accès refusé, journaux corrompus, en-têtes invalides — sont couvertes dans Dépannage.

10. Documentez le flux de travail

Où les journaux sont écrits, quand le travail s’exécute, quels paramètres sont utilisés, où la sortie va, qui la consomme, et combien de temps elle est conservée. Six lignes dans votre wiki opérationnel. C’est ce qui rend la configuration auditable et transmissible.

7 - Dépannage

« Le fichier n’est pas un fichier de journal de débogage DNS valide »

La vérification de l’en-tête a rejeté l’entrée. En général, le chemin est simplement incorrect — un fichier .log dans le même dossier qui n’est pas un journal de débogage DNS, ou un fichier qui ne contient qu’un en-tête tourné.

Procédez ainsi :

1. Ouvrez le fichier. Un journal de débogage DNS commence par une ligne d’en-tête telle que Message logging started at … et continue avec des entrées de requêtes horodatées.

2. Confirmez que la journalisation de débogage DNS est bien activée et écrit dans le chemin attendu :

   Get-DnsServerDiagnostics | Select-Object Enable, LogFilePath, MaxMBFileSize
   

3. Si le fichier est vraiment un journal DNS mais que l’en-tête est inhabituel — modifié manuellement, pré-filtré, une exportation personnalisée — contournez la vérification :

   Convert-DNSDebugLogFile -InputFile "C:\Logs\odd.log" -SkipHeaderValidation
   

Gardez la validation activée partout ailleurs. Notez que -SkipHeaderValidation ne peut pas être combiné avec -RemoveSourceFile, donc un fichier non vérifié ne peut jamais être supprimé par la conversion.

Le fichier de sortie est vide ou contient beaucoup moins de lignes que prévu

Vérifiez, dans cet ordre :

• Le journal contient-il des entrées de requêtes ? Un journal fraîchement tourné peut ne contenir qu’un en-tête si aucune requête n’a encore eu lieu.
• Un -ContextFilter est-il utilisé ? -ContextFilter Packet supprime par conception les entrées Event et Note. Si vous avez filtré sur Event ou Note, la plupart des colonnes seront aussi vides — ces types d’entrées ne contiennent que DateTime, ThreadId, Context et Information.
• Le journal source était-il actif ? Un fichier sur lequel le serveur DNS écrit encore peut changer pendant la conversion ; les entrées les plus récentes peuvent manquer et le dernier enregistrement peut être tronqué. Convertissez un journal tourné et fermé lorsque vous avez besoin d’une sortie complète.
• Le fichier est-il corrompu ou tronqué ? Vérifiez la fin du journal pour une ligne partiellement écrite.

Les dates sont incorrectes, décalées ou le jour et le mois sont inversés

Le journal a été écrit par un serveur avec une locale Windows différente de celle de la session effectuant la conversion. 20.01.2026 et 01/20/2026 décrivent le même moment, mais seulement si les deux parties s’accordent sur le format.

# le journal vient d’un serveur allemand
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns-berlin.log" -InputCulture 'de-DE'

Définissez explicitement -InputCulture dans les tâches planifiées plutôt que de compter sur la culture du compte qui les exécute. Si la sortie doit être lisible par une machine, ajoutez -OutputCulture 'sv-SE'. Plus de détails dans Paramètres et options.

Tout se retrouve dans une seule colonne après l’import

Mauvais délimiteur. Le module écrit ; par défaut ; votre consommateur attendait , (ou inversement).

Relancez la conversion avec le délimiteur attendu par le consommateur :

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -Delimiter ","

…ou indiquez au programme d’importation quel délimiteur utilise le fichier — dans Excel via Données → À partir du texte/CSV, dans PowerShell via Import-Csv -Delimiter ';'.

« Accès refusé »

• Le répertoire des journaux DNS nécessite généralement des droits administratifs. Lancez PowerShell en mode administrateur, ou exécutez la tâche planifiée avec un compte ayant les droits.
• Vérifiez aussi les droits d’écriture sur le répertoire de sortie, pas seulement les droits de lecture sur le journal.
• Pour les chemins SMB/UNC : une tâche exécutée en tant que SYSTEM s’authentifie sur le réseau en tant que compte ordinateur. Accordez les droits de partage et NTFS à ce compte ordinateur (ou au groupe Domain Controllers), ou utilisez un compte de service dédié.
• Si -RemoveSourceFile échoue à la fin d’une exécution par ailleurs réussie, le compte peut lire le journal mais pas le supprimer.

Le traitement est très lent

1. Commencez par le disque — la conversion est limitée par les E/S. Un volume occupé ou un chemin réseau lent domine le temps d’exécution.
2. Utilisez -NoDetailsParsing si vous n’avez pas besoin du JSON détaillant les paquets ; sur des journaux très détaillés, cela économise 30 à 50 %.
3. Utilisez -ContextFilter Packet pour écrire moins.
4. Divisez les journaux énormes avec la rotation des journaux du serveur DNS au lieu de convertir un seul fichier gigantesque.
5. Envisagez une exclusion antivirus pour le répertoire des journaux.

Plus d’infos dans Performance.

La sortie compressée est plus volumineuse que prévu

Les journaux avec un contenu très diversifié — de nombreux domaines uniques, de nombreux clients distincts — se compressent moins bien que les journaux répétitifs. C’est normal. ZIP réalise généralement une réduction substantielle ; si ce n’est pas le cas, vérifiez si la colonne Details gonfle le fichier et si vous en avez vraiment besoin.

Les statistiques ne correspondent pas à ce que j’attendais

• Confirmez que vous avez utilisé -OutputType Both ou -OutputType Statistic. Avec -OutputType CSV, aucun fichier de statistiques n’est généré.
• Count est un total, pas un compte distinct. Un client demandant le même nom 500 fois contribue pour 500. C’est la cause la plus fréquente du « ce nombre ne peut pas être correct ».
• Les statistiques sont regroupées par jour. Un journal couvrant deux jours produit des lignes pour les deux.
• Si ComputerName est vide dans les fichiers de statistiques, -ComputerName n’a pas été défini lors de la conversion.

La tâche planifiée fonctionne en mode interactif mais pas en tâche

Presque toujours l’une des trois causes :

• Module introuvable. SYSTEM avec -NoProfile ne voit que les chemins de modules machine-wide. Installez le module machine-wide ou ajoutez un Import-Module DNSServer.DebugLogParser explicite dans l’action de la tâche.
• Mauvaise culture. La locale du compte de la tâche diffère de la vôtre. Définissez explicitement -InputCulture et -OutputCulture.
• Politique d’exécution ou script non signé. Adaptez le -ExecutionPolicy de la tâche à votre politique de signature, et débloquez les fichiers copiés depuis ailleurs.

Exécutez manuellement la ligne de commande exacte de la tâche dans le même contexte (par exemple avec PsExec en tant que SYSTEM) pour reproduire le problème.

Signaler un problème

Si rien de tout cela ne vous aide :

1. Mettez à jour vers la dernière version du module et réessayez.

2. Cherchez dans les issues GitHub le même symptôme.

3. Rassemblez les diagnostics :

   $PSVersionTable
   Get-Module DNSServer.DebugLogParser -ListAvailable | Select-Object Name, Version, Path
   Get-Culture
   

   ainsi que la commande exacte que vous avez lancée, le message d’erreur complet incluant la pile d’appels, et — si vous pouvez le partager — un petit extrait anonymisé du journal reproduisant le problème.

4. Ouvrez une nouvelle issue avec ces informations.

8 - Référence des commandes du module

En cliquant sur une commande, tu seras dirigé vers une page détaillée qui fournit des informations complètes sur la commande, y compris sa syntaxe, ses paramètres, des exemples, ainsi que des notes ou astuces supplémentaires pour son utilisation.

8.1 - Convert-DNSDebugLogFile

SYNOPSIS

Transforme les journaux de débogage DNS de Windows Server en un format CSV structuré pour analyse et rapports.

SYNTAX

__AllParameterSets

Convert-DNSDebugLogFile [-InputFile] <string[]> [[-OutputFile] <string>] [[-Delimiter] <string>]
 [[-ComputerName] <string>] [[-OutputType] <string>] [[-ContextFilter] <string[]>]
 [[-InputCulture] <cultureinfo>] [[-OutputCulture] <cultureinfo>] [-SkipHeaderValidation]
 [-RemoveSourceFile] [-CompressOutput] [-NoDetailsParsing] [-WhatIf] [-Confirm]

ALIASES

Cette cmdlet possède les alias suivants,

DESCRIPTION

Convertit les fichiers journaux de débogage DNS de Windows Server en données CSV structurées pouvant être analysées dans Excel, Power BI, bases de données SQL ou outils SIEM. Conçu pour l’analyse de sécurité, la surveillance des performances, le dépannage et les rapports de conformité.

La cmdlet analyse les journaux de débogage DNS et génère une sortie CSV cohérente pour l’analyse. La sortie CSV contient 18 colonnes, dont une colonne Information pour le texte événementiel/diagnostique, une colonne JSON optionnelle Details pour les blocs de détails des paquets, et une colonne ComputerName toujours présente (vide sauf si spécifiée).

FONCTIONNALITÉS CLÉS :

• Traitement en streaming évitant de charger le fichier complet en mémoire (adapté aux très gros journaux)
• Analyse haute performance optimisée pour les gros fichiers (100 Mo+)
• Délimiteur CSV personnalisable (par défaut : point-virgule)
• Résumés statistiques optionnels avec métriques agrégées
• Filtrage contextuel (Packet, Event, Note et autres contextes) pour cibler certains types d’entrées
• Analyse et formatage des dates sensibles à la culture pour serveurs internationaux
• Support du pipeline pour traitement par lots de plusieurs fichiers
• Compression optionnelle des fichiers de sortie (format ZIP)
• Suppression automatique optionnelle des fichiers sources après traitement
• Validation des en-têtes pour garantir l’intégrité des données

FORMAT DE SORTIE : La colonne ComputerName est toujours incluse à la fin de chaque enregistrement. Si le paramètre -ComputerName n’est pas spécifié, la colonne restera vide. Cela garantit une structure de sortie cohérente pour les scénarios de consolidation multi-serveurs.

PERFORMANCE : Optimisé avec StreamReader/StreamWriter et tampons de 64 Ko, traitement en streaming pour une gestion mémoire efficace des gros fichiers, opérations sur chaînes au lieu de regex, génération manuelle du CSV, et collecte efficace des statistiques via tables de hachage.

COMPATIBILITÉ :

• PowerShell 5.1+ (éditions Desktop et Core)
• Windows Server 2016+
• Formats de journaux DNS Server 2012 R2 à 2025

EXAMPLES

EXEMPLE 1

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log"

Convertit le journal de débogage DNS avec les paramètres par défaut (fichiers de données et statistiques avec délimiteur point-virgule). Sortie :

• C:\Logs\dns.csv
• C:\Logs\dns_Statistic.csv
• C:\Logs\dns_PacketStatistic.csv

EXEMPLE 2

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -OutputType CSV

Génère uniquement le fichier de données sans statistiques. Sortie : C:\Logs\dns.csv

EXEMPLE 3

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -OutputType Statistic

Génère uniquement les fichiers statistiques avec métriques agrégées. Sortie :

• C:\Logs\dns_Statistic.csv
• C:\Logs\dns_PacketStatistic.csv

EXEMPLE 4

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -OutputFile "C:\Output\parsed.csv"

Convertit le journal vers un emplacement de sortie personnalisé. Sortie : C:\Output\parsed.csv

EXEMPLE 5

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -Delimiter "," -ComputerName "DNS01" -OutputType Both

Convertit avec délimiteur virgule et ajoute la colonne ComputerName avec la valeur “DNS01”. Sortie :

• C:\Logs\dns.csv
• C:\Logs\dns_Statistic.csv
• C:\Logs\dns_PacketStatistic.csv

EXEMPLE 6

PS C:\> Get-ChildItem "C:\Logs\*.log" | Convert-DNSDebugLogFile -OutputType Both

Traitement par lots de plusieurs fichiers journaux DNS via pipeline. Sortie : Pour chaque fichier .log, génère des fichiers .csv et _statistic.csv

EXEMPLE 7

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput

Convertit et compresse la sortie en archive ZIP. Sortie : C:\Logs\dns.zip (contenant dns.csv + fichiers statistiques)

EXEMPLE 8

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -RemoveSourceFile -Verbose

Convertit le journal et supprime le fichier source après traitement réussi. La sortie détaillée confirme la suppression du fichier.

EXEMPLE 9

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -InputCulture 'de-DE' -OutputCulture 'en-US'

Analyse le format de date allemand (JJ.MM.AAAA) et produit en format US (MM/JJ/AAAA). À utiliser lors du traitement de journaux provenant de serveurs avec des paramètres régionaux différents.

EXEMPLE 10

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -ContextFilter 'Packet'

Convertit uniquement les entrées de paquets de requêtes/réponses DNS, excluant les entrées EVENT et Note. Utile pour se concentrer sur le trafic DNS réel.

EXEMPLE 11

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -ContextFilter 'Packet','Event'

Convertit à la fois les paquets DNS et les événements serveur, excluant Note et autres entrées. Utile pour analyser le trafic DNS avec le contexte des événements serveur.

EXEMPLE 12

PS C:\> Get-ChildItem "C:\Logs\*.log" | Convert-DNSDebugLogFile -RemoveSourceFile -CompressOutput

Archivage automatique des journaux : traite tous les journaux, compresse la sortie et supprime les fichiers sources. Idéal pour les pipelines de traitement de journaux planifiés.

EXEMPLE 13

PS C:\> Convert-DNSDebugLogFile -InputFile "C:\Logs\large-dns.log" -NoDetailsParsing

Traite un gros fichier journal avec l’analyse des détails désactivée pour une performance maximale. Les blocs de détails PACKET sont ignorés, la colonne Details reste vide. À utiliser pour les très gros fichiers quand la structure détaillée des paquets n’est pas nécessaire.

PARAMÈTRES

-CompressOutput

Compresse les fichiers CSV de sortie dans une archive ZIP après création.

Crée un fichier .zip contenant les fichiers CSV générés, puis supprime les CSV non compressés. Le fichier ZIP est créé dans le même répertoire que le CSV de sortie avec le même nom de base.

Avantages :

• Réduit significativement l’espace disque (les fichiers CSV se compressent généralement à plus de 90 %)
• Simplifie la gestion et l’archivage des fichiers
• Adapté au stockage à long terme

Exemple : Le fichier ‘dns.log’ génère ‘dns.csv’ compressé en ‘dns.zip’, puis ‘dns.csv’ est supprimé.

Type: SwitchParameter
DefaultValue: False
SupportsWildcards: false
Aliases: []
ParameterSets:
- Name: (All)
  Position: Named
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-ComputerName

Spécifie la valeur de la colonne ComputerName dans la sortie CSV. La colonne ComputerName est toujours présente dans la sortie - si ce paramètre n’est pas spécifié, la colonne sera vide.

Utilisez-le lors de la consolidation de journaux de plusieurs serveurs DNS pour identifier le serveur source dans les ensembles de données combinés.

Note : Ce n’est PAS un paramètre de télécommande. Il sert uniquement à étiqueter la sortie. Si vous indiquez -InputFile vers un chemin UNC, le fichier est lu depuis ce chemin (aucune exécution distante WinRM n’est effectuée).

Type: String
DefaultValue: ''
SupportsWildcards: false
Aliases:
- Server
- DNSServer
- HostName
ParameterSets:
- Name: (All)
  Position: 3
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-Confirm

Vous invite à confirmer avant d’exécuter la cmdlet.

Si spécifié, demande confirmation avant :

• Le traitement de chaque fichier journal de débogage DNS
• La suppression des fichiers sources (lorsque -RemoveSourceFile est spécifié)
• L’écrasement des fichiers de sortie existants

Utile pour un traitement interactif lorsque vous souhaitez contrôler les fichiers traités.

Type: SwitchParameter
DefaultValue: ''
SupportsWildcards: false
Aliases:
- cf
ParameterSets:
- Name: (All)
  Position: Named
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-ContextFilter

Filtre les types d’entrées du journal à inclure dans la sortie. Accepte une ou plusieurs valeurs.

Les journaux de débogage DNS contiennent différents types de contexte :

• PACKET : Informations sur les paquets de requêtes et réponses DNS (données principales)
• EVENT : Événements du serveur DNS (ex. : « Le serveur DNS a démarré. »)
• Note : Notes et avertissements diagnostiques (ex. : erreurs de socket, états internes)
• DSPoll, Init, Lookup, Recurse, Remote, Tombstone : Types de contexte supplémentaires

Valeurs valides :

• ‘All’ : Inclut tous les types de contexte (par défaut)
• ‘Packet’ : Inclut uniquement les entrées PACKET (requêtes/réponses DNS)
• ‘Event’ : Inclut uniquement les entrées EVENT (événements serveur)
• ‘Note’ : Inclut uniquement les entrées Note (informations diagnostiques)
• Toute combinaison : Spécifiez plusieurs valeurs pour inclure des types de contexte spécifiques

Par défaut : All

Exemples :

• ‘Packet’ filtre uniquement le trafic DNS
• ‘Packet’,‘Event’ inclut à la fois le trafic DNS et les événements serveur
• ‘Note’,‘Event’ inclut les notes diagnostiques et les événements serveur

Note : En filtrant sur ‘Event’ ou ‘Note’, seules les colonnes DateTime, ThreadId, Context et Information contiendront des données. Les autres colonnes (Protocol, ClientIP, etc.) seront vides.

Type: String[]
DefaultValue: "@('All')"
SupportsWildcards: false
Aliases: []
ParameterSets:
- Name: (All)
  Position: 5
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-Delimiter

Spécifie le caractère délimiteur pour la sortie CSV.

Par défaut : point-virgule (;)

Alternatives courantes : virgule (,), tabulation (`t), barre verticale (|)

Utilisez le point-virgule dans les régions où la virgule est le séparateur décimal (Europe). Utilisez la virgule pour les outils CSV standard et bases de données qui attendent des valeurs séparées par des virgules.

Type: String
DefaultValue: ;
SupportsWildcards: false
Aliases: []
ParameterSets:
- Name: (All)
  Position: 2
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-InputCulture

Spécifie la culture/locale à utiliser pour analyser les valeurs date/heure dans le journal de débogage DNS.

Les journaux de débogage DNS utilisent le format de date de la locale Windows du serveur où le journal a été généré. Utilisez ce paramètre lors du traitement de journaux provenant de serveurs avec des paramètres régionaux différents.

Par défaut : culture actuelle

Exemples courants :

• ‘de-DE’ ou ‘de-AT’ : format allemand (JJ.MM.AAAA ou JJ/MM/AAAA)
• ’en-US’ : format US (MM/JJ/AAAA avec AM/PM)
• ’en-GB’ : format UK (JJ/MM/AAAA avec heure 24h)
• ‘sv-SE’ : format suédois/ISO (AAAA-MM-JJ)

Type: CultureInfo
DefaultValue: '[System.Globalization.CultureInfo]::CurrentCulture'
SupportsWildcards: false
Aliases: []
ParameterSets:
- Name: (All)
  Position: 6
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-InputFile

Spécifie le chemin vers le fichier journal de débogage DNS à analyser. Supporte les tableaux pour traiter plusieurs fichiers.

Accepte l’entrée du pipeline depuis Get-ChildItem ou autres cmdlets produisant des fichiers.

Type: String[]
DefaultValue: ''
SupportsWildcards: false
Aliases:
- FullName
- FilePath
- InputPath
- File
- Path
ParameterSets:
- Name: (All)
  Position: 0
  IsRequired: true
  ValueFromPipeline: true
  ValueFromPipelineByPropertyName: true
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-NoDetailsParsing

Ignore l’analyse des blocs de détails PACKET en format JSON structuré.

Si spécifié, les enregistrements PACKET avec blocs de détails auront la ligne d’info TCP/UDP dans la colonne Information, mais la colonne Details restera vide. Cela améliore significativement la performance de traitement pour les gros fichiers journaux quand l’analyse détaillée des paquets n’est pas nécessaire.

Utilisez ce commutateur lorsque :

• Vous traitez des fichiers journaux très volumineux (100 Mo+) et n’avez besoin que des informations de requête basiques
• La structure détaillée (flags Message, sections DNS) n’est pas requise pour l’analyse
• La vitesse d’analyse prime sur la complétude des données

Impact sur la performance : Peut améliorer la vitesse de traitement de 30 à 50 % pour les journaux avec de nombreux blocs de détails PACKET.

Type: SwitchParameter
DefaultValue: False
SupportsWildcards: false
Aliases: []
ParameterSets:
- Name: (All)
  Position: Named
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-OutputCulture

Spécifie la culture/locale à utiliser pour formater les valeurs date/heure dans les fichiers CSV de sortie.

Contrôle la manière dont les valeurs DateTime sont écrites dans le CSV. Utilisez-le lorsque les fichiers CSV seront consommés par des applications ou systèmes avec des paramètres régionaux spécifiques.

Par défaut : culture actuelle

Exemples courants :

• ’en-US’ : format US (MM/JJ/AAAA)
• ‘de-DE’ : format allemand (JJ.MM.AAAA)
• ‘sv-SE’ ou InvariantCulture : format ISO (AAAA-MM-JJ) pour compatibilité maximale

Type: CultureInfo
DefaultValue: '[System.Globalization.CultureInfo]::CurrentCulture'
SupportsWildcards: false
Aliases: []
ParameterSets:
- Name: (All)
  Position: 7
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-OutputFile

Spécifie le chemin du fichier CSV de sortie. Si non spécifié, utilise le nom du fichier d’entrée avec extension .csv dans le même répertoire que le fichier d’entrée.

Important : Doit être un chemin de fichier, pas un répertoire. Si vous souhaitez utiliser le répertoire du fichier d’entrée avec un nom personnalisé, spécifiez le chemin complet incluant le nom de fichier.

Type: String
DefaultValue: ''
SupportsWildcards: false
Aliases:
- Output
- Destination
- OutFile
- OutputPath
ParameterSets:
- Name: (All)
  Position: 1
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-OutputType

Spécifie le type de sortie à générer.

Valeurs valides :

• ‘CSV’ : Génère uniquement le fichier de données avec toutes les entrées analysées
• ‘Statistic’ : Génère uniquement les fichiers statistiques avec métriques agrégées
• ‘Both’ : Génère à la fois les fichiers de données et statistiques (par défaut)

Par défaut : Both

Lorsque les statistiques sont générées, deux fichiers distincts sont créés :

• ‘_Statistic.csv’ : Comptages résumés par type de contexte et par jour (Date, Context, Count, ComputerName)
• ‘_PacketStatistic.csv’ : Comptages détaillés PACKET par jour selon IP client, protocole, direction, et type de requête (Date, ClientIP, Protocol, Direction, QuestionType, Count, ComputerName)

Type: String
DefaultValue: Both
SupportsWildcards: false
Aliases: []
ParameterSets:
- Name: (All)
  Position: 4
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-RemoveSourceFile

Supprime le fichier journal de débogage DNS source après un traitement réussi.

Utilisez ceci pour les pipelines automatisés de traitement de journaux ou la gestion d’espace disque. Le fichier source est supprimé uniquement si le traitement se termine avec succès et que tous les fichiers de sortie sont créés.

Sécurité : Ne peut pas être utilisé avec -SkipHeaderValidation pour éviter la suppression accidentelle de fichiers invalides.

Avertissement : Les fichiers sources sont supprimés définitivement. Assurez-vous que les fichiers de sortie sont valides avant d’utiliser cette option.

Type: SwitchParameter
DefaultValue: False
SupportsWildcards: false
Aliases: []
ParameterSets:
- Name: (All)
  Position: Named
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-SkipHeaderValidation

Ignore la validation de l’en-tête du journal de débogage DNS.

Par défaut, la cmdlet vérifie que les fichiers d’entrée ont un en-tête valide de journal de débogage DNS Server. Utilisez ce commutateur pour traiter des fichiers sans validation, ce qui peut être utile pour :

• Formats de journaux modifiés ou personnalisés
• Dépannage de problèmes de validation
• Journaux non standard ou pré-traités

Avertissement : Peut entraîner des erreurs de traitement si le fichier n’est pas un journal DNS valide.

Type: SwitchParameter
DefaultValue: False
SupportsWildcards: false
Aliases: []
ParameterSets:
- Name: (All)
  Position: Named
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

-WhatIf

Montre ce qui se passerait si la cmdlet était exécutée. La cmdlet n’est pas exécutée.

Si spécifié, affiche des informations détaillées sur les opérations qui seraient effectuées sans les exécuter réellement. Utile pour :

• Prévisualiser les fichiers qui seraient traités
• Vérifier les chemins des fichiers de sortie avant traitement
• Tester les scripts avant exécution en production

Type: SwitchParameter
DefaultValue: ''
SupportsWildcards: false
Aliases:
- wi
ParameterSets:
- Name: (All)
  Position: Named
  IsRequired: false
  ValueFromPipeline: false
  ValueFromPipelineByPropertyName: false
  ValueFromRemainingArguments: false
DontShow: false
AcceptedValues: []
HelpMessage: ''

CommonParameters

Cette cmdlet prend en charge les paramètres communs : -Debug, -ErrorAction, -ErrorVariable, -InformationAction, -InformationVariable, -OutBuffer, -OutVariable, -PipelineVariable, -ProgressAction, -Verbose, -WarningAction, et -WarningVariable. Pour plus d’informations, voir about_CommonParameters.

INPUTS

System.String[]

NOTES

Version : 1.7.2.1 Auteur : Andi Bellstedt, Copilot, Patrick Charbonnier (Silent Waters IT Consulting S.L.) Date : 2026-07-24 Mots-clés : Microsoft Windows Server, DNSServer, DNS, DebugLog, LogParser

RELATED LINKS

• github.com/AndiBellstedt/DNSServer.DebugLogParser

9 - Exemples d'utilisation

Voici des exemples un peu plus approfondis et contextuels. Si vous souhaitez uniquement l’utilisation des commandes du module, consultez la référence des commandes.

9.1 - Flux de travail d'analyse de sécurité avec SQL Server

Cet exemple montre un flux de travail pratique pour l’analyse de sécurité : analyser un journal de débogage DNS avec Convert-DNSDebugLogFile, importer le CSV généré dans SQL Server, et exécuter une requête qui met en évidence des volumes anormalement élevés de requêtes sur les enregistrements TXT.

Pour une meilleure interopérabilité, cet exemple écrit les horodatages dans un format proche de l’ISO en utilisant -OutputCulture 'sv-SE'.

Modules requis

Cet exemple utilise les modules PowerShell suivants :

• DNSServer.DebugLogParser
• SqlServer

Installe-les si besoin :

Install-Module -Name DNSServer.DebugLogParser -Scope CurrentUser
Install-Module -Name SqlServer -Scope CurrentUser

Scénario

Utilise ce flux de travail lorsque tu souhaites transférer les données analysées d’un journal de débogage DNS dans SQL Server afin de pouvoir :

• rechercher efficacement dans de grands ensembles de données
• créer des requêtes de détection répétables
• corréler l’activité entre plusieurs serveurs DNS
• conserver des données normalisées pour des investigations ultérieures

Résultat de l’étape de conversion

Convert-DNSDebugLogFile n’écrit pas directement dans SQL Server. Il crée d’abord un fichier CSV. Ce fichier CSV est le jeu de données importé dans la base.

Dans cet exemple :

• journal d’entrée : C:\Administration\Logs\DNS\dns.log
• CSV généré : C:\Administration\Logs\DNS\dns.csv
• table cible : dbo.DNSQueries

Créer la table cible

Exécute la commande suivante une fois dans SQL Server pour créer la table cible.

IF OBJECT_ID('dbo.DNSQueries', 'U') IS NULL
BEGIN
    CREATE TABLE dbo.DNSQueries (
        DateTime      datetime2(0)   NOT NULL,
        ThreadId      int            NULL,
        Context       nvarchar(20)   NULL,
        PacketId      int            NULL,
        Protocol      nvarchar(10)   NULL,
        Direction     nvarchar(10)   NULL,
        ClientIP      nvarchar(64)   NULL,
        Xid           nvarchar(16)   NULL,
        Type          nvarchar(16)   NULL,
        Opcode        nvarchar(16)   NULL,
        FlagsHex      nvarchar(16)   NULL,
        FlagsChar     nvarchar(16)   NULL,
        ResponseCode  nvarchar(32)   NULL,
        QuestionType  nvarchar(32)   NULL,
        QuestionName  nvarchar(512)  NULL,
        Information   nvarchar(max)  NULL,
        Details       nvarchar(max)  NULL,
        ComputerName  nvarchar(256)  NULL
    );
END;

Convertir le journal et importer le CSV

L’exemple PowerShell suivant réalise le flux complet :

1. importe les modules requis
2. convertit le journal de débogage DNS en CSV
3. charge le CSV généré
4. importe en masse les lignes dans SQL Server

# Requires -Modules DNSServer.DebugLogParser, SqlServer

Import-Module -Name DNSServer.DebugLogParser -ErrorAction Stop
Import-Module -Name SqlServer -ErrorAction Stop

$logPath = 'C:\Administration\Logs\DNS\dns.log'
$csvPath = 'C:\Administration\Logs\DNS\dns.csv'
$serverInstance = 'SQLServer'
$databaseName = 'DNSLogs'
$delimiter = ';'

$createTableSql = @'
IF OBJECT_ID('dbo.DNSQueries', 'U') IS NULL
BEGIN
    CREATE TABLE dbo.DNSQueries (
        DateTime      datetime2(0)   NOT NULL,
        ThreadId      int            NULL,
        Context       nvarchar(20)   NULL,
        PacketId      int            NULL,
        Protocol      nvarchar(10)   NULL,
        Direction     nvarchar(10)   NULL,
        ClientIP      nvarchar(64)   NULL,
        Xid           nvarchar(16)   NULL,
        Type          nvarchar(16)   NULL,
        Opcode        nvarchar(16)   NULL,
        FlagsHex      nvarchar(16)   NULL,
        FlagsChar     nvarchar(16)   NULL,
        ResponseCode  nvarchar(32)   NULL,
        QuestionType  nvarchar(32)   NULL,
        QuestionName  nvarchar(512)  NULL,
        Information   nvarchar(max)  NULL,
        Details       nvarchar(max)  NULL,
        ComputerName  nvarchar(256)  NULL
    );
END
'@

Convert-DNSDebugLogFile `
    -InputFile $logPath `
    -ComputerName 'DNS01' `
    -OutputType CSV `
    -OutputFile $csvPath `
    -Delimiter $delimiter `
    -OutputCulture 'sv-SE'

$rows = Import-Csv -Path $csvPath -Delimiter $delimiter

if (-not $rows) {
    throw "Le fichier CSV généré '$csvPath' ne contient aucune ligne."
}

$dataTable = [System.Data.DataTable]::new()
foreach ($columnName in $rows[0].PSObject.Properties.Name) {
    $null = $dataTable.Columns.Add($columnName, [string])
}

foreach ($row in $rows) {
    $dataRow = $dataTable.NewRow()
    foreach ($column in $dataTable.Columns) {
        $columnName = $column.ColumnName
        $dataRow[$columnName] = $row.$columnName
    }

    $null = $dataTable.Rows.Add($dataRow)
}

$connectionString = "Server=$serverInstance;Database=$databaseName;Integrated Security=True"
$connection = [System.Data.SqlClient.SqlConnection]::new($connectionString)

try {
    $connection.Open()

    $command = $connection.CreateCommand()
    $command.CommandText = $createTableSql
    $null = $command.ExecuteNonQuery()

    $bulkCopy = [System.Data.SqlClient.SqlBulkCopy]::new($connection)
    $bulkCopy.DestinationTableName = 'dbo.DNSQueries'

    foreach ($column in $dataTable.Columns) {
        $null = $bulkCopy.ColumnMappings.Add($column.ColumnName, $column.ColumnName)
    }

    $bulkCopy.WriteToServer($dataTable)
}
finally {
    $connection.Dispose()
}

Requête pour détecter une activité suspecte sur les enregistrements TXT

Une fois les données dans SQL Server, tu peux rechercher les clients qui émettent un nombre anormalement élevé de requêtes sur les enregistrements TXT.

SELECT
    ComputerName,
    ClientIP,
    QuestionName,
    COUNT(*) AS QueryCount
FROM dbo.DNSQueries
WHERE QuestionType = 'TXT'
GROUP BY
    ComputerName,
    ClientIP,
    QuestionName
HAVING COUNT(*) > 100
ORDER BY QueryCount DESC;

Si tu préfères exécuter la requête depuis PowerShell, utilise Invoke-Sqlcmd du module SqlServer :

$query = @'
SELECT
    ComputerName,
    ClientIP,
    QuestionName,
    COUNT(*) AS QueryCount
FROM dbo.DNSQueries
WHERE QuestionType = 'TXT'
GROUP BY
    ComputerName,
    ClientIP,
    QuestionName
HAVING COUNT(*) > 100
ORDER BY QueryCount DESC;
'@

Invoke-Sqlcmd `
    -ServerInstance 'SQLServer' `
    -Database 'DNSLogs' `
    -Query $query

Pourquoi les requêtes TXT sont intéressantes

Un volume élevé de requêtes sur les enregistrements TXT peut valoir la peine d’être examiné car cela peut indiquer :

• un tunnel DNS
• une exfiltration de données via DNS
• un abus des enregistrements TXT par des malwares ou des outils
• des clients anormalement bruyants ou mal configurés

Cette requête n’est qu’un point de départ. En production, tu devrais ajuster le seuil et ajouter des filtres adaptés à ton environnement.

Notes opérationnelles

• Import-Csv charge le fichier complet en mémoire. Pour des exports de journaux très volumineux, envisage une approche en streaming plutôt que de construire un DataTable complet.
• Garde -ComputerName dans l’étape de conversion pour que les enregistrements restent attribuables après ingestion centralisée.
• Utilise un délimiteur et une culture cohérents lors de l’export et de l’import.
• Vérifie la rétention, l’indexation et le contrôle d’accès dans SQL Server avant d’utiliser ce flux pour un stockage à long terme.

9.2 - Utilisation pratique dans un environnement de domaine (collection et conversion pilotées par GPO)

Ce document présente un exemple pratique complet d’exécution de DNSServer.DebugLogParser dans un environnement de domaine Active Directory, axé sur la conversion des journaux de débogage du serveur DNS Windows sur les contrôleurs de domaine.

Cet exemple est accompagné d’une archive ZIP, qui fournit les artefacts de stratégie utilisés pour mettre en œuvre le flux de travail décrit ici.
Les artefacts les plus pertinents sont le manifest de sauvegarde, le rapport GPO, le Files.xml, le Set-DNSServerDebugLogging.ps1, et le ScheduledTasks.xml.

Scénario

• Plusieurs contrôleurs de domaine (DC) hébergent le rôle de serveur DNS.
• Le journal de débogage DNS est activé et configuré de manière cohérente sur chaque DC via une tâche planifiée (écriture des fichiers journaux dans C:\Administration\Logs\DNSServer).
• Un processus centralisé convertit les journaux en CSV pour :
  • l’analyse de sécurité
  • le reporting opérationnel
  • le dépannage
  • la conformité / conservation

Résultats visés

• Paramètres de conversion cohérents sur tous les DC
• Emplacement et nommage des fichiers de sortie prévisibles
• Compression optionnelle pour réduire l’espace de stockage
• Sorties statistiques optionnelles pour des synthèses quotidiennes rapides
• Risque minimal côté hôte, avec des considérations explicites de relance et nettoyage

Architecture suggérée

Modèle de collecte : conversion locale + collecte centrale

1. Chaque DC écrit les journaux de débogage DNS sur disque avec rotation activée.
2. Chaque DC convertit les fichiers *.log archivés en CSV de données et CSV statistiques, puis compresse les sorties en *.zip selon un planning (Planificateur de tâches).
3. Les sorties sont écrites à côté des fichiers journaux pour garder le pipeline simple.
4. Un serveur central collecte les fichiers *.zip, par exemple via ingestion de partage de fichiers, copie planifiée, forwarder SIEM ou collecteur basé agent.

Ce modèle minimise les lectures réseau de gros fichiers journaux bruts et maintient l’analyse proche des données.

Flux de travail GPO

Le flux de travail est mis en œuvre via la stratégie de groupe (configuration ordinateur) pour garantir des paramètres cohérents sur tous les contrôleurs de domaine.

Implémentation de référence incluse dans ce dépôt (rapport GPO) :

• Nom d’archive/rapport : T0-C-Analytics-DNSDebugLogging
• ID de sauvegarde : {2B6F16BC-0E7C-4787-83D7-2854FED882EE}
• Cible de lien GPO : corp.company.com/Domain Controllers
• Filtre d’élément (utilisé pour le déploiement des fichiers et les tâches planifiées) : s’applique uniquement si C:\Windows\System32\dns.exe existe

1) Prérequis (dossiers + module)

La sauvegarde fournie suppose que ces dossiers existent déjà. Ajoutez des éléments GPP séparés si vous souhaitez que le déploiement les crée automatiquement :

• C:\Administration\Scripts
• C:\Administration\Logs\DNSServer

La sauvegarde fournie suppose également que Convert-DNSDebugLogFile est déjà disponible sur les DC. La tâche de conversion lance Windows PowerShell 5.1 avec -NoProfile et n’importe pas explicitement le module, donc celui-ci doit être installé dans un chemin de module PowerShell machine-wide visible par LocalSystem. Approches recommandées :

• Installer DNSServer.DebugLogParser sur les DC. Par exemple, depuis PowerShell Gallery (si la politique le permet).
• Déployer le module via un repo interne / partage de fichiers pour qu’il soit détectable dans $env:PSModulePath
• Ajouter un Import-Module explicite à l’action de la tâche si vous souhaitez un chargement déterministe

2) Déployer le script de configuration du journal de débogage (GPP Files)

La GPO déploie le script :

• Source (dans SYSVOL via GPP) : %GptPath%\Preferences\Files\Set-DNSServerDebugLogging.ps1
• Cible (sur chaque DC) : C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1

Cela est implémenté dans l’élément de préférence GPP Files dans Files.xml.

3) Tâche planifiée : configurer le journal de débogage DNS

La GPO crée une tâche planifiée nommée Set-DNSServerDebugLogging.

• Contexte de sécurité dans la sauvegarde fournie : SYSTEM avec type de connexion S4U
• Déclencheur dans la sauvegarde fournie : quotidien (heure de début 2025-03-01T00:00:01)
• Action dans ScheduledTasks.xml :
  • powershell.exe -ExecutionPolicy RemoteSigned -command " & { C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1 }"
  • Répertoire de travail : C:\Administration\Scripts

Le script Set-DNSServerDebugLogging.ps1 configure le journal de débogage DNS via Get-DnsServerDiagnostics / Set-DnsServerDiagnostics et notamment :

• Active la journalisation dans un fichier + rotation
• Écrit dans : C:\Administration\Logs\DNSServer\DnsDebugLog_<COMPUTERNAME>.<Domain>_.log
• Utilise une taille de rotation de 10 Mo par fichier
• Capture principalement l’activité liée aux requêtes (requêtes + notifications + mises à jour + transactions de questions) et exclut la journalisation complète des paquets

4) Tâche planifiée : convertir les journaux de débogage archivés en CSV compressé

La GPO crée une tâche planifiée nommée Convert-DNSDebugLogs.

• Contexte de sécurité dans la sauvegarde fournie : SYSTEM avec type de connexion InteractiveToken
• Déclencheur dans la sauvegarde fournie : quotidien (heure de début 2026-01-01T00:30:00)
• Répertoire de travail : C:\Administration\Logs\DNSServer
• Action dans ScheduledTasks.xml (formaté pour la lisibilité) :

Get-ChildItem .\*.log |
  Sort-Object lastwritetime, Name -Descending |
  Select-Object -Skip 1 |
  Convert-DNSDebugLogFile `
    -ComputerName $env:COMPUTERNAME `
    -Delimiter ';' `
    -OutputType Both `
    -ContextFilter Packet `
    -OutputCulture sv-SE `
    -CompressOutput

Notes de conception :

• Select-Object -Skip 1 évite intentionnellement de traiter le fichier journal le plus récent (actif). Convert-DNSDebugLogFile peut lire un journal que le serveur DNS a actuellement ouvert, mais ce fichier change pendant la lecture : la sortie peut manquer les entrées les plus récentes ou se terminer par un enregistrement tronqué, et deux exécutions ne produisent pas des résultats identiques. Ignorer le fichier actif maintient la sortie planifiée reproductible.
• Cela signifie que les données actuelles ne sont exportées qu’après la rotation ; sur les DC à faible volume, le journal actif peut rester non traité plus d’un jour. Réduisez la taille de rotation si ce délai est trop long pour votre cas d’usage.
• Parce que Convert-DNSDebugLogFile utilise par défaut -OutputFile « même dossier, même nom, .csv », les sorties se trouvent à côté des entrées *.log.
• Avec -CompressOutput, chaque journal traité produit un *.zip et les CSV intermédiaires sont supprimés.
• À moins d’archiver ou supprimer les fichiers *.log traités, les exécutions ultérieures retraiteront tous les journaux non actifs.
• La tâche génère une erreur si $Error.Count -gt 0 pour signaler un échec.

5) Ingestion centrale

Options (choisir une) :

• Ingestion via partage de fichiers : le DC écrit (ou copie) C:\Administration\Logs\DNSServer\*.zip vers \\fileserver\share\dns\$env:COMPUTERNAME\... (accorder les droits de partage et NTFS aux comptes ordinateurs DC ou au groupe Domain Controllers si la tâche s’exécute en SYSTEM)
• Modèle pull : un job central lit \\dc\C$\Administration\Logs\DNSServer\*.zip (moins recommandé ; nécessite les partages admin)
• Forwarder agent : pipeline SIEM / journal qui expédie les sorties *.zip

Considérations opérationnelles

• Moindre privilège : les tâches s’exécutent en SYSTEM ; assurez-vous que les dossiers locaux sont accessibles en écriture et que toute cible UNC accorde l’accès au compte ordinateur si utilisée.
• Politique de signature : les deux tâches utilisent -ExecutionPolicy RemoteSigned ; signez ou débloquez le script et le module déployés selon votre politique.
• Utilisation disque : -CompressOutput aide significativement, mais ce flux ne supprime pas les journaux sources ; planifiez la conservation et le nettoyage.
• Comportement de retraitement : sauf archivage ou suppression des journaux traités, la tâche de conversion retraitera chaque fichier *.log non actif lors des exécutions ultérieures. C’est simple et robuste, mais cela peut écraser les sorties et créer des doublons en aval si votre collecteur ne déduplique pas.
• Consolidation multi-DC : -ComputerName $env:COMPUTERNAME est inclus pour que les jeux de données consolidés restent traçables. Notez que -ComputerName ne fait que marquer la sortie — il n’établit aucune connexion distante.
• Partages réseau : Convert-DNSDebugLogFile peut lire les journaux sources depuis des chemins SMB/UNC, mais convertir localement et expédier les résultats compressés reste la meilleure pratique pour les gros journaux bruts. Si vous utilisez un chemin UNC, rappelez-vous qu’une tâche s’exécutant en SYSTEM s’authentifie sur le réseau en tant que compte ordinateur et nécessite les droits de partage et NTFS.
• Format de date : -OutputCulture sv-SE est utilisé délibérément pour que les horodatages s’écrivent sous la forme 2026-01-20 23:00:16. Ce format est lu sans indication par SQL Server, Power BI et la plupart des outils d’import, indépendamment de la locale du DC qui a produit le journal.
• Validation : la validation de l’en-tête reste activée car la tâche n’utilise pas -SkipHeaderValidation (recommandé).

Valider et adapter (avec le ZIP)

Utilisez l’archive ZIP comme implémentation de référence, puis alignez les aspects suivants à votre environnement :

• Portée cible : quels DC / OU reçoivent la stratégie
• Identité d’exécution : confirmez que les deux tâches planifiées utilisent le type de connexion prévu (S4U vs InteractiveToken) ou normalisez-les selon votre standard
• Création des dossiers : décidez si C:\Administration\Scripts et C:\Administration\Logs\DNSServer sont pré-créés ailleurs ou doivent être créés par des éléments GPP supplémentaires
• Chemins : confirmez que C:\Administration\Scripts et C:\Administration\Logs\DNSServer correspondent à vos standards
• Conservation : décidez si vous conservez les journaux bruts et pour combien de temps (surtout si vous activez les options de nettoyage)
• Ingestion : confirmez où les sorties CSV/ZIP sont écrites et comment elles sont collectées centralement

Si vous souhaitez valider la configuration exacte de la GPO sans l’importer, les sources autoritaires dans ce dépôt sont :

• manifest.xml pour les métadonnées de sauvegarde
• gpreport.xml pour le rapport complet lisible
• Files.xml pour le déploiement des fichiers
• Set-DNSServerDebugLogging.ps1 pour le contenu du script
• ScheduledTasks.xml pour les tâches planifiées

9.3 - Exemple de tâche planifiée

Ce script crée une tâche planifiée Windows qui s’exécute tous les jours à 2h00 du matin. Il importe le module et traite tous les fichiers journaux dans le dossier où le script est exécuté (dans cet exemple “C:\Administration\Logs\DNS”). Le processus compresse la sortie dans des fichiers ZIP et supprime les originaux pour maintenir la propreté.

$actionParams = @{
    Execute = "powershell.exe"
    Argument = '-ExecutionPolicy RemoteSigned -Command "Import-Module DNSServer.DebugLogParser; Get-ChildItem .\*.log | Sort-Object lastwritetime, Name -Descending | Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME -Delimiter \";\" -OutputType Both -ContextFilter Packet -OutputCulture sv-SE -CompressOutput"'
    WorkingDirectory = "C:\Administration\Logs\DNS"
}
$Action = New-ScheduledTaskAction @actionParams

$Trigger = New-ScheduledTaskTrigger -Daily -At "2:00AM"

Register-ScheduledTask -TaskName "Process DNS Logs" -Action $Action -Trigger $Trigger -Description "Convert DNS debug logs to CSV daily"