DNS-Server-Debugprotokollierung

Worum geht es hier?

Wie der Name schon sagt, geht es in diesem Artikel um die Debug-Logging-Funktionen des Windows DNS-Servers. Durch das Lesen dieses Artikels erhältst du Informationen darüber, wie du Einblicke in die Namensauflösungsprozesse in deiner Umgebung gewinnen kannst. Dies kann sehr hilfreich sein, um DNS-bezogene Probleme zu beheben und zu analysieren. Bevor wir ins Detail gehen, lass uns zunächst verstehen, was DNS-Server-Debug-Logging ist und warum es - manchmal - eine wichtige Sache und ein praktischer Helfer ist.

In vielen Fällen ist der DNS-Server eine Rolle auf dem Domänencontroller in einer Active Directory-Umgebung. In jedem Fall ist der DNS-Server ein kritischer Bestandteil der Netzwerk-Infrastruktur. Die Namensauflösung ist überall und ein grundlegender Teil der Kommunikation von Computern in einem Netzwerk.

Aber was passiert, wenn etwas schiefgeht oder wenn dieser kritische Bestandteil aus irgendeinem Grund angefasst werden muss? Dies kann aus verschiedenen Gründen geschehen, wie zum Beispiel:

Fehlerbehebung - Jemand meldet Probleme mit der Namensauflösung. Von Zeit zu Zeit werden falsche IP-Adressen an einen Client zurückgegeben und eine Anwendung funktioniert nicht mehr.
Migration und Änderungsmanagement - Server müssen möglicherweise an einen anderen Ort migriert werden. Vielleicht in ein neues Netzwerksegment, zu einem Hyperscaler oder einfach, weil die Organisation beschlossen hat, DNS von Active Directory auf Netzwerkgeräte zu übertragen. Die Clients müssen möglicherweise zu diesem Zeitpunkt neu konfiguriert werden, um den neuen DNS-Server anzusprechen.
Statistiken und (Sicherheits-)Analyse - Wer fragt nach was? Welche Muster können beobachtet werden? Welche Art von Anfragen werden gestellt? Gibt es verdächtige Aktivitäten?

In solchen Fällen können Einblicke in die Details der Namensauflösung von unschätzbarem Wert sein. Dieser Artikel versucht, einige Möglichkeiten zu behandeln, um diese Einblicke zu gewinnen. Nur um es zu erwähnen: Wenn ich von einem “DNS-Client” spreche, meine ich jedes Gerät, das nach Namensauflösung fragt, wie einen Arbeitsplatz, einen Server, einen Drucker, IT-Infrastrukturgeräte oder sogar ein IoT-Gerät.

Möglichkeiten für Einblicke in den Windows DNS-Server

Wenn es um die Frage geht, “Wie bekomme ich die Informationen aus dem DNS-Server?”, gibt es mehrere Optionen. Entscheidungen, Entscheidungen Schauen wir uns die häufigsten an:

Fähigkeit - Netzwerkpaketaufzeichnung

Klassisch und leistungsstark. Vielleicht nicht die langfristige Lösung, aber für schnelle Fehlerbehebung oder Echtzeitanalyse ist es absolut wertvoll. Ich habe darüber in meinem letzten Artikel [Netzwerkverkehr in Windows erfassen][captureNetworkTrafficReference] geschrieben, daher werde ich hier nicht ins Detail gehen.

Fähigkeit - Firewall-Logging

Falls du eine Segmentierung deines Netzwerks eingerichtet hast und Zugriff auf die Firewall-Protokolle hast, kannst du Informationen darüber erhalten, wer für DNS - und alle anderen Dienste - kommuniziert. Dies sind nicht die detailliertesten Informationen, da es an Granularität und dienstspezifischen Details mangelt, aber es kann hilfreich sein und ein schneller Gewinn, wenn es bereits vorhanden ist. Dies könnte keine Option sein, wenn du flache Netzwerke hast; wahrscheinlich gibt es keine Firewall zwischen den DNS-Clients und dem DNS-Server. Du kannst trotzdem die lokale Windows-Firewall verwenden, aber wie du in den nächsten Abschnitten sehen wirst, gibt es in diesem Fall bessere Optionen. Dann gibt es leider den prohibierenden Fall von “organisatorischen Silos” und “Mangel an Kommunikation” zwischen Teams, wo es einfach nicht machbar sein könnte, die Firewall-Protokolle zu erhalten, selbst wenn sie existieren.

Fähigkeit - Ereignisprotokolle

Hoffentlich hast du die Ereignisprotokollkonfiguration, um alle Ereignisse auf deinem DNS-Server zu protokollieren. Wenn nicht, ist jetzt der richtige Zeitpunkt, um es einzurichten, denn es ist ein guter Ausgangspunkt für Betriebsprotokollierung in deinem Windows DNS-Dienst.

Es sind vielleicht nicht die detailliertesten Informationen, aber sie liefern grundlegende Einblicke in die klassischen Windows-Ereignisprotokolle.

Neben den klassischen Windows-Ereignisprotokollen gibt es auch einige DNS-Server-spezifische Anwendungsprotokolle. Viele kennen das “DNS-Server”-Protokoll im Abschnitt “Anwendungs- und Dienstprotokolle” des Ereignisanzeigers, aber sie sind nicht so interessant für echte Einblicke in den Dienst.

