Über diese Dokumentation

• 1: Übersicht
• 2: Ausgabeformate
• 3: Parameter und Optionen
• 4: Performance
• 5: Integration mit Analysetools
• 6: Operative Best Practices
• 7: Fehlerbehebung
• 8: Modulbefehle Referenz
• 8.1: Convert-DNSDebugLogFile
• 9: Anwendungsbeispiele
• 9.1: Geplantes Aufgaben-Beispiel
• 9.2: Praktische Anwendung in einer Domänenumgebung (GPO-gesteuerte Sammlung und Konvertierung)
• 9.3: Sicherheitsanalyse-Workflow mit SQL Server

1 - Übersicht

Windows DNS Server kann ein Debug-Log schreiben. Es ist eine Textdatei, die für Menschen lesbar ist und an einem stark genutzten Domänencontroller täglich um mehrere hundert Megabyte wächst. Diese Kombination macht sie nahezu nutzlos, sobald du eine Frage beantworten willst wie „Welcher Client hat diese Domain letzte Nacht 40.000 Mal abgefragt?“

DNSServer.DebugLogParser verwandelt diese Textdatei in eine CSV-Tabelle. Eine Logzeile wird zu einer Zeile mit benannten Spalten, sodass du sie in Excel öffnen, in Power BI laden, massenhaft in SQL Server einfügen oder an dein SIEM schicken kannst.

Das Modul enthält einen einzigen Befehl:

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

Das ist der ganze Einstiegspunkt. Alles andere auf dieser Seite dreht sich darum, es im großen Stil, nach Zeitplan und über mehrere Server hinweg zu machen.

Wie ein DNS-Debug-Log aussieht

Ein roher Eintrag ist eine einzelne Zeile mit Positionsfeldern, einige davon in Klammern:

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)

Nach der Umwandlung ist dasselbe Ereignis eine CSV-Zeile, die du filtern und sortieren kannst:

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

Beachte zwei Dinge, die das rohe Format erschwert und der Parser für dich erledigt:

• Der abgefragte Name ist im DNS-Wire-Format gespeichert, (3)odc(9)officeapps(4)live(3)com(0), und wird zu einem normalen FQDN.
• Ein einzelnes Ereignis ist nicht immer eine einzelne Zeile. PACKET-Detailblöcke und Ereignismeldungen setzen sich in eingerückten Folgelinien fort. Der Parser hängt diese an den zugehörigen Datensatz an, anstatt sie zu verwerfen oder verwaiste Zeilen zu erzeugen.

Jeder Eintrag enthält bis zu 16 native Felder — Zeitstempel, Protokoll, Richtung, Client-IP, Abfragetyp, abgefragter Name, Antwortcode, Flags und mehr. Die vollständige Spaltenliste findest du in Ausgabeformate.

Warum die Umwandlung lohnt

Fehlerbehebung

• Herausfinden, warum ein Name nicht aufgelöst wird und ob die Abfrage überhaupt den Server erreicht hat
• Fehlkonfigurierte Clients oder Anwendungen identifizieren, die den Server überlasten
• Nachverfolgen, wo eine problematische Abfrage tatsächlich herkommt
• Zonentransfers und allgemeines DNS-Verhalten überprüfen

Leistung und Kapazität

• Clients nach Abfragevolumen sortieren und die lauten Kandidaten finden
• Sehen, welche Record-Typen deinen Traffic dominieren
• Konfigurationsfehler erkennen, die vermeidbare Abfragen verursachen
• Serverlast über die Zeit verfolgen statt zu raten

Sicherheitsanalyse

• DNS-Tunneling und Datenexfiltration erkennen (typischerweise sichtbar als übermäßiger TXT-Traffic — siehe das SQL Server Analysebeispiel)
• Abfragen gegen Malware- und Command-and-Control-Domains finden
• Abfragemuster eines kompromittierten Hosts erkennen
• DNS-Amplification-Missbrauch beobachten
• Rekonstruieren, was während eines Vorfalls passiert ist

Compliance und Auditing

• Protokollierungs- und Aufbewahrungspflichten erfüllen
• Eine Audit-Trail der Netzwerkaktivität führen
• Berichte für Management oder Auditoren erstellen

Wie das Modul funktioniert

Convert-DNSDebugLogFile liest das Log als Stream und schreibt die CSV ebenfalls als Stream. Die Datei wird nie komplett in den Speicher geladen, sodass ein 100 MB Log ungefähr genauso viel RAM benötigt wie ein 10 MB Log. Details findest du unter Performance.

Das bekommst du:

Aktives Log vs. rotiertes Log

Das praktische Muster ist, auf dem DNS-Server die Protokollrotation zu aktivieren und die geplante Umwandlung die neueste Datei überspringen zu lassen:

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

Eine vollständige, auf Gruppenrichtlinien basierende Umsetzung ist im GPO-gesteuerten Sammelbeispiel dokumentiert.

Wohin als Nächstes

• Ausgabeformate — was die Spalten bedeuten, mit echten Beispieldateien
• Parameter und Optionen — die Stellschrauben, einfach erklärt
• Performance — warum es schnell ist und wie es schnell bleibt
• Integration — Excel, Power BI, SQL, SIEM, Python
• Betriebliche Best Practices — Einsatz im Produktivbetrieb
• Anwendungsbeispiele — geplante Tasks, GPO-Rollout, SQL-Analysen
• Befehlsreferenz — die autoritative Parameterliste

Lizenz und Support

MIT-Lizenz. Community-Support läuft über GitHub Issues; Fehlerberichte und Featurewünsche sind willkommen.

• GitHub-Repository: AndiBellstedt/DNSServer.DebugLogParser
• PowerShell Gallery: DNSServer.DebugLogParser

2 - Ausgabeformate

Convert-DNSDebugLogFile erzeugt bis zu drei Dateien pro Eingabeprotokoll:

Both ist die Standardeinstellung. Die Ausgabe landet neben der Eingabedatei, sofern du nicht -OutputFile setzt.

Die auf dieser Seite verlinkten Beispieldateien sind echte Konversionsergebnisse, keine Mock-ups. Lade eine herunter und öffne sie in Excel, bevor du dich für ein Pipeline-Design entscheidest.

Die CSV-Datendatei

Beispielausgabe:

Zwei Zeilen aus einer echten Konversion — eine DNS-Abfrage und eine serverinterne Notiz:

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

Spalten

Immer 18 Spalten, immer in dieser Reihenfolge:

Zwei Dinge, die du beachten solltest:

• Nicht jede Spalte ist für jede Zeile gefüllt. Nur Packet-Einträge haben eine Client-IP, einen Abfragenamen und einen Antwortcode. Note- und Event-Zeilen tragen ihren Text in Information und lassen die Protokollspalten leer. Gestalte dein Datenbankschema und Dashboard-Filter entsprechend.
• ComputerName ist immer die letzte Spalte, auch wenn du -ComputerName nicht benutzt. Dann ist sie einfach leer. So bleibt das Layout über alle Server hinweg identisch, sodass du Dateien von vielen DNS-Servern ohne Spaltenzuordnung zusammenfügen kannst.

Die Details-Spalte

Detailblöcke erscheinen nur, wenn der DNS-Server so konfiguriert ist, dass er vollständige Paketdetails protokolliert. Wenn sie vorhanden sind, wandelt der Parser sie in einen einzelnen JSON-Wert um, sodass die Zeile eine Zeile bleibt:

{
  "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": []
  }
}

Das Parsen dieser Blöcke kostet Zeit und macht die CSV deutlich größer. Wenn du sie nicht brauchst, nutze -NoDetailsParsing — die Spalte bleibt vorhanden, aber leer, und die Konvertierung wird schneller. Siehe Performance.

Die Statistikdateien

Statistiken sind tägliche Aggregationen. Nutze sie, wenn du einen Trend oder eine Zusammenfassung möchtest und nicht den kompletten Datensatz verschieben willst — sie sind um Größenordnungen kleiner als die Datendatei.

Kontextstatistiken (*_Statistic.csv)

Antworten auf die Frage: Wie viel von welcher Aktivität ist pro Tag passiert?

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

Beispieldateien: en-US WithComputerName, en-US NoComputerName, de-DE WithComputerName, de-DE NoComputerName

Paketstatistiken (*_PacketStatistic.csv)

Antworten auf die Frage: Wer hat was wie oft pro Tag abgefragt?

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

Beispieldateien: en-US WithComputerName, en-US NoComputerName, de-DE WithComputerName, de-DE NoComputerName

Trennzeichen- und Datumsformat

Beide Ausgabetypen respektieren -Delimiter (Standard ;) und -OutputCulture. Für alles, was maschinell importiert wird, schreibe ISO-ähnliche Zeitstempel:

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

Das ergibt 2026-01-20 23:00:16, was SQL Server, Power BI und pandas alle ohne Formatangabe lesen. Details in Parameter und Optionen.

3 - Parameter und Optionen

Diese Seite erklärt die Optionen in einfacher Sprache und in der Reihenfolge, in der du sie typischerweise brauchst. Es ist ein Leitfaden, keine Spezifikation — die autoritative, immer aktuelle Parameterliste findest du in der Befehlsreferenz und in:

Get-Help Convert-DNSDebugLogFile -Full

Die Kurzfassung

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

Diese eine Zeile liefert dir schon ein sinnvolles Verhalten: sowohl Daten- als auch Statistikdateien, Semikolon als Trennzeichen, das Datumsformat deiner Maschine, Header-Validierung an, Quell-Log bleibt unverändert. Alles Weitere ist Feintuning.

Eingabe und Ausgabe

-InputFile

Pfad zum zu konvertierenden Log. Akzeptiert ein Array und Pipeline-Eingaben — deshalb funktioniert das hier:

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

Get-ChildItem gibt Objekte mit einer FullName-Eigenschaft aus, und -InputFile akzeptiert diese per Eigenschaftsname (Aliase sind u.a. FullName, Path, FilePath). Kein ForEach-Object nötig.

Lokale Pfade und SMB/UNC-Pfade funktionieren beide:

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

Der Befehl kann auch ein Log öffnen, das der DNS-Server gerade offen hält. Siehe aktive Logs weiter unten, bevor du dich darauf verlässt.

-OutputFile

Ohne Angabe landet die CSV neben der Eingabedatei, gleicher Basisname, .csv-Erweiterung. Mit Angabe steuerst du das Ziel.

-Delimiter

Standard ist ein Semikolon, weil in Gebieten, wo das Komma Dezimaltrennzeichen ist, Excel das erwartet. Nutze -Delimiter "," für Tools und Datenbanken, die klassische CSV mit Komma erwarten, oder -Delimiter "`t" für Tabulator.

Was auch immer du wählst, benutze denselben Wert beim Import. Eine Abweichung ist die Hauptursache dafür, dass „alles in einer Spalte landet“.

Beschriftung und Filterung

-ComputerName

Füllt die Spalte ComputerName. Die Spalte gibt es so oder so; das hier gibt ihr nur einen Wert.

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

Setze es immer, wenn mehrere Server in einen Datensatz einspeisen — sonst kannst du später nicht mehr sagen, von welchem DC eine Zeile stammt.

-OutputType

• CSV — nur die Datendatei
• Statistic — nur die zwei Aggregatdateien, keine Zeilendaten
• Both — alle drei Dateien (Standard)

Statistic ist die schnelle, kleine Option, wenn du nur tägliche Trends brauchst. CSV ist richtig, wenn ein nachgelagertes System selbst aggregiert.

-ContextFilter

Ein DNS-Debug-Log mischt tatsächlichen Abfrageverkehr mit serverinternem Geplapper. -ContextFilter entscheidet, was in der Ausgabe bleibt.

# nur echter DNS-Verkehr
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -ContextFilter Packet

# Verkehr plus Serverereignisse, aber keine Diagnosehinweise
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -ContextFilter Packet, Event

Weitere Kontexttypen (DSPoll, Init, Lookup, Recurse, Remote, Tombstone) erscheinen unter All.

Filterst du nur auf Event oder Note, werden nur DateTime, ThreadId, Context und Information gefüllt — die Protokollspalten bleiben leer, weil diese Einträge diese Infos nicht enthalten.

-ContextFilter Packet ist die übliche Wahl für Sicherheits- und Reporting-Pipelines: es entfernt den Lärm und verkleinert die Ausgabe spürbar.

Internationale Logs

Der DNS-Server schreibt Zeitstempel im Windows-Gebietsschema der Maschine, auf der er läuft. Ein deutscher DC schreibt 20.01.2026 23:00:16; ein US-Server schreibt 1/20/2026 11:00:16 PM. Wenn das Gebietsschema deines Arbeitsplatzrechners vom Server abweicht, klappt das Parsen nicht — oder schlimmer, Tag und Monat werden still vertauscht.

-InputCulture

Sag dem Parser, welches Gebietsschema das Quell-Log verwendet:

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

Standard ist die Kultur der Sitzung, die den Befehl ausführt. In einer Umgebung mit gemischten Gebietsschemata solltest du sie explizit setzen, statt dich auf den Standard zu verlassen — und denk daran, dass ein geplanter Task, der als SYSTEM läuft, vielleicht nicht die Kultur hat, mit der du interaktiv getestet hast.

-OutputCulture

Steuert, wie Zeitstempel in die CSV geschrieben werden:

# ISO-ähnliche Ausgabe, die SQL Server, Power BI und pandas alle verstehen
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -OutputCulture 'sv-SE'

# gleicher Effekt, explizite Invariant-Kultur
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" `
    -OutputCulture ([System.Globalization.CultureInfo]::InvariantCulture)

Faustregel: Wenn ein Mensch die Datei in Excel öffnet, nutze die lokale Kultur. Wenn eine Maschine sie liest, verwende sv-SE oder die Invariant-Kultur und mach dir keine Sorgen um regionale Einstellungen beim Import.

Die beiden Parameter sind unabhängig — du kannst ein schwedisches Log lesen und US-formatierten Output schreiben.

Geschwindigkeit und Speicher

-NoDetailsParsing

Wenn der DNS-Server volle Paketdetails protokolliert, wandelt der Parser jeden Detailblock in JSON in der Spalte Details um. Das ist nützlich, aber auch der teuerste Teil des Laufs und bläht die CSV auf.

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

Die Spalte bleibt vorhanden, aber leer; die TCP/UDP-Detail-Headerzeile ist weiterhin in Information verfügbar. Bei Logs mit vielen Detailblöcken kann das die Verarbeitungszeit um 30–50 % reduzieren. Nutze es, wenn Informationen auf Abfrageebene ausreichen.

-CompressOutput

Komprimiert die erzeugten CSV-Dateien und löscht die unkomprimierten. dns.log erzeugt dns.zip statt dns.csv.

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

CSV dieser Art komprimiert typischerweise um 90 % oder mehr, das spart also quasi kostenlosen Speicherplatz für Archive und beim Versand über das Netzwerk.

-RemoveSourceFile

Löscht die Quell-.log nach erfolgreicher Konvertierung — die Logdatei wird nur gelöscht, wenn alle Ausgabedateien erstellt wurden.

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

Sicherheitsnetze

-SkipHeaderValidation

Standardmäßig prüft der Befehl, ob die Datei wirklich ein DNS-Server-Debug-Log ist, bevor er es parst. Das fängt den klassischen Fehler ab, den Job auf den falschen Ordner zu zeigen.

Schalte es nur bei wirklich ungewöhnlichen Fällen aus: handbearbeitete Logs, vorgefilterte Ausschnitte, benutzerdefinierte Formate. Lass es sonst an — es kostet kaum Leistung und verhindert, dass ein Tippfehler in einem Haufen Müll endet.

-WhatIf und -Confirm

Der Befehl unterstützt beides. -WhatIf ist der richtige Weg, um zu sehen, was ein neuer Batch-Job anfasst:

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

-Confirm fragt vor der Verarbeitung jeder Datei, vor dem Löschen einer Quelldatei und vor dem Überschreiben vorhandener Ausgaben nach.

Aktive Logs

Convert-DNSDebugLogFile kann eine Datei lesen, die der DNS-Server gerade offen hat. Praktisch für einen Ad-hoc-Blick auf das, was gerade passiert.

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

Zusammengesetzt

Ein typischer Produktionsaufruf auf einem Domänencontroller:

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

Gelesen heißt das: Nimm jedes rotierte Log außer dem aktiven, behalte nur DNS-Verkehr, versehe jede Zeile mit dem Servernamen, schreibe maschinenlesbare Zeitstempel und hinterlasse komprimierte Archive. Die vollständige Version für geplante Tasks und Gruppenrichtlinien findest du im GPO-gesteuerten Sammelbeispiel.

4 - Performance

DNS-Debug-Logs auf einem stark genutzten Domänencontroller sind groß. Convert-DNSDebugLogFile ist genau für diesen Fall gemacht: Es wurde mit Logs von 100 MB und mehr getestet und verarbeitet sie in Minuten auf gewöhnlicher Server-Hardware.

Warum es so schnell ist

Du musst das nicht wissen, um das Modul zu nutzen, aber es erklärt das Verhalten, das du beobachten wirst.

Die wichtige Konsequenz: Das gesamte Log wird nie komplett im Speicher gehalten. Ein 500 MB großes Log braucht nicht 500 MB RAM. Das ist der Unterschied zwischen dem Modul und dem „Datei lesen, splitten, Objekte bauen“-Ansatz, den die meisten selbstgebastelten Skripte verwenden – dieser Ansatz funktioniert bei einer 5 MB Probe gut, aber bei einem echten DC bricht er zusammen.

Das Beste aus einem Lauf herausholen

Konvertiere rotierte Dateien, nicht eine riesige Datei

Konfiguriere den DNS-Server so, dass das Log bei einer handhabbaren Größe rotiert – 50 bis 200 MB sind ein guter Bereich. Mehrere mittelgroße Dateien werden in vorhersehbarer Zeit konvertiert und erlauben einem geplanten Job, innerhalb seines Zeitfensters fertig zu werden. Eine immer größer werdende Datei irgendwann nicht mehr.

Rollover gibt dir außerdem geschlossene Dateien zum Arbeiten, was du sowieso willst:

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

Überspringe Detail-Parsing, wenn du es nicht brauchst

Wenn der DNS-Server vollständige Paketdetails schreibt, ist das Umwandeln dieser Blöcke in JSON der mit Abstand teuerste Teil der Konvertierung.

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

Erwarte 30–50 % schnellere Läufe bei Logs mit vielen Detailblöcken, plus eine deutlich kleinere CSV. Du bekommst trotzdem die Abfrage-Daten und die TCP/UDP-Detail-Kopfzeile in Information. Siehe Parameter und Optionen.

Früh filtern

-ContextFilter Packet lässt Server-Notizen und Events weg, bevor sie geschrieben werden. Weniger Ausgabe bedeutet weniger I/O, kleinere Dateien und weniger Arbeit danach.