Effektiv gibt es zwei weitere DNS-Server-Ereignisprotokolle, die weiter unten in der Ordnerstruktur verfügbar sind. Das Audit-Protokoll, das betriebliche Informationen darüber liefert, welche Art von Operationen im DNS-Server stattfinden: DNS-Server-Audit-Ereignisprotokoll Auf der anderen Seite gibt es ein weniger bekanntes Analytisches Protokoll, das auf Anfrage aktiviert werden kann. Es liefert sehr detaillierte Informationen über die laufenden Namensauflösungsprozesse, wie welche Art von Abfragen gestellt werden, welche Art von Antworten gesendet werden und so weiter. DNS-Server-Analytisches Ereignisprotokoll Dieses Protokoll ist standardmäßig nicht aktiv, kann jedoch zu Troubleshooting- und Analysezwecken aktiviert werden. Leider kann das “Analytische” Protokoll, soweit ich weiß, nicht in mehrere Dateien umschalten, sodass es schwierig sein kann, es für einen langfristigen Ansatz zu verwenden. Für kurzfristige Fehlerbehebung oder Analyse könnte es eine Wahl sein.

Fähigkeit - Ereignisverfolgung

Windows Event Tracing (ETW) ist wahrscheinlich die leistungsstärkste Option, wenn du tief in die Windows-Interna eintauchen möchtest. Leider ist es auch die komplexeste und nicht sehr benutzerfreundlich. Ich werde ETW möglicherweise in einem zukünftigen Artikel explizit behandeln, aber für jetzt werde ich hier nicht ins Detail gehen.

Fähigkeit - DebugLogFile

Der Windows DNS-Server verfügt auch über ein integriertes textbasiertes Debug-Logging, das einfach konfiguriert werden kann. Diese Funktion ermöglicht es dir, die gleichen Details wie das “Analytische” Ereignisprotokoll zu protokollieren, aber es schreibt in Textdateien und bietet Roll-over-Funktionen, sodass es für einen langfristigen Ansatz verwendet werden kann.

Es könnte etwas benutzerfreundlicher sein als ETW, da es lesbaren Text ohne die Notwendigkeit für PerfMon und die anderen ETW-Tools bereitstellt. Das Format der Protokolldatei ist jedoch nicht perfekt strukturiert, aber es ist dennoch möglich, die Informationen mit etwas Aufwand zu konsumieren. von DNS-spezifischen Opcodes und Flags.

Es gibt zwei Möglichkeiten, die Debug-Protokolldatei zu aktivieren, entweder über die GUI oder über PowerShell.

Die GUI ist “Windows klassisch” ziemlich unkompliziert, du findest die Einstellungen im DNS-Manager im Abschnitt “Debug-Protokollierung” der Servereigenschaften.

Praktischer Tipp: Wenn du mehr als einen DNS-Server hast (und ich nehme an, das hast du), ist es eine sehr gute Idee, die gleichen Einstellungen auf allen Servern zu verwenden, um konsistente Daten in deiner Umgebung zu erhalten.
Außerdem empfehle ich, den Namen des Servers in den Dateinamen des Protokolls aufzunehmen, um die Quelle der Protokolldaten leicht identifizieren zu können.

Auch wenn die GUI benutzerfreundlich und unkompliziert erscheint, hat sie einige Nachteile und Schwächen. Tatsächlich bietet sie nicht das volle Spektrum an Konfigurationsoptionen und ist nicht so skalierbar, wenn du mehr als eine kleine Anzahl von Servern hast. Wenn du beispielsweise die Debug-Protokolldatei auf 10 oder mehr Servern aktivieren möchtest, musst du sehr konzentriert sein, um die gleichen Einstellungen und korrekten Eingaben auf allen Servern immer wieder vorzunehmen. Wenn es um Zahlen höher als vier geht, bevorzuge ich normalerweise einen “Dev-Ops” Ansatz gegenüber dem “Click-Ops” Ansatz.

Meine Erfahrung mit meiner eigenen menschlichen Faulheit und Ungenauigkeiten bei sich wiederholenden Aufgaben hat mich gelehrt: PowerShell ist der Weg, den du gehen solltest

Es gibt also nicht überraschend PowerShell-Cmdlets, um die Debug-Protokolleinstellungen für den DNS-Server zu “Get” und “Set”:

# Holen der Einstellungen des DNS-Server-Debug-Protokolls
Get-DnsServerDiagnostic

# Setzen der Einstellungen des DNS-Server-Debug-Protokolls
Set-DnsServerDiagnostic

Der Get-Befehl gibt alle Optionen aus der GUI zusammen mit einigen zusätzlichen Optionen zurück, die in der GUI nicht verfügbar sind, wie die Roll-over-Einstellungen für das Protokoll und die Möglichkeit, weitere spezifische interne Betriebsinformationen des DNS-Servers in das Debug-Protokoll aufzunehmen.

DNS Server Debug Log Settings via PowerShell

WICHTIG: Auch wenn die Eigenschaft “MaxMBFileSize” suggeriert, dass die Dateigröße in MB definiert ist, wird sie tatsächlich in Bytes definiert. Wenn du also eine Dateigröße von 10 MB festlegen möchtest, musst du den Wert auf 10485760 (10 * 1024 * 1024) setzen.

Achte auch auf das abschließende Zeichen des Namens für “LogFilePath”!
Da ich schöne Dateinamen haben möchte und die Eigenschaft “EnableLogFileRollover” aktiviert ist, endet der Protokoll Dateiname mit einem Unterstrich. Der Server fügt beim Erstellen des Protokolls einen Zeitstempel als Suffix zum angegebenen Dateinamen hinzu. Mit diesem Ansatz habe ich eine klare Trennung zwischen dem Servernamen und dem Zeitstempel.

Das folgende Bild zeigt das unterschiedliche Verhalten der Eigenschaft “EnableLogFileRollover” im Dateinamen:

WICHTIG: Es ist auch SEHR WICHTIG, das Verhalten des Roll-over-Prozesses zu verstehen. Es gibt keine allgemeinen Einstellungen für die Protokollgröße! Das bedeutet, wenn das Roll-over aktiviert ist, erstellt der Server jedes Mal eine neue Datei, wenn die angegebene MaxMBFileSize erreicht ist, aber es gibt keine Begrenzung für die Anzahl der Dateien, die erstellt werden können.

Das bedeutet, DU MUSST DICH UM DIE PROTOKOLLDATEN und den FREIEN SPEICHER AUF DEINEM SERVER KÜMMERN!

Wenn du die Debug-Protokolldatei mit einem “set-and-forget”-Ansatz aktivierst und du eine produktive Last auf deinem Server hast, kannst du deine Festplatte füllen. Je nach Anzahl der Abfragen und dem Detaillierungsgrad kann dies bis zu mehreren Gigabyte pro Tag betragen, wenn du viele DNS-Clients hast.

NOCHMAL, MACH HIER KEINEN SET-AND-FORGET!

Du musst deine eigene Strategie haben, um dich um die Protokolldateien zu kümmern. Es gibt keine automatische Bereinigung.

Hier ist ein Beispiel, wie du die Debug-Protokolldatei über PowerShell aktivieren kannst:

# Gebe die gewünschten DNS-Server-Debug-Protokollparameter an
$dnsDebugLogParameter = @{
    "Queries"                              = $true
    "Answers"                              = $true
    "Notifications"                        = $true
    "Update"                               = $true
    "QuestionTransactions"                 = $true
    "UnmatchedResponse"                    = $true
    "SendPackets"                          = $true
    "ReceivePackets"                       = $true
    "TcpPackets"                           = $true
    "UdpPackets"                           = $true
    "FullPackets"                          = $false
    "FilterIPAddressList"                  = $null
    "EventLogLevel"                        = 4
    "UseSystemEventLog"                    = $false
    "EnableLoggingToFile"                  = $true
    "EnableLogFileRollover"                = $true
    "LogFilePath"                          = "C:\Administration\Logs\DNSServer\DnsDebugLog_$($env:COMPUTERNAME).$((Get-CimInstance -ClassName "win32_computersystem").Domain)_.log"
    "MaxMBFileSize"                        = (10 * 1mb)
    "SaveLogsToPersistentStorage"          = $false
    "WriteThrough"                         = $false
    "EnableLoggingForLocalLookupEvent"     = $false
    "EnableLoggingForPluginDllEvent"       = $false
    "EnableLoggingForRecursiveLookupEvent" = $false
    "EnableLoggingForRemoteServerEvent"    = $false
    "EnableLoggingForServerStartStopEvent" = $false
    "EnableLoggingForTombstoneEvent"       = $false
    "EnableLoggingForZoneDataWriteEvent"   = $false
    "EnableLoggingForZoneLoadingEvent"     = $false
}

# Wende die definierten Einstellungen an
Set-DnsServerDiagnostics @dnsDebugLogParameter

Im nächsten Kapitel werden wir uns meine Ideen dazu ansehen, “wie man die Informationen aus den generierten Debug-Protokollen konsumiert”. Dort verweise ich auf mein eigenes PowerShell-Modul [DNSServer.DebugLogParser][dNSServerDebugLogParserDef], um solche DebugLogFiles zu parsen, die vom Windows-Dienst erstellt wurden.
Das Modul ist in der PowerShell Gallery verfügbar und in meinem [GitHub-Konto][githubProfile]. Das GitHub-Repository enthält auch [zusätzliche Dokumentation mit einer Gebrauchsanweisung in einer Domänenumgebung][dnssLogParserRepository]. Dort findest du Skripte, die du wahrscheinlich auf deinen Servern anwenden kannst.

Was den Fokus des Artikels betrifft, werde ich nicht näher auf die betrieblichen Details in einer wahrscheinlichen Produktionsumgebung eingehen. Hoffentlich habe ich oben eine klare Aussage getroffen, dass du dich um zusätzliche Strategien kümmern musst, bevor du solche Protokolle aktivierst.

Verbrauch von Daten

OK, indem du die obigen Schritte befolgst, hast du Daten auf deinen verschiedenen Servern. Das bedeutet, du hast Müll, der überall verteilt ist. Im nächsten Schritt musst du dich um den Prozess des Konsums der Daten kümmern und sie wahrscheinlich an einem zentralen Ort zusammenführen.

Es mag dir sicher nicht überraschen, dass PowerShell dir dabei helfen kann.

Ereignisprotokolle

Wie bereits erwähnt, kann das “Analytische” Ereignisprotokoll etwas sehr Praktisches für schnelle Fehlersuche sein. Während wir in den vorherigen Abschnitten über das Was und Warum gesprochen haben, hier ein Beispiel für eine schnelle Fehlersession. Dies kann praktisch sein in einer Situation, in der du mit Problemen wie “Alter, dein DNS-Server gibt nichts zurück, wenn ich nach ‘xyz’ frage. Was zum Teufel!” umgehen musst.