Fordere nur an, was du brauchst

-OutputType Statistic überspringt das Schreiben der zeilenweisen CSV komplett. Wenn dein Dashboard nur Tageszählungen anzeigt, ist das bei weitem die günstigste Option.

Lokal konvertieren, Ergebnisse verschieben

Das Modul liest SMB/UNC-Pfade, aber eine 200 MB große Rohdatei über das Netzwerk zu ziehen, um sie zentral zu parsen, ist der langsame Weg. Konvertiere auf dem DNS-Server und verschiebe dann die (komprimierte) CSV – die ist meist nur ein Zehntel der Bytes. Das ist das Konzept hinter dem GPO-gesteuerten Sammelbeispiel.

Für Transfer und Archiv komprimieren

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

CSV dieser Art schrumpft typischerweise um 90 % oder mehr. Komprimierung kostet am Ende des Laufs etwas CPU und spart danach viel Festplatten- und Netzwerkplatz.

Wenn ein Lauf langsamer als erwartet ist

Prüfe diese Punkte der Reihe nach:

1. Festplatte, nicht CPU. Die Konvertierung ist I/O-lastig. Ein Log auf einem stark genutzten Volume oder über eine langsame Verbindung gelesen, bestimmt die Laufzeit.
2. Detailblöcke. Wenn das Log vollständige Paketdetails enthält und du nicht -NoDetailsParsing verwendet hast, geht dort die Zeit drauf.
3. Dateigröße. Eine einzelne mehrgigabyte große Datei braucht einfach seine Zeit. Löse das mit Rollover, nicht mit Parametern.
4. Antivirus. Echtzeit-Scanning von Quell-Log und generierter CSV kann die effektiven I/O-Kosten verdoppeln. Eine Ausnahme für das Log-Verzeichnis ist eine übliche und sinnvolle Maßnahme.
5. Speicherdruck. Das Modul streamt, sollte also nicht die Ursache sein – aber ein Server, der bereits swappt, macht alles langsam.

Weitere Symptome und Lösungen findest du in Fehlerbehebung.

5 - Integration mit Analysetools

Der Sinn der Konvertierung eines DNS-Debug-Logs liegt im, was danach passiert. CSV wurde gewählt, weil es von allem gelesen wird – aber „alles liest CSV“ verbirgt zwei Einstellungen, die entscheiden, ob der Import schmerzfrei oder ein Nachmittag voller Fummelei wird.

Zwei Einstellungen, die alles entscheiden

Trennzeichen. Standard ist ;. Behalte es für Excel in Regionen, die das Komma als Dezimaltrennzeichen verwenden. Wechsle zu , für die meisten Datenbanken und Data-Science-Tools. Was auch immer du wählst, sag der importierenden Seite dasselbe.

Datumsformat. -OutputCulture steuert, wie Zeitstempel geschrieben werden. Für alles, was von einer Maschine gelesen wird, nutze sv-SE (oder die Invariant Culture), damit DateTime als 2026-01-20 23:00:16 ausgegeben wird:

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

Jeder unten genannte Verbraucher versteht dieses Format ohne Hinweis. Länderspezifische Ausgaben wie 20.01.2026 werden als Text importiert oder – noch schlimmer – als Monat/Tag falsch interpretiert.

Microsoft Excel

Der schnellste Weg, sich eine einzelne konvertierte Logdatei anzusehen.

• Mit dem Standard-Trennzeichen ; und einer passenden Regionseinstellung öffnet ein Doppelklick die Datei mit korrekten Spalten.
• Wenn alles in Spalte A landet, passt das Trennzeichen nicht zu deiner Excel-Einstellung. Entweder erneut mit -Delimiter "," ausführen oder über Daten → Aus Text/CSV importieren und dort das Trennzeichen auswählen.
• Mach aus dem Bereich eine Tabelle (Strg+T) und erstelle eine Pivot-Tabelle mit ClientIP, QuestionName oder QuestionType. Top-Talker und Top-Domains sind in etwa einer Minute fertig.
• Bei mehr als ein paar hunderttausend Zeilen nutze stattdessen Power Query oder eine der anderen unten genannten Optionen.

Die Dateien *_Statistic.csv und *_PacketStatistic.csv sind meist die besseren Excel-Ziele – sie sind voraggregiert und bleiben klein. Siehe Ausgabeformate.

Power BI

Importiere die CSV-Dateien und erstelle Dashboards für DNS-Aktivität, Top-Clients, Abfrage-Trends und Fehlerraten.

• Richte Power Query auf den Ordner mit deinen konvertierten Dateien ein, nicht auf eine einzelne Datei. Das Layout ist über Server und Tage hinweg identisch, Dateien werden einfach angehängt.
• Die Spalte ComputerName ermöglicht Multi-Server-Berichte – setze -ComputerName während der Konvertierung, sonst kannst du nicht nach Server filtern.
• ResponseCode und QuestionType sind natürliche Filter; DateTime wird zur Zeitachse.
• Wenn du nur tägliche Trends brauchst, füttere Power BI mit *_PacketStatistic.csv statt der kompletten Datei, um das Modell klein zu halten.

SQL-Datenbanken

Lade die CSV per Bulk-Load in SQL Server, PostgreSQL oder andere SQL-Datenbanken für langfristige Speicherung und wiederholbare Abfragen.

Eine einsatzbereite Schritt-für-Schritt-Anleitung – Tabellen-Definition, Konvertierung, SqlBulkCopy-Import und eine Erkennungsabfrage für verdächtige TXT-Aktivität – findest du unter Security Analysis Workflow with SQL Server.

Punkte, die du vor dem ersten Laden planen solltest:

• Nutze -OutputCulture 'sv-SE', damit Zeitstempel ohne Umwandlungstricks in eine datetime2-Spalte landen.
• Information und Details können lang sein; gib ihnen nvarchar(max).
• Indexiere, was du tatsächlich abfragst – typischerweise DateTime, ClientIP und QuestionName.
• Halte -ComputerName gefüllt, damit Zeilen nach dem Zusammenführen noch zugeordnet werden können.

SIEM-Systeme

Splunk, Elastic, Sentinel und ähnliche Plattformen nehmen die CSV auf, um sie mit anderer Sicherheitstelemetrie zu korrelieren und Alarme zu generieren.

• Versende die komprimierte Ausgabe (-CompressOutput) – sie ist etwa ein Zehntel der Größe und die meisten Collector entpacken sie selbst.
• Definiere die Feldzuordnung einmal; das Spaltenlayout ändert sich nie zwischen Läufen oder Servern, inklusive der immer vorhandenen abschließenden Spalte ComputerName.
• Lass deinen Collector Duplikate entfernen oder archiviere verarbeitete .log-Dateien. Ein Konvertierungsjob, der dieselben rotierten Logs erneut verarbeitet, sendet sonst identische Zeilen erneut.
• -ContextFilter Packet hält das Ingest-Volumen (und die Lizenzkosten) niedrig, wenn Server-Notizen nicht zu deinen Anwendungsfällen gehören.

Python, R und Data-Science-Tools

Die strukturierte Ausgabe ist bereit für Anomalieerkennung, Baseline-Analysen und individuelle Auswertungen.

import pandas as pd

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

# Top 20 abgefragte Namen, nur Anfragen
top = (
    df[df["Direction"] == "Rcv"]
    .groupby("QuestionName")
    .size()
    .sort_values(ascending=False)
    .head(20)
)
print(top)

parse_dates funktioniert direkt, wenn du mit -OutputCulture 'sv-SE' exportiert hast. Ab hier übernehmen pandas, scikit-learn oder R das Clustering, die Saisonalität und Ausreißererkennung wie gewohnt.

In PowerShell bleiben

Du musst PowerShell nicht verlassen, um schnell eine Antwort zu bekommen:

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

# lauteste Clients
$dns | Where-Object Direction -eq 'Rcv' |
    Group-Object ClientIP |
    Sort-Object Count -Descending |
    Select-Object -First 10 Count, Name

# fehlgeschlagene Abfragen
$dns | Where-Object ResponseCode -eq 'NXDOMAIN' |
    Group-Object QuestionName |
    Sort-Object Count -Descending |
    Select-Object -First 10 Count, Name

Import-Csv liest die ganze Datei in den Speicher, das ist also okay für ein rotiertes Chunk, aber ungeeignet für einen mehrgigabytegroßen Export – dafür sind die Datenbank- und SIEM-Wege gedacht.

6 - Operative Best Practices

Ein Protokoll manuell zu konvertieren ist einfach. Es jede Nacht auf jedem Domänencontroller über Jahre hinweg laufen zu lassen, ohne dass jemand hinschaut, erfordert etwas Planung. Das sind die Punkte, die in der Praxis wichtig sind.

1. Konvertiere rotierte Protokolle, nicht das aktive

Aktiviere die Protokollrotation auf dem DNS-Server und konvertiere nur geschlossene Dateien. Das Modul kann das Protokoll lesen, in das der DNS-Server gerade schreibt, aber diese Datei ändert sich während der Konvertierung: die neuesten Einträge können fehlen und der letzte Eintrag kann abgeschnitten sein. Zwei Durchläufe liefern zwei unterschiedliche Ergebnisse.

Das Standardmuster überspringt die neueste Datei:

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

Ein Kompromiss, den du kennen solltest: Bei einem Server mit geringem Datenaufkommen kann die Rotation länger als einen Tag dauern, sodass die Daten des aktuellen Tages erst nach der Rotation konvertiert werden. Passe die Rotationsgröße entsprechend an.

2. Plane es ein und gib dem Job eine passende Identität

Der Task Scheduler ist der übliche Ort dafür — täglich ist ein sinnvoller Standard. Eine vollständige Gruppenrichtlinien-Implementierung für Domänencontroller ist im GPO-gesteuerten Sammelbeispiel dokumentiert, und eine eigenständige Aufgabe im Scheduled Task Beispiel.

Drei Dinge bereiten hier oft Probleme:

• Modulauffindbarkeit. Ein Task, der als SYSTEM mit -NoProfile läuft, sieht nur maschinenweite Modulpfade. Installiere das Modul maschinenweit oder füge einen expliziten Import-Module in die Task-Aktion ein.
• Kultur. Das Konto, das den Task ausführt, hat möglicherweise nicht die gleiche Gebietsschema-Einstellung wie du beim interaktiven Test. Setze -InputCulture und -OutputCulture explizit, statt dich auf den Standard zu verlassen.
• Netzwerkzugriff. Wenn Quelle oder Ziel ein UNC-Pfad sind, authentifiziert sich SYSTEM als Computerkonto. Erteile dem Computerkonto (oder der Gruppe Domain Controllers) Freigabe- und NTFS-Rechte oder führe den Task als dediziertes Dienstkonto aus.

3. Rotieren bei einer Größe, die du verarbeiten kannst

50–200 MB pro Datei halten die Konvertierung vorhersehbar und lassen einen nächtlichen Job innerhalb seines Zeitfensters abschließen. Eine Datei, die ewig wächst, tut das irgendwann nicht mehr. Siehe Performance.

4. Validier die ersten Ausgaben, bevor du automatisierst

Führe die Konvertierung manuell auf zwei oder drei echten Protokollen aus und öffne die CSV tatsächlich:

• Sind die Zeitstempel korrekt — nicht Tag/Monat vertauscht? (Falls doch, setze -InputCulture.)
• Passt das Trennzeichen zu dem, was dein Verbraucher erwartet?
• Ist ComputerName ausgefüllt?
• Sind die benötigten Kontexte vorhanden und die unnötigen herausgefiltert?

-WhatIf zeigt dir, welche Dateien ein Batch berühren würde, bevor es sie berührt:

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

5. Entscheide, was mit verarbeiteten Protokollen passiert

Ein Job, der einfach „jede Datei außer der neuesten“ konvertiert, verarbeitet dieselben Dateien jede Nacht erneut. Das ist robust und einfach, überschreibt aber Ausgaben und kann doppelte Zeilen in die nachgelagerte Verarbeitung bringen.

Wähle eine Option:

• verschiebe verarbeitete .log-Dateien in einen Archivordner
• lösche sie mit -RemoveSourceFile, sobald du der Pipeline vertraust
• lasse den nachgelagerten Collector Duplikate entfernen

Was auch immer du wählst, schreib es auf — das ist die Kleinigkeit, die den nächsten Administrator verwirrt.

6. Plane Speicher und Aufbewahrung

Komprimierung (-CompressOutput) reduziert die CSV meist um 90 % oder mehr, aber das Volumen wächst trotzdem. Schätze anhand deiner tatsächlichen Abfragerate und deiner Aufbewahrungspflicht und setze ein Enddatum für die Daten, anstatt sie unbegrenzt wachsen zu lassen.

-OutputType Statistic ist für lange Aufbewahrung einen Blick wert: tägliche Rollups sind winzig und beantworten oft die Trendfragen, für die alte Zeilen-Daten aufbewahrt wurden.

7. Behandle die Ausgabe als sensibel

Geparste DNS-Protokolle beschreiben deine interne Namensstruktur und wer was abgefragt hat. Das ist aufschlussreicher als die meisten Infrastrukturprotokolle und kann je nach Rechtslage als personenbezogene Daten gelten.

• Beschränke NTFS- und Freigabeberechtigungen auf die Ausgabeordner.
• Lege CSVs nicht „temporär“ auf einem allgemeinen Dateifreigabeordner ab.
• Beziehe DNS-Protokolldaten in deine Aufbewahrungs- und Löschrichtlinie ein, nicht nur in deine Backup-Policy.
• Komprimierte Ausgaben sind kleiner, aber nicht geschützt — nutze Verschlüsselung oder Zugriffskontrolle, wo es wichtig ist.

8. Lass die Header-Validierung an

Die Standardprüfung, ob eine Datei wirklich ein DNS-Debug-Protokoll ist, kostet nichts und verhindert, dass ein falsch eingegebener Pfad Tausende Unsinn-Zeilen erzeugt. Verwende -SkipHeaderValidation nur für wirklich ungewöhnliche Formate — und beachte, dass der Befehl genau aus diesem Grund die Kombination mit -RemoveSourceFile verweigert.

9. Überwache den Job, nicht nur den Server

Eine unbeaufsichtigte Konvertierung, die stillschweigend stoppt, ist schlimmer als keine Konvertierung, weil die Lücke erst bemerkt wird, wenn jemand die Daten braucht.

• Achte auf Fehlerausgaben ungleich Null; die GPO-Referenzimplementierung wirft absichtlich einen Fehler, wenn $Error.Count -gt 0 ist, damit der Task einen Fehler meldet.
• Alarmiere anhand des letzten Ergebniscodes des geplanten Tasks, nicht nur danach, ob der Task existiert.
• Prüfe, ob Ausgabedateien tatsächlich mit aktuellen Zeitstempeln erscheinen.
• Überwache freien Speicherplatz sowohl auf dem Protokolllaufwerk als auch am Ausgabeziel.

Häufige Ursachen für einen fehlgeschlagenen Lauf — Zugriff verweigert, beschädigte Protokolle, ungültige Header — sind in Troubleshooting behandelt.

10. Dokumentiere den Ablauf

Wo Protokolle geschrieben werden, wann der Job läuft, welche Parameter verwendet werden, wohin die Ausgabe geht, wer sie konsumiert und wie lange sie aufbewahrt wird. Sechs Zeilen in deinem Operations-Wiki. Das macht die Einrichtung auditierbar und übergabefähig.

7 - Fehlerbehebung

„Die Datei ist keine gültige DNS-Debug-Logdatei“

Die Header-Prüfung hat die Eingabe abgelehnt. Meistens ist der Pfad einfach falsch — eine .log-Datei im gleichen Ordner, die kein DNS-Debug-Log ist, oder eine Datei, die nur einen rotierten Header enthält.

Arbeite das Folgende durch:

1. Öffne die Datei. Ein DNS-Debug-Log beginnt mit einer Header-Zeile wie Message logging started at … und enthält danach mit Zeitstempel versehene Abfrageeinträge.

2. Bestätige, dass das DNS-Debug-Logging tatsächlich aktiviert ist und in den erwarteten Pfad schreibt:

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

3. Wenn die Datei tatsächlich ein DNS-Log ist, der Header aber ungewöhnlich ist — handbearbeitet, vorgefiltert, ein benutzerdefinierter Export — kannst du die Prüfung umgehen:

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

Behalte die Validierung überall sonst aktiviert. Beachte, dass -SkipHeaderValidation nicht mit -RemoveSourceFile kombiniert werden kann, sodass eine nicht verifizierte Datei durch die Konvertierung niemals gelöscht wird.

Ausgabedatei ist leer oder enthält viel weniger Zeilen als erwartet

Prüfe in dieser Reihenfolge:

• Enthält das Log überhaupt Abfrageeinträge? Ein frisch rotiertes Log kann außer einem Header noch keine Einträge enthalten, wenn noch keine Abfragen stattgefunden haben.
• Ist ein -ContextFilter aktiv? -ContextFilter Packet entfernt per Design Event- und Note-Einträge. Wenn du auf Event oder Note gefiltert hast, sind die meisten Spalten ebenfalls leer — diese Eintragstypen enthalten nur DateTime, ThreadId, Context und Information.
• War das Quell-Log aktiv? Eine Datei, in die der DNS-Server noch schreibt, kann sich während der Konvertierung ändern; die neuesten Einträge fehlen möglicherweise und der letzte Datensatz kann abgeschnitten sein. Konvertiere ein rotiertes, geschlossenes Log, wenn du vollständige Ausgabe brauchst.
• Ist die Datei beschädigt oder abgeschnitten? Prüfe das Ende des Logs auf eine halbgeschriebene Zeile.

Daten sind falsch, verschoben oder Tag und Monat vertauscht

Das Log wurde von einem Server mit einer anderen Windows-Lokalisierung geschrieben als die Sitzung, die die Konvertierung durchführt. 20.01.2026 und 01/20/2026 beschreiben denselben Zeitpunkt, aber nur, wenn beide Seiten dasselbe Format verwenden.

# Log stammt von einem deutschen Server
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns-berlin.log" -InputCulture 'de-DE'

Setze -InputCulture explizit in geplanten Aufgaben, anstatt dich auf die Kultur des Kontos zu verlassen, das sie zufällig ausführt. Wenn die Ausgabe maschinenlesbar sein soll, füge -OutputCulture 'sv-SE' hinzu. Details in Parameter und Optionen.

Nach dem Import landet alles in einer Spalte

Trennzeichen stimmt nicht überein. Das Modul schreibt standardmäßig ;; dein Importer erwartete , (oder umgekehrt).

Entweder führe die Konvertierung mit dem vom Importer gewünschten Trennzeichen erneut aus:

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

…oder sag dem Importer, welches Trennzeichen die Datei verwendet — in Excel über Daten → Aus Text/CSV, in PowerShell über Import-Csv -Delimiter ';'.