Beachte, dass das folgende Beispiel davon ausgeht, dass du an einem Admin-Arbeitsplatz arbeitest und über die richtigen Firewall-Richtlinien verfügst, um deine Server remote zu verwalten. Wenn du direkt auf dem Server arbeitest, kannst du einfach den Parameter “-ComputerName” in den Befehlen überspringen oder den Code im Parameter “-ScriptBlock” direkt verwenden.

Zuerst definieren wir einige Variablen, wie den Server, den wir abfragen:

$Server = "DC01"

Du kannst einen oder mehrere Server direkt angeben.

Jetzt, da wir festgelegt haben, welche Server wir überwachen wollen, können wir das analytische Protokoll auf diesen Servern aktivieren. Wenn das erledigt ist, warte eine Weile oder reproduziere das Problem, und deaktiviere dann das Protokoll wieder.

# Aktiviere das analytische Protokoll
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:true /q
}

# Warte eine Weile, um Daten zu sammeln

# Deaktiviere das analytische Protokoll
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:false
}

Im nächsten Schritt erfassen wir die Datensätze aus dem Protokoll. Je nach Datenmenge kann dies einige Zeit in Anspruch nehmen, also sei geduldig. Nachdem die Ereignisse erfasst wurden, gibt es einige Arbeiten zu erledigen, um die Daten nützlicher zu machen.
Ich verwende die Message-Eigenschaft der EventLog-Datensätze, um die Details zu extrahieren, da sie bereits die ValueNames enthält. Es gibt jedoch auch die Properties-Eigenschaft (🤭 beim Schreiben klingt das wie 🤪 Programmierung) mit einer Tabelle aller Werte, aber ohne PropertyNames. Wenn du mit der .Properties-Eigenschaft arbeiten möchtest, musst du etwas mehr Arbeit investieren, um die Werte in ein nützliches Format zu bringen, was dir wahrscheinlich eine stärkere Konsistenz über Lokalisierungen und verschiedene Windows-Versionen hinweg gibt…

# Hole die EventLog-Datensätze von den Server(n)
$records = Get-WinEvent -ComputerName $Server -LogName "Microsoft-Windows-DNSServer/Analytical" -Oldest | Where-Object Providername -ne ""

# Verarbeite die Datensätze, um die Daten anzureichern
$propNames = @("MachineName", "LogName", "TimeCreated", "LevelDisplayName", "RecordId", "Message", "ProviderName", "Id", "Version", "Level", "Task", "Opcode", "Keywords", "ProviderId", "ProcessId", "ThreadId", "ContainerLog", "OpcodeDisplayName", "TaskDisplayName")
$dataRecords = foreach ($record in $records) {
    $hash = [ordered]@{}
    
    $propNames | ForEach-Object { $hash[$_] = $record.$_}
    $record.Message.split(";").trim() | ForEach-Object { $pair = $_.split("="); $hash[$pair[0].replace(":", "").trim()] = $pair[1].trim() }
    
    [PSCustomObject]$hash
    
}

Jetzt, da wir die Daten in einem nützlicheren Format haben, können wir tun, was wir wollen damit.
Wir können die Daten anzeigen, exportieren oder eine Live-Analyse mit PowerShell durchführen.

Hier sind einige Beispiele:

# Daten anzeigen
$dataRecords | Format-Table

$dataRecords | Out-GridView

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

Das rohe Format-Table ist möglicherweise nicht so wertvoll, da die Konsole die Ausgabe umbricht. Out-GridView ist etwas benutzerfreundlicher, da es eine scrollbare und sortierbare Tabelle bietet. Mit Format-List erhältst du einen Einblick in die Details eines einzelnen Datensatzes, was dir Informationen darüber gibt, nach welcher Eigenschaft du suchen und nach der du in weiteren Analysen gruppieren solltest.

# Daten exportieren, um sie in anderen Tools wie Excel, PowerBI oder was auch immer du magst, zu verwenden
$dataRecords | Export-Csv -Path "DNSServer-Analytics.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Der Export nach CSV und das Übertragen nach Excel scheint in vielen Fällen die typische einfache Lösung zu sein, da dies dir die Möglichkeiten anderer Tools zum Analysieren und Verarbeiten der Daten gibt.

Andererseits, wenn du eine schnelle und grobe Analyse direkt in PowerShell während eines Troubleshooting-Anrufs durchführen möchtest, ist das ebenfalls möglich. Hier sind einige Ideen:

# Daten aufteilen und analysieren... Informationen direkt in PowerShell mit grundlegender Gruppierung abrufen
$dataRecords | Group-Object TaskDisplayName
$dataRecords | Group-Object QNAME
$dataRecords | Group-Object InterfaceIP
$dataRecords | Group-Object Source