„Zugriff verweigert“

• Das DNS-Log-Verzeichnis erfordert typischerweise Administratorrechte. Starte PowerShell erhöht oder führe die geplante Aufgabe mit einem Konto aus, das Zugriff hat.
• Prüfe auch Schreibrechte für das Ausgabeverzeichnis, nicht nur Leserechte für das Log.
• Bei SMB/UNC-Pfaden: Ein Task, der als SYSTEM läuft, authentifiziert sich im Netzwerk als Computer-Konto. Gewähre Freigabe- und NTFS-Rechte für dieses Computerkonto (oder für die Gruppe Domain Controllers), oder nutze ein dediziertes Dienstkonto.
• Wenn -RemoveSourceFile am Ende eines ansonsten erfolgreichen Laufs fehlschlägt, kann das Konto das Log lesen, aber nicht löschen.

Verarbeitung ist sehr langsam

1. Zuerst die Festplatte prüfen — die Konvertierung ist I/O-gebunden. Ein ausgelastetes Volume oder ein langsamer Netzwerkpfad bestimmt die Laufzeit.
2. Nutze -NoDetailsParsing, wenn du die Paket-Detail-JSON nicht brauchst; bei detailreichen Logs spart das 30–50 %.
3. Nutze -ContextFilter Packet, um weniger zu schreiben.
4. Teile riesige Logs mit DNS-Server-Log-Rollover auf, statt eine riesige Datei zu konvertieren.
5. Ziehe eine Antivirus-Ausnahme für das Log-Verzeichnis in Betracht.

Mehr dazu in Performance.

Komprimierte Ausgabe ist größer als erwartet

Logs mit sehr vielfältigem Inhalt — viele einzigartige Domains, viele verschiedene Clients — komprimieren sich weniger gut als repetitive. Das ist normal. ZIP erreicht trotzdem meist eine deutliche Reduktion; wenn nicht, prüfe, ob die Spalte Details die Datei aufbläht und ob du sie überhaupt brauchst.

Statistiken stimmen nicht mit den Erwartungen überein

• Vergewissere dich, dass du -OutputType Both oder -OutputType Statistic verwendet hast. Bei -OutputType CSV werden keine Statistikdateien geschrieben.
• Count ist eine Gesamtzahl, keine Anzahl unterschiedlicher Werte. Ein Client, der denselben Namen 500-mal abfragt, trägt 500 bei. Das ist die häufigste Ursache für „diese Zahl kann nicht stimmen“.
• Statistiken werden pro Tag gruppiert. Ein Log, das zwei Tage umfasst, erzeugt Zeilen für beide.
• Wenn ComputerName in den Statistikdateien leer ist, wurde -ComputerName während der Konvertierung nicht gesetzt.

Die geplante Aufgabe funktioniert interaktiv, aber nicht als Aufgabe

Fast immer eine von drei Ursachen:

• Modul nicht gefunden. SYSTEM mit -NoProfile sieht nur maschinenweite Modulpfade. Installiere das Modul maschinenweit oder füge der Task-Aktion ein explizites Import-Module DNSServer.DebugLogParser hinzu.
• Falsche Kultur. Die Lokalisierung des Task-Kontos unterscheidet sich von deiner. Setze -InputCulture und -OutputCulture explizit.
• Ausführungsrichtlinie oder unsigniertes Skript. Passe die -ExecutionPolicy der Aufgabe an deine Signierrichtlinie an und hebe die Blockierung von Dateien auf, die von anderswo kopiert wurden.

Führe die genaue Befehlszeile der Aufgabe manuell im gleichen Kontext aus (zum Beispiel mit PsExec als SYSTEM), um das Problem zu reproduzieren.

Ein Problem melden

Wenn nichts davon hilft:

1. Aktualisiere auf die neueste Modulversion und versuche es erneut.

2. Suche in den GitHub-Issues nach dem gleichen Symptom.

3. Sammle die Diagnosedaten:

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

   plus den genauen Befehl, den du ausgeführt hast, die vollständige Fehlermeldung inklusive Stacktrace und — wenn du sie teilen kannst — einen kleinen anonymisierten Ausschnitt des Logs, der das Problem reproduziert.

4. Öffne ein neues Issue mit diesen Informationen.

8 - Modulbefehle Referenz

Wenn du auf einen Befehl klickst, gelangst du zu einer Detailseite, die umfassende Informationen zum Befehl bietet, einschließlich Syntax, Parameter, Beispiele sowie zusätzliche Hinweise oder Tipps zur Verwendung.

8.1 - Convert-DNSDebugLogFile

SYNOPSIS

Wandelt Windows DNS-Server-Debugprotokolle in ein strukturiertes CSV-Format zur Analyse und Berichterstellung um.

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

Dieses Cmdlet hat folgende Aliase,

BESCHREIBUNG

Konvertiert Windows DNS-Server-Debugprotokolldateien in strukturierte CSV-Daten, die in Excel, Power BI, SQL-Datenbanken oder SIEM-Tools analysiert werden können. Entwickelt für Sicherheitsanalysen, Leistungsüberwachung, Fehlerbehebung und Compliance-Berichte.

Das Cmdlet analysiert DNS-Debugprotokolle und schreibt eine konsistente CSV-Ausgabe zur Analyse. Die CSV-Ausgabe enthält 18 Spalten, darunter eine Information-Spalte für Ereignis-/Diagnosetexte, eine optionale Details-JSON-Spalte für Paket-Detailblöcke und eine stets vorhandene ComputerName-Spalte (leer, sofern nicht angegeben).

WICHTIGE FUNKTIONEN:

• Streaming-Verarbeitung vermeidet das Laden der gesamten Datei in den Speicher (geeignet für sehr große Protokolle)
• Hochleistungs-Parsing optimiert für große Dateien (100MB+)
• Anpassbarer CSV-Trennzeichen (Standard: Semikolon)
• Optionale statistische Zusammenfassungen mit aggregierten Metriken
• Kontextfilterung (Packet, Event, Note und weitere Kontexte) zur Fokussierung auf bestimmte Protokolleintragstypen
• Kulturabhängiges Datumsparsing und -formatierung für internationale Server
• Pipeline-Unterstützung für die Stapelverarbeitung mehrerer Dateien
• Optionale Komprimierung der Ausgabedateien (ZIP-Format)
• Optionale automatische Entfernung der Quelldateien nach der Verarbeitung
• Kopfzeilenvalidierung zur Sicherstellung der Datenintegrität

AUSGABEFORMAT: Die Spalte ComputerName ist immer am Ende jedes Datensatzes enthalten. Wenn der Parameter -ComputerName nicht angegeben wird, bleibt die Spalte leer. Dies gewährleistet eine konsistente Ausgabestruktur für Multi-Server-Konsolidierungsszenarien.

LEISTUNG: Optimiert durch StreamReader/StreamWriter mit 64KB-Puffern, Streaming-Verarbeitung für speichereffiziente Handhabung großer Dateien, String-Operationen statt Regex, manuelle CSV-Erzeugung und effiziente Hashtable-basierte Statistik-Erfassung.

KOMPATIBILITÄT:

• PowerShell 5.1+ (Desktop- und Core-Editionen)
• Windows Server 2016+
• DNS Server 2012 R2 bis 2025 Logformate

BEISPIELE

BEISPIEL 1

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

Konvertiert das DNS-Debugprotokoll mit Standardeinstellungen (Daten- und Statistikdateien mit Semikolon als Trennzeichen).
Ausgabe:

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

BEISPIEL 2

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

Erzeugt nur die Datendatei ohne Statistiken.
Ausgabe: C:\Logs\dns.csv

BEISPIEL 3

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

Erzeugt nur die Statistikdateien mit aggregierten Metriken.
Ausgabe:

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

BEISPIEL 4

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

Konvertiert das Protokoll an einen benutzerdefinierten Speicherort.
Ausgabe: C:\Output\parsed.csv

BEISPIEL 5

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

Konvertiert mit Komma als Trennzeichen und fügt die Spalte ComputerName mit dem Wert “DNS01” hinzu.
Ausgabe:

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

BEISPIEL 6

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

Batch-Verarbeitung mehrerer DNS-Debugprotokolldateien über die Pipeline.
Ausgabe: Für jede .log-Datei werden .csv- und _statistic.csv-Dateien erzeugt.

BEISPIEL 7

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

Konvertiert und komprimiert die Ausgabe in ein ZIP-Archiv.
Ausgabe: C:\Logs\dns.zip (enthält dns.csv + Statistikdateien)

BEISPIEL 8

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

Konvertiert das Protokoll und entfernt die Quelldatei nach erfolgreicher Verarbeitung.
Verbose-Ausgabe bestätigt die Dateientfernung.

BEISPIEL 9

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

Parst deutsches Datumsformat (TT.MM.JJJJ) und gibt im US-Format (MM/TT/JJJJ) aus.
Nützlich bei der Verarbeitung von Protokollen von Servern mit unterschiedlichen Regionaleinstellungen.

BEISPIEL 10

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

Konvertiert nur DNS-Abfrage-/Antwortpakete, schließt EVENT- und Note-Einträge aus.
Nützlich, um die Analyse auf den tatsächlichen DNS-Verkehr zu fokussieren.

BEISPIEL 11

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

Konvertiert sowohl DNS-Abfrage-/Antwortpakete als auch Serverereignisse, schließt Note- und andere Einträge aus.
Nützlich zur Analyse von DNS-Verkehr zusammen mit Serverereignissen.

BEISPIEL 12

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