# Einige fortgeschrittene Gruppierungsbeispiele
$dataRecords | Group-Object { "Source '$($_.Source)' on Interface '$($_.InterfaceIP)'" } | Format-Table Count, Name
$dataRecords | Group-Object { "Source '$($_.Source)' on Interface '$($_.InterfaceIP)' with '$($_.QNAME)'" } | Sort-Object Name | Format-Table Count, Name
$dataRecords | Group-Object { "'$($_.QNAME)' - Source '$($_.Source)' ($($_.TaskDisplayName))" } | Sort-Object Name | Format-Table Count, Name
$dataRecords | Group-Object { "'$($_.QNAME)' - Source '$($_.Source)' on Interface '$($_.InterfaceIP)' ($($_.TaskDisplayName))" } | Sort-Object Name | Format-Table Count, Name

# Gruppierung kombiniert mit Filterung
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Group-Object { "Source '$($_.Source)' - '$($_.QNAME)'" } | Sort-Object Name | Format-Table Count, Name

# Nachdem wir die möglichen Werte aus der grundlegenden Gruppierung erkundet haben, können wir die Datensätze mit ihren Details filtern und auflisten
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Where-Object Source | Sort-Object TimeCreated | Format-Table MachineName, TimeCreated, Source, InterfaceIP, QNAME, QTYPE
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Where-Object Source -like "10.1.1.1" | Sort-Object QNAME | Format-Table MachineName, TimeCreated, Source, InterfaceIP, QNAME, QTYPE

Mit diesen Beispielen hoffe ich, dir einige Ideen zu geben, wie du Einblicke aus den Daten gewinnen und PowerShell dafür nutzen kannst.
Natürlich gibt es viele weitere Optionen, und dies skaliert möglicherweise nicht für sehr große Datensätze oder über lange Zeiträume. Lass uns also im nächsten Kapitel einen Blick darauf werfen…

DebugLogFile

Einen Blick auf die Option für die DNS-Debug-Protokolldatei zu werfen, bietet eine Lösung, um mit dem unbeaufsichtigten und langfristigen Ansatz umzugehen. Es könnte auch besser skalieren in großen Umgebungen mit umfangreichen Datensätzen. Die Datei selbst ist textbasiert, sodass sie durch Öffnen in Notepad gelesen werden kann. DNS-Server-Debug-Protokolldatei in Notepad

Leider ist das Format nicht perfekt strukturiert, sodass eine Datenverarbeitung erforderlich ist, um die Daten in ein nützlicheres Format zu bringen. Also, wie wir es zuvor mit den Ereignisprotokollen gemacht haben, lass uns in PowerShell gehen, um etwas Parsing-Magie zu machen.

Während ich einige Recherchen und KI-Arbeiten zum Format der DebugLogFile durchgeführt habe, hat die KI witzigerweise darüber geklagt, dass das Format nicht perfekt strukturiert ist, um eine einfache Analyse zu ermöglichen. 🤪

Um diese Herausforderung anzugehen, habe ich ein PowerShell-Modul namens [DNSServer.DebugLogParser][dNSServerDebugLogParserDef] erstellt.
Das Modul bietet umfassende Parsing-Logik innerhalb eines einzigen Cmdlets. Es ist im Grunde ein “One-Stop-Shop”, um die “nicht so parsebare Protokolldatei” in eine gültige und benutzerfreundliche CSV-Datei zu konvertieren. Das Modul kümmert sich um alle notwendigen Schritte. Im [assets-Ordner][dnssLogParserRepositoryExampleFolder] im [GitHub-Repository des Moduls][dnssLogParserRepository] findest du einige Beispielprotokolldateien und deren konvertierte CSVs zum Ausprobieren. Offensichtlich kannst und solltest du auch deine eigenen Dateien aus deiner Umgebung verwenden!

Um dir ein schnelles Beispiel für den Konvertierungsprozess zu geben, hier ist ein einfaches Beispiel, wie du das Modul verwenden kannst, um eine DebugLogFile in eine CSV-Datei zu konvertieren:

# Modul importieren (stelle sicher, dass du es vorher installierst)
Import-Module DNSServer.DebugLogParser

# DebugLogFile analysieren und nach CSV exportieren
Convert-DNSDebugLogFile "DnsDebugLog_DC01.log"

Wenn du dies mit allen Standardeinstellungen des Befehls machst, erhältst du 3 CSV-Dateien als Ausgabe des Konvertierungsprozesses.

Datei	Beschreibung
DnsDebugLog_DC01.csv	Dies ist die konvertierte Protokolldatei mit ihren Details im CSV-Format
DnsDebugLog_DC01_Statistic.csv	Eine CSV mit einer Statistik, die eine Zusammenfassung aller Typen von Datensätzen im Protokoll pro Tag enthält
DnsDebugLog_DC01_PacketStatistic.csv	Eine CSV mit einer Statistik für den Typ “Packet” und einer Zusammenfassung aller Clients pro Tag

Wie bereits in den vorherigen Abschnitten erwähnt, können die CSVs für weitere Analysen in Excel, PowerBI oder was auch immer du magst, verwendet werden. Der Zweck der Erstellung mehrerer Dateien besteht darin, die Herausforderungen von Big Data in größeren Umgebungen zu bewältigen.

Je nach deinem Anwendungsfall möchtest du wahrscheinlich nur Nutzungsstatistiken haben. Mit diesem Ansatz musst du nicht alle Details im vollständigen Protokoll überprüfen. Es kann den Speicherbedarf erheblich reduzieren, da es die Daten bereits zusammenfasst und alle störenden Details ignoriert.
Falls du tiefer in die Jagd nach Details und Analysen eintauchen möchtest, solltest du das vollständige Protokoll verwenden und die Statistiken ignorieren, da sie nicht genügend Details bieten.

Aber wäre es nicht schön, einen Parameter zu haben, um anzugeben, welche der Ausgabedateien du haben möchtest?
Sag Hallo zum -OutputType-Parameter!

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

Damit kannst du angeben, ob du nur das Protokoll, nur die Statistiken oder beides haben möchtest. Das gibt dir mehr Flexibilität und spart dir potenziell viel Speicherplatz.

Wenn du die generierten CSV-Dateien überprüfst, wirst du feststellen, dass es eine leere Spalte namens “ComputerName” in den CSVs gibt.

Das liegt daran, dass das DNS-Debug-Protokoll den Namen des Servers nicht enthält. 🤷‍♂️

Du kannst dieser Spalte Leben einhauchen, indem du den Namen des Servers an den -ComputerName-Parameter im Befehl übergibst.

# Computername manuell angeben
Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -ComputerName "DC01"

Erinnerst du dich an meinen Rat im Abschnitt Configure the DebugLogFile zum Einfügen des Namens des Servers in den Dateinamen der Protokolle? Mit etwas Übung kannst du den Namen des Servers zur Laufzeit in die CSV-Datei einfügen, indem du den Dateinamen aufteilst.

# Computername automatisch aus dem Dateinamen extrahieren
$files = Get-ChildItem c:\logs\*.log

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

Dies ist besonders hilfreich, wenn du mehrere Server hast und den Servernamen in der CSV für eine bessere Identifizierung und Analyse haben möchtest.

Ein weiteres, um das du dich wahrscheinlich kümmern möchtest, ist das Datumsformat in der generierten CSV. Standardmäßig wird das Format aus der zugrunde liegenden Protokolldatei verwendet.
Das kann zu Herausforderungen führen, wenn du eine internationale Umgebung mit lokalisierten Servern hast. Wahrscheinlich kann das Datumsformat von Server zu Server variieren. Das wird Herausforderungen schaffen, wenn du Analysen zum Datum in Tools wie Excel oder PowerBI durchführen möchtest, da sie das Datumsformat möglicherweise nicht korrekt erkennen. Um dem entgegenzuwirken, kannst du einen weiteren Parameter im Befehl verwenden… willkommen beim -OutputCulture-Parameter.

Mein persönliches Vorliebe für das Datumsformat ist das ISO-Format, daher stelle ich normalerweise die schwedische Ausgabekultur ("sv-SE") ein, da sie das ISO-Format für Datum und Uhrzeit verwendet. Damit kann ich sicherstellen, dass das Datumsformat in der generierten CSV konsistent, sortierbar und leicht erkennbar ist, unabhängig von den Locale-Einstellungen.

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

Als Anmerkung gibt es auch einen -InputCulture-Parameter, wenn du dir des explizit verwendeten Formats auf dem Quellserver bewusst bist. Dieser Parameter verhält sich genauso wie der -OutputCulture-Parameter, wird jedoch verwendet, um die Kultur für das Parsen des Datums aus der Quellprotokolldatei anzugeben.

Last but not least, zwei praktische Tipps für den Produktionsgebrauch:
Nach der Konvertierung der ursprünglich geschriebenen Protokolldatei in die CSV möchtest du sie möglicherweise löschen, um Speicherplatz zu sparen. Die CSV sollte alle Informationen in einem nützlicheren Format enthalten. Mit dem -RemoveSourceFile-Parameter kannst du dies ohne zusätzlichen Aufwand tun.
Und da die Protokolldateien im Klartext vorliegen und ziemlich groß sein können, möchtest du sie möglicherweise nach der Konvertierung komprimieren. Mit dem -CompressOutput-Parameter kannst du dies ebenfalls direkt tun.

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

Wenn du all dies kombinierst, hast du ein ziemlich leistungsfähiges und flexibles Tool, um Daten für weitere Analysen aus den DNS-Debug-Protokollen zu erhalten, während du auch darauf achtest, Speicherplatz und Dateiverwaltung. Als abschließendes Beispiel möchte ich ein umfassenderes Beispiel anführen, das du in einer Produktionsumgebung verwenden kannst:

# Holen Sie sich die vollständig geschriebenen (überrollten) Protokolldateien aus dem Protokollordner
$files = Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Sort-Object lastwritetime, Name -Descending | Select-Object -Skip 1

# Übergabe der Dateien zur Konvertierung mit allen praktischen Parametern für den Produktionsgebrauch
foreach($file in $files) {
    $file | Convert-DNSDebugLogFile -ComputerName $file.BaseName.split("_")[1] -Delimiter ';' -OutputType 'Both' -ContextFilter Packet -OutputCulture sv-SE -CompressOutput -RemoveSourceFile
}

Dieses Beispiel, insbesondere mit der Filterung im Dateiauswahlprozess, ist dafür gedacht, direkt auf den DNS-Servern ausgeführt zu werden. Es ist jedoch auch in Ordnung, es auf einem dedizierten Rechner auszuführen, um Ressourcen auf den DNS-Servern zu sparen. Wenn es auf einem dedizierten Rechner ausgeführt wird, musst du Select-Object -Skip 1 im Dateiauswahlprozess nicht verwenden.