Automatisierte Protokollarchivierung: verarbeitet alle Protokolle, komprimiert die Ausgabe und entfernt die Quelldateien.
Ideal für geplante Protokollverarbeitungspipelines.

BEISPIEL 13

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

Verarbeitet eine große Protokolldatei mit deaktiviertem Detail-Parsing für maximale Leistung.
PACKET-Detailblöcke werden übersprungen, die Details-Spalte bleibt leer.
Nützlich bei sehr großen Dateien, wenn die detaillierte Paketstruktur nicht benötigt wird.

PARAMETER

-CompressOutput

Komprimiert die ausgegebenen CSV-Dateien nach der Erstellung in ein ZIP-Archiv.

Erstellt eine .zip-Datei mit den generierten CSV-Dateien und entfernt anschließend die unkomprimierten CSV(s).
Die ZIP-Datei wird im selben Verzeichnis wie die Ausgabedatei mit demselben Basisnamen erstellt.

Vorteile:

• Reduziert den Speicherplatzbedarf erheblich (CSV-Dateien komprimieren sich typischerweise um 90%+)
• Vereinfacht Dateiverwaltung und Archivierung
• Geeignet für Langzeitspeicherung

Beispiel: Eingabedatei ‘dns.log’ erzeugt ‘dns.csv’, die zu ‘dns.zip’ komprimiert wird, danach wird ‘dns.csv’ entfernt.

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

Legt den Wert für die Spalte ComputerName in der CSV-Ausgabe fest.
Die Spalte ComputerName ist immer in der Ausgabe enthalten – wenn dieser Parameter nicht angegeben wird, bleibt die Spalte leer.

Verwende dies bei der Konsolidierung von Protokollen mehrerer DNS-Server, um die Quelle in kombinierten Datensätzen zu identifizieren.

Hinweis: Dies ist kein Remoting-Parameter.
Er kennzeichnet nur die Ausgabe.
Wenn du -InputFile auf einen UNC-Pfad setzt, wird die Datei von diesem Pfad gelesen (keine WinRM-/Remote-Ausführung).

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

Fordert vor Ausführung des Cmdlets eine Bestätigung an.

Wenn angegeben, wird vor Folgendem um Bestätigung gebeten:

• Verarbeitung jeder DNS-Debugprotokolldatei
• Entfernen von Quelldateien (bei Angabe von -RemoveSourceFile)
• Überschreiben vorhandener Ausgabedateien

Nützlich bei interaktiver Verarbeitung, wenn du steuern möchtest, welche Dateien verarbeitet werden.

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

Filtert, welche Protokolleintragstypen in die Ausgabe aufgenommen werden.
Akzeptiert einzelne oder mehrere Werte.

DNS-Debugprotokolle enthalten verschiedene Kontexttypen:

• PACKET: DNS-Abfrage- und Antwortpaketinformationen (primäre Daten)
• EVENT: DNS-Serverereignisse (z.B. “Der DNS-Server wurde gestartet.”)
• Note: Diagnosenotizen und Warnungen (z.B. Socket-Fehler, interne Zustände)
• DSPoll, Init, Lookup, Recurse, Remote, Tombstone: Weitere Kontexttypen

Gültige Werte:

• ‘All’: Alle Kontexttypen einschließen (Standard)
• ‘Packet’: Nur PACKET-Einträge einschließen (DNS-Abfragen/-Antworten)
• ‘Event’: Nur EVENT-Einträge einschließen (Serverereignisse)
• ‘Note’: Nur Note-Einträge einschließen (Diagnoseinformationen)
• Beliebige Kombination: Mehrere Werte angeben, um spezifische Kontexttypen einzuschließen

Standard: All

Beispiele:

• ‘Packet’ filtert nur DNS-Verkehr
• ‘Packet’,‘Event’ umfasst DNS-Verkehr und Serverereignisse
• ‘Note’,‘Event’ umfasst Diagnosenotizen und Serverereignisse

Hinweis: Bei Filterung auf ‘Event’ oder ‘Note’ enthalten nur die Spalten DateTime, ThreadId, Context und Information Daten. Andere Spalten (Protokoll, ClientIP usw.) bleiben leer.

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

Legt das Trennzeichen für die CSV-Ausgabe fest.

Standard: Semikolon (;)