In jedem Fall musst du dich um das Sammeln der Dateien kümmern, unabhängig davon, ob es sich um die endgültig verarbeiteten Dateien oder die ursprünglichen Protokolldateien handelt. Mit dem gezeigten Beispiel hast du den Vorteil, dass du nur bereits komprimierte ZIP-Dateien transportierst. Das kann ein guter Ansatz sein, um Netzwerkbandbreite zu sparen, insbesondere wenn du weit verteilte Server mit vielen Protokolldaten hast.

Berichterstellung

Nach der Konfiguration und dem Sammeln der Daten möchtest du wahrscheinlich davon Gebrauch machen, um wertvolle Einblicke und Berichte zu erstellen. Je nach Anwendungsfall stehen dir verschiedene Tools zur Verfügung, um dies zu tun. Lass uns einige Optionen ansehen.

Ich bin mir bewusst, dass es viele weitere Tools und Ansätze gibt, also betrachte die folgenden Abschnitte einfach als grundlegende Beispiele, um einen Einblick in die Möglichkeiten zu bekommen.

PowerShell - der schnelle Schuss

Wie bereits im Abschnitt Datenverbrauch - Ereignisprotokolle skizziert, kannst du einige schnelle Analysen direkt in PowerShell durchführen, indem du die Daten importierst. Das kann in schnellen Fehlersitzungen praktisch sein, in denen du nur schnell einige grundlegende Informationen erfassen möchtest. Sicherlich ist dies nicht die erste Wahl für komplexe Analysen oder langfristige Berichterstattung, aber es ist möglich.

Ich werde hier nicht zu sehr ins Detail gehen, da wir bereits die grundlegenden Gruppierungs- und Filteroptionen im Abschnitt Datenverbrauch - Ereignisprotokolle behandelt haben. Nur als weiteres Beispiel kann der gleiche Ansatz mit Group-Object auch auf die CSV-Dateien aus dem DebugLogFile angewendet werden:

# Importiere die Daten aus der generierten CSV-Datei
$dataRecords = Get-ChildItem C:\Administration\Logs\DNSServer\*_PacketStatistic.csv -File -Recurse | Import-Csv -Delimiter ";" -Encoding utf8

# Zusammenfassen, wie viele DNS-Abfragen gemacht wurden
$dataRecords | Measure-Object Count -Sum

# Welche Server sind in den Daten
$dataRecords | Group-Object ComputerName -NoElement

# Welche Art von DNS-Abfragen wurden gesammelt
$dataRecords | Group-Object QuestionType -NoElement

# Welche DNS-Client-IPs stehen in Kontakt mit dem Server
$dataRecords | Group-Object ClientIP -NoElement

# Welche DNS-Clients sprechen mit welchem Server
$dataRecords | Group-Object { "$($_.ClientIP) --> $($_.ComputerName)" } | Format-Table Name -AutoSize

Insbesondere das letzte Beispiel zur Gruppierung nach ClientIP kann sehr nützlich sein, um eine Zuordnungstabelle für die IP und den jeweiligen Namen des Systems zu erstellen. Dies erfordert natürlich eine ordnungsgemäße DNS-Infrastruktur mit allen registrierten Geräten. So kannst du dies mit PowerShell tun:

# Holen Sie sich die Liste der eindeutigen Client-IPs aus den Datenaufzeichnungen
$clientIPList = $dataRecords | Group-Object ClientIP -NoElement | Select-Object -ExpandProperty Name

# Auflösen der Client-IPs zu Hostnamen und Erstellen einer Zuordnungstabelle
$clientMapping = foreach ($clientIP in $clientIPList) {
    if ($clientIP -in ("127.0.0.1", "0.0.0.0", "::1", ".")) {
        [pscustomobject]@{
            ClientIP = $clientIP
            Name     = "Localhost auf dem DNS-Server"
        }
    } else {
        $result = Resolve-DnsName -Name $clientIP -Type PTR -QuickTimeout -ErrorAction SilentlyContinue 
        
        if (([array]$result).count -ge 1) {
            [pscustomobject]@{
                ClientIP = $clientIP
                Name     = (($result.NameHost | Sort-Object) -join "; ")
            }
        } else {
            [pscustomobject]@{
                ClientIP = $clientIP
                Name     = "<Name kann nicht durch DNS aufgelöst werden>"
            }
        }
    }
}

# Ausgabe der Client-Zuordnungstabelle
$clientMapping | Format-Table -AutoSize

# Exportiere die Client-Zuordnung in eine CSV-Datei zur weiteren Verwendung
$clientMapping | Export-Csv -Path "ClientIP_Mapping.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Eine solche Client-Zuordnung kann nützlich und hilfreich sein. Die Ergebnisse könnten so aussehen:

Excel - die klassische und flexible Option

Die Verwendung von Excel ist wahrscheinlich der gebräuchlichste Ansatz für schnelle und flexible CSV-basierte Analysen. Und daran ist nichts auszusetzen, denn Excel bietet viele Möglichkeiten zum Filtern, Gruppieren und Visualisieren von Daten, um wertvolle Informationen zu erhalten. Es ist auch ziemlich benutzerfreundlich und die meisten Menschen sind damit einigermaßen vertraut. Der einzige Nachteil ist, dass es bei sehr großen Datensätzen möglicherweise nicht so gut skalierbar ist.

Für eine schnelle Analyse zu “Wer verwendet meine DNS-Server für welche Art von Abfragen?” ist Excel völlig in Ordnung. Lege einfach die generierten PacketStatistic-CSV-Dateien in einen Ordner und sage Excel, dass es den Ordner über die Registerkarte Daten importieren soll.

Durch die Auswahl des Ordners importiert Excel automatisch alle CSV-Dateien darin und kombiniert sie zu einer einzigen Tabelle. Da die PacketStatistic-Dateien nicht so groß sind, sollte dies auch in mittelgroßen Umgebungen mit ein paar Servern gut funktionieren.
Nachdem die Daten importiert wurden, kannst du die Funktionen von Excel nutzen, um die Daten nach Belieben zu analysieren und zu visualisieren. Mit etwas mehr Aufwand in die Datenimportlogik innerhalb von PowerQuery oder der Verwendung zusätzlicher Formelspalten danach kannst du die Client-IPs aus den CSVs mit der ClientIP_Mapping.csv-Datei aus dem obigen Beispiel korrelieren, um die Namen der Clients in dieselbe Tabelle zu bringen.
Durch die Nutzung der Funktion “PivotTable” in Kombination mit den Pivot-Diagrammen ist die Visualisierung der Daten ziemlich einfach und bietet viele Möglichkeiten zur Analyse. Das kann eine Übersicht sein, wie oben gezeigt, oder zeitgesteuerte Diagramme.

Nicht zu vergessen sind mehrdimensionale Datentabellen wie diese, die die Verteilung der Abfragetypen über die verschiedenen DNS-Clients zeigen.

All das sollte nur ein Beispiel sein… und ich möchte klarstellen, dass dies möglicherweise nicht deinen Bedürfnissen oder dem Design deines Unternehmens oder deiner Kunden entspricht. Betrachte es als Inspiration, um dein eigenes zu erstellen. Wenn du einen Blick auf die Formeln und die Pivot-Logik werfen möchtest, die ich verwendet habe, um die gezeigten Beispiele zu erstellen, hier ist die [Excel-Datei mit den Daten und den Beispielen][dnsStatisticsFile].

PowerBI - die moderne, leistungsstarke Wahl

Wenn es um “Big Data” in “großen Unternehmensumgebungen” geht, ist PowerBI ein starker Mitbewerber. Excel könnte an seine Grenzen stoßen, da es nicht dafür ausgelegt ist, sehr große Datensätze zu verarbeiten. Wenn du ein paar Hundert Server hast, kann die Anzahl der Dateien und sogar die Datensätze in den Dateien schnell in die Tausende, Millionen oder sogar Milliarden gehen.

Hier kommt PowerBI ins Spiel, denn es ist dafür ausgelegt, große Datensätze zu verarbeiten, leistungsstarke Analysen und Visualisierungen bereitzustellen, mit der Fähigkeit, regelmäßig automatisch aktualisiert zu werden und von mehreren Benutzern konsumiert zu werden, ohne dass sie wissen müssen, wie man mit den zugrunde liegenden Daten umgeht.

Die Importlogik in PowerBI ist die gleiche wie beim Datenimport in Excel, [PowerQuery][powerQueryDocLink]. Damit ist die Importlogik in PowerBI und Excel mehr oder weniger gleich. Der Unterschied beginnt in der Art und Weise, wie PowerBI die Daten nach dem Import verarbeitet und wie es Optionen für die Visualisierung und das Teilen bereitstellt.
Ich bin mir sicher, dass die PowerBI- und Fabric-Experten da draußen mich dafür bestrafen wollen, dass ich PowerBI mit Excel vergleiche, aber für ein grundlegendes Verständnis bleiben wir dabei. Ich werde nicht viel mehr ins Detail zu den PowerBI-spezifischen Funktionen gehen, da dies den Rahmen dieses Artikels sprengen würde, aber ich möchte dir zumindest einige Ideen geben, wie es wahrscheinlich aussehen kann.

Das gleiche wie im vorherigen Abschnitt für die Excel-Beispiele erwähnt… Alles ist nur ein Beispiel und könnte nicht deinen Bedürfnissen entsprechen. Ich habe nicht viel Mühe in das Design der PowerBI-Berichte gesteckt, weil ich nur einige Beispiele für ein grundlegendes Verständnis geben möchte. Je nach Größe deiner Umgebung und der Menge an Daten kann dein Bericht ganz anders aussehen.

Der Hauptpunkt ist, dass du mit PowerBI die Möglichkeit hast, deine eigenen Berichte und Dashboards zu erstellen, die automatisch aktualisiert werden können.on a regular basis and are easily accessible by multiple users without knowing how to deal with the underlying data.

Falls du dir dennoch die PowerBI-Datei mit den Beispielen ansehen möchtest, hier ist die [PowerBI-Datei mit den Daten und den Beispielen][pbiStatisticsFile].

Fazit

Mit all dem bist du nun gut gerüstet, um in die Welt des DNS-Server-Debug-Loggings einzutauchen.

Du hast das Wissen, um das Debug-Logging zu aktivieren und zu konfigurieren sowie die generierten Daten zu konsumieren und zu analysieren. Ob du eine schnelle Analyse in PowerShell durchführen oder detaillierte Berichte in Excel oder PowerBI erstellen möchtest, die Wahl liegt bei dir. Denk daran, mit großer Macht kommt große Verantwortung, also sei dir der Menge an Daten, die du sammelst, und wie du sie verwendest, bewusst.

🚀 Viel Spaß beim Protokollieren und Analysieren! 🚀

Andi Bellstedt