Gängige Alternativen: Komma (,), Tabulator (`t), Pipe (|)

Verwende Semikolon in Regionen, in denen Komma als Dezimaltrennzeichen verwendet wird (Europa).
Verwende Komma für Standard-CSV-Tools und Datenbanken, die komma-getrennte Werte erwarten.

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

-InputCulture

Legt die Kultur/Region fest, die zum Parsen von Datums-/Uhrzeitwerten im DNS-Debugprotokoll verwendet wird.

DNS-Server-Debugprotokolle verwenden das Datumsformat der Windows-Region auf dem Server, auf dem das Protokoll erstellt wurde.
Verwende diesen Parameter bei der Verarbeitung von Protokollen von Servern mit unterschiedlichen Regionaleinstellungen.

Standard: Aktuelle Kultur

Gängige Beispiele:

• ‘de-DE’ oder ‘de-AT’: Deutsches Format (TT.MM.JJJJ oder TT/MM/JJJJ)
• ’en-US’: US-Format (MM/TT/JJJJ mit AM/PM)
• ’en-GB’: UK-Format (TT/MM/JJJJ mit 24-Stunden-Zeit)
• ‘sv-SE’: Schwedisches/ISO-Format (JJJJ-MM-TT)

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

Legt den Pfad zur zu parsenden DNS-Debugprotokolldatei fest.
Unterstützt Arrays zur Verarbeitung mehrerer Dateien.

Akzeptiert Pipeline-Eingaben von Get-ChildItem oder anderen Cmdlets, die Dateien liefern.

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

Überspringt das Parsen von PACKET-Detailblöcken in ein strukturiertes JSON-Format.

Wenn angegeben, enthalten PACKET-Datensätze mit Detailblöcken nur die TCP/UDP-Infozeile in der Spalte Information, während die Spalte Details leer bleibt.
Dies verbessert die Verarbeitungsleistung bei großen Protokolldateien erheblich, wenn keine detaillierte Paketstruktur-Analyse benötigt wird.

Verwende diesen Schalter, wenn:

• Sehr große Protokolldateien (100MB+) verarbeitet werden und nur Basisabfrageinformationen benötigt werden
• Die Detailstruktur (Nachrichtenflags, DNS-Abschnitte) für die Analyse nicht erforderlich ist
• Die maximale Parsing-Geschwindigkeit wichtiger ist als die Vollständigkeit der Daten

Leistungsverbesserung: Kann die Verarbeitungsgeschwindigkeit um 30-50% bei Protokollen mit vielen PACKET-Detailblöcken steigern.

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

Legt die Kultur/Region fest, die zum Formatieren von Datums-/Uhrzeitwerten in den Ausgabedateien verwendet wird.

Steuert, wie DateTime-Werte in die CSV geschrieben werden.
Verwende dies, wenn CSV-Dateien von Anwendungen oder Systemen mit spezifischen Regionaleinstellungen genutzt werden.

Standard: Aktuelle Kultur

Gängige Beispiele:

• ’en-US’: US-Format (MM/TT/JJJJ)
• ‘de-DE’: Deutsches Format (TT.MM.JJJJ)
• ‘sv-SE’ oder InvariantCulture: ISO-Format (JJJJ-MM-TT) für maximale Kompatibilität

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

Legt den Pfad für die Ausgabedatei im CSV-Format fest.
Wenn nicht angegeben, wird der Eingabedateiname mit der Erweiterung .csv im selben Verzeichnis wie die Eingabedatei verwendet.

Wichtig: Muss ein Dateipfad sein, kein Verzeichnis.
Wenn du das Verzeichnis der Eingabedatei mit einem benutzerdefinierten Namen verwenden möchtest, gib den vollständigen Pfad inklusive Dateiname an.

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

Legt fest, welche Art von Ausgabe erzeugt wird.

Gültige Werte:

• ‘CSV’: Nur die Datendatei mit allen geparsten Protokolleinträgen erzeugen
• ‘Statistic’: Nur die Statistikdateien mit aggregierten Metriken erzeugen
• ‘Both’: Sowohl Daten- als auch Statistikdateien erzeugen (Standard)

Standard: Both

Wenn Statistiken erzeugt werden, entstehen zwei separate Dateien:

• ‘_Statistic.csv’: Zusammenfassende Zählungen pro Kontexttyp und Tag (Datum, Kontext, Anzahl, ComputerName)
• ‘_PacketStatistic.csv’: Detaillierte PACKET-Zählungen pro Tag nach Client-IP, Protokoll, Richtung und Abfragetyp (Datum, ClientIP, Protokoll, Richtung, FrageTyp, Anzahl, 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

Entfernt die Quell-DNS-Debugprotokolldatei nach erfolgreicher Verarbeitung.

Verwende dies für automatisierte Protokollverarbeitungspipelines oder zur Speicherplatzverwaltung.
Die Quelldatei wird nur entfernt, wenn die Verarbeitung erfolgreich abgeschlossen wurde und alle Ausgabedateien erstellt sind.

Sicherheit: Kann nicht zusammen mit -SkipHeaderValidation verwendet werden, um versehentliches Löschen ungültiger Dateien zu verhindern.

Warnung: Quelldateien werden dauerhaft gelöscht.
Stelle sicher, dass die Ausgabedateien gültig sind, bevor du diese Option verwendest.

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

Umgeht die Validierung der DNS-Debugprotokoll-Kopfzeile.

Standardmäßig prüft das Cmdlet, ob Eingabedateien eine gültige DNS-Server-Debugprotokoll-Kopfzeile besitzen.
Verwende diesen Schalter, um Dateien ohne Validierung zu verarbeiten, was nützlich sein kann bei:

• Modifizierten oder benutzerdefinierten Protokollformaten
• Fehlerbehebung bei Validierungsproblemen
• Nicht standardmäßigen oder vorverarbeiteten Protokollen

Warnung: Kann zu Verarbeitungsfehlern führen, wenn die Datei kein gültiges DNS-Protokoll ist.

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

Zeigt an, was passieren würde, wenn das Cmdlet ausgeführt wird.
Das Cmdlet wird nicht ausgeführt.

Wenn angegeben, werden detaillierte Informationen über die auszuführenden Operationen angezeigt, ohne diese tatsächlich auszuführen.
Nützlich für:

• Vorschau, welche Dateien verarbeitet würden
• Überprüfung der Ausgabepfade vor der Verarbeitung
• Testen von Skripten vor dem produktiven Einsatz

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

Dieses Cmdlet unterstützt die Common-Parameter: -Debug, -ErrorAction, -ErrorVariable, -InformationAction, -InformationVariable, -OutBuffer, -OutVariable, -PipelineVariable, -ProgressAction, -Verbose, -WarningAction und -WarningVariable. Weitere Informationen findest du unter about_CommonParameters.

EINGABEN

System.String[]

HINWEISE

Version : 1.7.2.1
Autor : Andi Bellstedt, Copilot, Patrick Charbonnier (Silent Waters IT Consulting S.L.)
Datum : 2026-07-24
Schlüsselwörter : Microsoft Windows Server, DNSServer, DNS, DebugLog, LogParser

VERWANDTE LINKS

• github.com/AndiBellstedt/DNSServer.DebugLogParser

9 - Anwendungsbeispiele

Dies sind Beispiele mit etwas mehr Tiefe und Kontext. Wenn du nur die Verwendung der Befehle aus dem Modul sehen möchtest, schau dir die Befehlsreferenz an.

9.1 - Geplantes Aufgaben-Beispiel

Dieses Skript erstellt eine Windows-Geplante Aufgabe, die täglich um 2:00 Uhr morgens ausgeführt wird. Es importiert das Modul und verarbeitet alle Protokolldateien im Ordner, in dem das Skript ausgeführt wird (in diesem Beispiel “C:\Administration\Logs\DNS”). Der Prozess komprimiert die Ausgabe in ZIP-Dateien und entfernt die Originaldateien, um Ordnung zu halten.

$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"

9.2 - Praktische Anwendung in einer Domänenumgebung (GPO-gesteuerte Sammlung und Konvertierung)

Dieses Dokument beschreibt ein praktisches, durchgängiges Beispiel für den Einsatz von DNSServer.DebugLogParser in einer Active Directory-Domänenumgebung, mit Fokus auf die Konvertierung von Windows DNS Server-Debug-Protokollen auf Domänencontrollern.

Dieses Beispiel wird von einem ZIP-Archiv begleitet, das die Richtlinien-Artefakte enthält, die zur Umsetzung des hier beschriebenen Workflows verwendet werden.
Die wichtigsten Artefakte sind das Backup-Manifest, der GPO-Bericht, die Files.xml, das Set-DNSServerDebugLogging.ps1 und die ScheduledTasks.xml.

Szenario

• Mehrere Domänencontroller (DCs) hosten die DNS-Serverrolle.
• DNS-Debug-Protokollierung ist auf jedem DC aktiviert und wird konsistent über eine geplante Aufgabe konfiguriert (Protokolldateien werden nach C:\Administration\Logs\DNSServer geschrieben).
• Ein zentral verwalteter Prozess konvertiert die Protokolle in CSV für:
  • Sicherheitsanalysen
  • Betriebsberichte
  • Fehlerbehebung
  • Compliance/Aufbewahrung

Zielergebnisse

• Einheitliche Konvertierungseinstellungen auf allen DCs
• Vorhersehbarer Ausgabeort und -namen
• Optionale Komprimierung zur Reduzierung des Speicherbedarfs
• Optionale Statistik-Ausgaben für schnelle tägliche Zusammenfassungen
• Minimales Risiko auf dem Host mit expliziten Wiederholungs- und Bereinigungsüberlegungen

Vorgeschlagene Architektur

Sammelmodell: lokale Konvertierung + zentrale Abholung

1. Jeder DC schreibt DNS-Debug-Protokolle mit aktivierter Rollierung auf die Festplatte.
2. Jeder DC konvertiert die rotierten *.log-Dateien in eine Daten-CSV und Statistik-CSVs und komprimiert die Ausgaben dann zeitgesteuert (Task Scheduler) zu *.zip.
3. Die Ausgaben werden neben den Protokolldateien abgelegt, damit die Pipeline einfach bleibt.
4. Ein zentraler Server sammelt die *.zip-Ausgaben, z. B. über Dateifreigabe, geplante Kopie, SIEM-Forwarder oder einen agentenbasierten Collector.

Dieses Modell minimiert Netzwerkzugriffe auf große Rohprotokolle und hält die Verarbeitung nahe an den Daten.

GPO-Workflow

Der Workflow wird über Gruppenrichtlinien (Computerkonfiguration) implementiert, um konsistente Einstellungen auf allen Domänencontrollern sicherzustellen.

Referenzimplementierung in diesem Repository enthalten (GPO-Bericht):

• Archiv-/Berichtsname: T0-C-Analytics-DNSDebugLogging
• Backup-ID: {2B6F16BC-0E7C-4787-83D7-2854FED882EE}
• GPO-Linkziel: corp.company.com/Domain Controllers
• Elementfilter (für Datei-Bereitstellung und geplante Aufgaben): gilt nur, wenn C:\Windows\System32\dns.exe existiert

1) Voraussetzungen (Ordner + Modul)

Das bereitgestellte Backup geht davon aus, dass diese Ordner bereits existieren. Füge separate GPP-Elemente hinzu, wenn die Bereitstellung sie automatisch erstellen soll:

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

Das Backup setzt außerdem voraus, dass Convert-DNSDebugLogFile bereits auf den DCs verfügbar ist. Die Konvertierungsaufgabe startet Windows PowerShell 5.1 mit -NoProfile und importiert das Modul nicht explizit, daher muss das Modul in einem maschinenweiten Windows PowerShell-Modulpfad installiert sein, der für LocalSystem sichtbar ist. Empfohlene Vorgehensweisen:

• Installiere DNSServer.DebugLogParser auf den DCs, z. B. aus der PowerShell Gallery (wenn die Richtlinie dies erlaubt).
• Stelle das Modul über ein internes Repository / Dateifreigabe bereit, sodass es in $env:PSModulePath auffindbar ist.
• Füge einen expliziten Import-Module-Befehl zur Aufgabenaktion hinzu, wenn du ein deterministisches Ladeverhalten möchtest.

2) Bereitstellung des Debug-Logging-Konfigurationsskripts (GPP Dateien)

Die GPO stellt das Skript bereit:

• Quelle (im SYSVOL via GPP): %GptPath%\Preferences\Files\Set-DNSServerDebugLogging.ps1
• Ziel (auf jedem DC): C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1

Dies ist im GPP-Dateielement in Files.xml implementiert.

3) Geplante Aufgabe: DNS-Debug-Logging konfigurieren

Die GPO erstellt eine geplante Aufgabe namens Set-DNSServerDebugLogging.

• Sicherheitskontext im bereitgestellten Backup: SYSTEM mit Anmeldetyp S4U
• Trigger im bereitgestellten Backup: täglich (Startzeitpunkt 2025-03-01T00:00:01)
• Aktion in ScheduledTasks.xml:
  • powershell.exe -ExecutionPolicy RemoteSigned -command " & { C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1 }"
  • Arbeitsverzeichnis: C:\Administration\Scripts

Das verlinkte Set-DNSServerDebugLogging.ps1-Skript konfiguriert DNS-Debug-Logging über Get-DnsServerDiagnostics / Set-DnsServerDiagnostics und insbesondere:

• Aktiviert Logging in Dateien + Rollierung
• Schreibt nach: C:\Administration\Logs\DNSServer\DnsDebugLog_<COMPUTERNAME>.<Domain>_.log
• Verwendet eine Rolliergröße von 10 MB pro Datei
• Erfasst hauptsächlich abfragebezogene Aktivitäten (Abfragen + Benachrichtigungen + Updates + Frage-Transaktionen) und schließt vollständiges Paket-Logging aus

4) Geplante Aufgabe: konvertiere rotierte Debug-Protokolle in komprimierte CSV

Die GPO erstellt eine geplante Aufgabe namens Convert-DNSDebugLogs.

• Sicherheitskontext im bereitgestellten Backup: SYSTEM mit Anmeldetyp InteractiveToken
• Trigger im bereitgestellten Backup: täglich (Startzeitpunkt 2026-01-01T00:30:00)
• Arbeitsverzeichnis: C:\Administration\Logs\DNSServer
• Aktion in ScheduledTasks.xml (zur besseren Lesbarkeit formatiert):

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

Designhinweise:

• Select-Object -Skip 1 vermeidet absichtlich die Verarbeitung der neuesten (aktiven) Protokolldatei. Convert-DNSDebugLogFile kann eine aktuell vom DNS-Server geöffnete Protokolldatei lesen, aber diese Datei ändert sich während des Lesens: Die Ausgabe kann die neuesten Einträge vermissen oder mit einem abgeschnittenen Datensatz enden, und zwei Durchläufe liefern nicht identische Ergebnisse. Das Überspringen der aktiven Datei macht die geplante Ausgabe reproduzierbar.
• Das bedeutet, dass aktuelle Daten erst nach der Rollierung exportiert werden; bei DCs mit geringem Volumen kann die aktive Protokolldatei länger als einen Tag unberührt bleiben. Verringere die Rolliergröße, wenn diese Verzögerung für deinen Anwendungsfall zu lang ist.
• Da Convert-DNSDebugLogFile standardmäßig -OutputFile auf „gleicher Ordner, gleicher Name, .csv“ setzt, landen die Ausgaben neben den *.log-Eingaben.
• Mit -CompressOutput erzeugt jede verarbeitete Protokolldatei eine *.zip und die Zwischen-CSVs werden entfernt.
• Sofern du verarbeitete *.log-Dateien nicht archivierst oder löschst, werden spätere Durchläufe jede nicht-aktive Protokolldatei erneut verarbeiten.
• Die Aufgabe wirft einen Fehler, wenn $Error.Count -gt 0 ist, um einen fehlgeschlagenen Lauf zu signalisieren.

5) Zentrale Erfassung

Optionen (eine auswählen):

• Dateifreigabe-Erfassung: DC schreibt (oder kopiert) C:\Administration\Logs\DNSServer\*.zip nach \\fileserver\share\dns\$env:COMPUTERNAME\... (erteile Freigabe- und NTFS-Rechte für die DC-Computer-Konten oder die Gruppe Domänencontroller, wenn die Aufgabe als SYSTEM läuft)
• Pull-Modell: zentraler Job liest \\dc\C$\Administration\Logs\DNSServer\*.zip (am wenigsten bevorzugt; erfordert Admin-Freigaben)
• Agent-Forwarder: SIEM-/Log-Pipeline, die die *.zip-Ausgaben versendet

Betriebstechnische Überlegungen

• Least Privilege: Aufgaben laufen als SYSTEM; stelle sicher, dass die lokalen Ordner beschreibbar sind und dass alle UNC-Ziele Zugriff für das Computerkonto gewähren, falls verwendet.
• Signierungsrichtlinie: beide Aufgaben verwenden -ExecutionPolicy RemoteSigned; signiere oder entsperre das bereitgestellte Skript und Modul gemäß deiner Richtlinie.
• Plattennutzung: -CompressOutput hilft erheblich, aber dieser Workflow entfernt die Quellprotokolle nicht; plane Aufbewahrung und Bereinigung.
• Wiederverarbeitungsverhalten: Sofern du verarbeitete Protokolle nicht archivierst oder löschst, verarbeitet die Konvertierungsaufgabe bei späteren Läufen jede nicht-aktive *.log-Datei erneut. Das ist einfach und robust, kann aber Ausgaben überschreiben und doppelte nachgelagerte Erfassungen erzeugen, wenn dein Collector nicht dedupliziert.
• Multi-DC-Konsolidierung: -ComputerName $env:COMPUTERNAME ist enthalten, damit konsolidierte Datensätze nachvollziehbar bleiben. Beachte, dass -ComputerName nur die Ausgabe beschriftet — es stellt keine Remote-Verbindung her.
• Netzwerkfreigaben: Convert-DNSDebugLogFile kann Quellprotokolle von SMB/UNC-Pfaden lesen, aber lokale Konvertierung und Versand der komprimierten Ergebnisse ist das bessere Muster für große Rohprotokolle. Wenn du einen UNC-Pfad verwendest, denke daran, dass eine Aufgabe, die als SYSTEM läuft, sich im Netzwerk als Computerkonto authentifiziert und dort Freigabe- sowie NTFS-Rechte benötigt.
• Datumsformat: -OutputCulture sv-SE wird bewusst verwendet, damit Zeitstempel als 2026-01-20 23:00:16 geschrieben werden. Dieses Format wird von SQL Server, Power BI und den meisten Importwerkzeugen ohne Hinweis gelesen, unabhängig von der Gebietsschema-Einstellung des DC, der das Protokoll erzeugt hat.
• Validierung: Die Kopfzeilenvalidierung bleibt aktiviert, da die Aufgabe -SkipHeaderValidation nicht verwendet (empfohlen).

Validieren und anpassen (mit dem ZIP)

Nutze das ZIP-Archiv als Referenzimplementierung und passe dann folgende Aspekte an deine Umgebung an:

• Zielbereich: welche DCs / OUs die Richtlinie erhalten
• Ausführungsidentität: bestätige, dass beide geplanten Aufgaben den vorgesehenen Anmeldetyp verwenden (S4U vs. InteractiveToken) oder normalisiere sie auf deinen Standard
• Ordnererstellung: entscheide, ob C:\Administration\Scripts und C:\Administration\Logs\DNSServer anderswo vorab bereitgestellt werden oder durch zusätzliche GPP-Elemente erstellt werden sollen
• Pfade: bestätige, dass C:\Administration\Scripts und C:\Administration\Logs\DNSServer deinen Standards entsprechen
• Aufbewahrung: entscheide, ob Rohprotokolle behalten werden und wie lange (besonders bei aktivierter Bereinigungsoption)
• Erfassung: bestätige, wo CSV/ZIP-Ausgaben geschrieben und wie sie zentral gesammelt werden

Wenn du die genaue GPO-Konfiguration validieren möchtest, ohne sie zu importieren, sind die maßgeblichen Quellen in diesem Repo:

• manifest.xml für Backup-Metadaten
• gpreport.xml für den menschenlesbaren Vollbericht
• Files.xml für die Datei-Bereitstellung
• Set-DNSServerDebugLogging.ps1 für Skriptinhalt
• ScheduledTasks.xml für geplante Aufgaben

9.3 - Sicherheitsanalyse-Workflow mit SQL Server

Dieses Beispiel zeigt einen praktischen Workflow für Sicherheitsanalysen: Ein DNS-Debug-Log wird mit Convert-DNSDebugLogFile geparst, die erzeugte CSV-Datei in SQL Server importiert und eine Abfrage ausgeführt, die ungewöhnlich hohe Mengen an TXT-Record-Abfragen hervorhebt.

Für beste Interoperabilität schreibt dieses Beispiel Zeitstempel in einem ISO-ähnlichen Format, indem -OutputCulture 'sv-SE' verwendet wird.

Erforderliche Module

Dieses Beispiel verwendet folgende PowerShell-Module:

• DNSServer.DebugLogParser
• SqlServer

Installiere sie bei Bedarf:

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

Szenario

Nutze diesen Workflow, wenn du geparste DNS-Debug-Log-Daten in SQL Server verschieben möchtest, um:

• große Datensätze effizient zu durchsuchen
• wiederholbare Erkennungsabfragen zu erstellen
• Aktivitäten über mehrere DNS-Server hinweg zu korrelieren
• normalisierte Daten für spätere Untersuchungen zu speichern

Ausgabe des Konvertierungsschritts

Convert-DNSDebugLogFile schreibt nicht direkt in SQL Server. Zuerst wird eine CSV-Datei erstellt. Diese CSV-Datei ist der Datensatz, der in die Datenbank importiert wird.

In diesem Beispiel:

• Eingabe-Log: C:\Administration\Logs\DNS\dns.log
• erzeugte CSV: C:\Administration\Logs\DNS\dns.csv
• Ziel-Tabelle: dbo.DNSQueries

Erstelle die Zieltabelle

Führe die folgende Anweisung einmalig in SQL Server aus, um die Zieltabelle zu erstellen.

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;

Konvertiere das Log und importiere die CSV

Das folgende PowerShell-Beispiel führt den kompletten Workflow aus:

1. Importiert die benötigten Module
2. Konvertiert das DNS-Debug-Log in CSV
3. Lädt die erzeugte CSV-Datei
4. Importiert die Zeilen per Bulk-Import in 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 "Die erzeugte CSV-Datei '$csvPath' enthält keine Zeilen."
}

$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()
}

Abfrage nach verdächtiger TXT-Record-Aktivität

Sobald die Daten in SQL Server sind, kannst du nach Clients suchen, die ungewöhnlich viele TXT-Record-Abfragen stellen.

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;

Wenn du die Abfrage lieber aus PowerShell heraus ausführst, nutze Invoke-Sqlcmd aus dem SqlServer-Modul:

$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

Warum TXT-Abfragen interessant sind

Hohe Volumina von TXT-Record-Abfragen können eine Überprüfung wert sein, da sie auf Folgendes hinweisen können:

• DNS-Tunneling
• Datenexfiltration über DNS
• Missbrauch von TXT-Records durch Malware oder Tools
• ungewöhnlich laute oder falsch konfigurierte Clients

Diese Abfrage ist nur ein Ausgangspunkt. Im produktiven Einsatz solltest du die Schwelle anpassen und Filter hinzufügen, die zu deiner Umgebung passen.

Betriebshinweise

• Import-Csv liest die gesamte Datei in den Speicher ein. Bei sehr großen Log-Exports solltest du einen Streaming-Ansatz statt eines vollständigen DataTable-Aufbaus in Betracht ziehen.
• Behalte -ComputerName im Konvertierungsschritt bei, damit die Datensätze nach zentraler Einspeisung zugeordnet bleiben.
• Verwende während Export und Import einen konsistenten Trenner und eine konsistente Kultur.
• Prüfe Aufbewahrung, Indizierung und Zugriffskontrolle in SQL Server, bevor du diesen Workflow für Langzeitspeicherung nutzt.