Di cosa si tratta?

Come suggerisce il nome, questo articolo riguarda le capacità di registrazione del debug del Windows DNS Server. Leggendo questo articolo, otterrai informazioni su come ottenere approfondimenti sui processi di risoluzione dei nomi nel tuo ambiente. Questo può essere molto utile per la risoluzione dei problemi e l’analisi di questioni relative al DNS. Prima di entrare nei dettagli, comprendiamo prima cos’è la registrazione del debug del DNS Server e perché - a volte - è una cosa importante e un aiuto pratico.

In molti casi, il DNS Server è un ruolo sul Domain Controller in un ambiente Active Directory. In ogni caso, il DNS Server è un componente critico dell’infrastruttura di rete. La risoluzione dei nomi è ovunque ed è una parte fondamentale di come i computer comunicano su una rete.

Ma cosa succede quando qualcosa va storto, o se questo componente critico deve essere toccato per qualche motivo? Questo può accadere per vari motivi, come:

  • Risoluzione dei problemi - Qualcuno segnala problemi con la risoluzione dei nomi. Di tanto in tanto, indirizzi IP errati vengono restituiti a un client e un’applicazione smette di funzionare.
  • Migrazione e gestione delle modifiche - I server potrebbero dover essere migrati altrove. Forse in un nuovo segmento di rete, in un hyperscaler, o semplicemente l’organizzazione ha deciso di trasferire il DNS da Active Directory a dispositivi di rete. I client potrebbero dover essere riconfigurati a questo punto per puntare al nuovo server DNS.
  • Statistiche e analisi (di sicurezza) - Chi sta chiedendo cosa? Quali tipi di modelli possono essere osservati? Quali richieste vengono effettuate? Ci sono attività sospette?

In tali casi, avere approfondimenti sui dettagli della risoluzione dei nomi può essere inestimabile. Questo articolo cerca di coprire alcuni modi per ottenere tali approfondimenti. Solo per menzionare, parlando di un “client DNS”, intendo qualsiasi dispositivo che richiede la risoluzione dei nomi, come una workstation, un server, una stampante, dispositivi di infrastruttura IT o persino un dispositivo IoT.

Capacità per approfondimenti sul Windows DNS Server

Quando si tratta della domanda “Come ottenere le informazioni dal DNS Server?”, ci sono diverse opzioni disponibili. Decisioni, Decisioni Diamo un’occhiata alle più comuni:

Capacità - Cattura di pacchetti di rete

Classica e potente. Forse non è la soluzione a lungo termine, ma per la risoluzione dei problemi rapida o l’analisi in tempo reale, è assolutamente preziosa. Ne ho parlato nel mio ultimo articolo [Cattura del traffico di rete in Windows][captureNetworkTrafficReference], quindi non entrerò nei dettagli qui.

Capacità - Registrazione del firewall

Nel caso in cui tu abbia una segmentazione della tua rete in atto e tu abbia accesso ai log del firewall, puoi ottenere informazioni su chi sta comunicando per DNS - e tutti gli altri servizi - da lì. Queste non sono le informazioni più dettagliate, perché mancano di granularità e dettagli specifici del servizio, ma possono essere utili e un guadagno rapido se sono già in atto. Questo potrebbe non essere un’opzione se hai reti appiattite, probabilmente non c’è un firewall tra i client DNS e il server DNS. Puoi comunque utilizzare il firewall locale di Windows, ma come vedrai nelle prossime sezioni, ci sono opzioni migliori in quel caso. Poi c’è purtroppo il caso proibitivo dei “silos organizzativi” e della “mancanza di comunicazione” tra i team, dove semplicemente potrebbe non essere fattibile ottenere i log del firewall, anche se esistono.

Capacità - EventLogs

Speriamo che tu abbia la configurazione dell’EventLog per registrare Tutti gli eventi in atto sul tuo DNS Server. Se non lo hai fatto, ora è il momento di impostarlo, perché è un buon punto di partenza per la registrazione operativa nel tuo servizio DNS di Windows.

Potrebbe non essere l’informazione più dettagliata, ma produce approfondimenti di base nei classici Event Logs di Windows.

Oltre ai classici Event Logs di Windows, ci sono anche alcuni log di applicazione specifici del DNS Server disponibili. Molti conoscono il log “DNS Server” nella sezione “Application and Services Logs” del Visualizzatore eventi, ma non sono così interessanti per veri approfondimenti sul servizio.

Effettivamente, ci sono due ulteriori EventLogs del DNS Server disponibili nella struttura delle cartelle. Il log di audit che fornisce informazioni operative su quali tipi di operazioni si stanno verificando nel DNS Server: Log degli eventi di audit del DNS Server D’altra parte, c’è un log analitico meno conosciuto che può essere attivato su richiesta. Fornisce informazioni molto dettagliate sui processi di risoluzione dei nomi in corso, come quali tipi di query vengono effettuate, quali tipi di risposte vengono inviate e così via. Log degli eventi analitici del DNS Server Questo log non è attivo per impostazione predefinita, ma può essere abilitato per scopi di risoluzione dei problemi e analisi. Sfortunatamente, per quanto ne so, il log “Analitico” non è in grado di passare a più file, quindi potrebbe essere complicato utilizzarlo per un approccio a lungo termine. Per la risoluzione dei problemi o l’analisi a breve termine, potrebbe essere una scelta.

Capacità - EventTracing

Il Windows Event Tracing (ETW) è probabilmente l’opzione più potente quando vuoi approfondire gli interni di Windows. Sfortunatamente, è anche la più complessa e non è molto user-friendly. Potrei trattare l’ETW esplicitamente in un futuro articolo, ma per ora non entrerò nei dettagli qui.

Capacità - DebugLogFile

Il Windows DNS Server ha anche una registrazione del debug basata su testo integrata che può essere configurata facilmente. Questa funzionalità ti consente di registrare gli stessi dettagli del “Log degli eventi analitici”, ma scrive in file di testo e fornisce capacità di rollover, quindi può essere utilizzata per un approccio a lungo termine.

Potrebbe essere un po’ più user-friendly rispetto all’ETW, perché fornisce testo leggibile senza la necessità di PerfMon e degli altri strumenti ETW. Tuttavia, il formato del file di log non è perfettamente strutturato, ma è comunque possibile consumare le informazioni con un certo sforzo.

Come configurare la registrazione

Ora che abbiamo le opzioni sul tavolo, diamo un’occhiata a come configurarle. Come già accennato, non tratterò qui la cattura dei pacchetti, la registrazione del firewall né l’EventTracing, ma diamo un’occhiata agli EventLogs e al DebugLogFile.

Configurare l’EventLog analitico

Come già menzionato, il “Log degli eventi analitici” non è attivo per impostazione predefinita. Ancora di più, non è visibile per impostazione predefinita. Prima di tutto, naviga nella pertinente sezione dei log di servizio nel Visualizzatore eventi.


Lì, devi abilitare i log analitici e di debug per il DNS Server.


Dopo, il log è ancora disabilitato e non mostrerà alcuna voce, quindi devi abilitare il log.


Per chi non vuole seguire i click-ops, ecco la riga di comando per abilitare il log analitico:

wevtutil set-log "Microsoft-Windows-DNSServer/Analytical" /e:true

Abilitando il log, il server inizierà a catturare informazioni. Tieni presente che non c’è una visualizzazione in tempo reale degli eventi catturati nel log. La raccolta dei dati deve essere interrotta disabilitando nuovamente il log, e poi puoi vedere gli eventi catturati.

wevtutil set-log "Microsoft-Windows-DNSServer/Analytical" /e:false


Dopo, puoi vedere gli eventi catturati nel log:


A causa della natura degli EventLogs, è disponibile anche una vista dati XML che fornisce una visualizzazione più strutturata degli eventi catturati. Ciò significa che i record dell’EventLog non contengono il messaggio di testo dallo screenshot sopra, ma contengono invece una struttura di dati grezza che viene visualizzata come un messaggio di testo nel Visualizzatore eventi di Windows.


Gli eventi nel log “Analitico” possono essere esportati tramite il Visualizzatore eventi, ma potresti ottenere maggiore flessibilità e controllo utilizzando PowerShell per la query e l’esportazione degli eventi. I record possono essere interrogati anche tramite PowerShell:

# Interroga i record dal log analitico
$records = Get-WinEvent -LogName "Microsoft-Windows-DNSServer/Analytical" -Oldest

# Mostra i primi 5 record
$records | Select-Object -First 5 | Format-List

Fai attenzione al parametro richiesto “-Oldest” nel comando Get-WinEvent! Il cmdlet restituirà un errore sul log analitico se non specifichi questo parametro.

Configurare il DebugLogFile

Un’altra opzione, e probabilmente molto preziosa, è abilitare il file di log del debug DNS. Come descritto sopra, è un file di log basato su testo che può essere facilmente abilitato e fornisce informazioni dettagliate sulle operazioni di risoluzione dei nomi. In base alla configurazione del log di debug, i dettagli forniti possono variare da informazioni di base “chi ha interrogato cosa” fino a informazioni molto, molto dettagliate con dettagli sui pacchetti, così come un saccoof DNS-specific opcodes and flags.

Ci sono due modi per abilitare il file di log di debug, o tramite l’interfaccia grafica (GUI) o tramite PowerShell.

L’interfaccia grafica è “classica di Windows”, piuttosto semplice, puoi trovare le impostazioni nel DNS Manager sotto la sezione “Debug Logging” delle proprietà del server.

Suggerimento pratico: Se hai più di un server DNS (e suppongo che tu ce l’abbia), è una buona idea utilizzare le stesse impostazioni su tutti i server, per ottenere dati coerenti nel tuo ambiente.

Inoltre, ti consiglio di inserire il nome del server nel nome del file di log, per poter identificare facilmente la fonte dei dati di log.

Anche se l’interfaccia grafica sembra essere user-friendly e diretta, ha alcuni svantaggi e debolezze. Infatti, non fornisce l’intera gamma di opzioni di configurazione, e non è così scalabile se hai più di un piccolo numero di server. Ad esempio, se desideri abilitare il file di log di debug su 10 o più server, devi essere molto concentrato per applicare le stesse impostazioni e scrivere correttamente su tutti i server ripetutamente. Quando si tratta di numeri superiori a quattro, di solito preferisco un approccio “Dev-Ops” rispetto al modo “Click-Ops”.

La mia esperienza con la mia stessa pigrizia umana e i difetti di accuratezza nei compiti ripetitivi mi ha costretto a imparare: PowerShell è la strada da seguire

Quindi, non sorprende che ci siano cmdlet PowerShell disponibili per “Get” e “Set” le impostazioni del log di debug per il server DNS:

# Ottieni le impostazioni del log di debug del server DNS
Get-DnsServerDiagnostic

# Imposta le impostazioni del log di debug del server DNS
Set-DnsServerDiagnostic

Il comando Get restituisce tutte le opzioni dalla GUI insieme ad alcune opzioni aggiuntive che non sono disponibili nella GUI, come le impostazioni di rollover per il log e la possibilità di aggiungere ulteriori informazioni operative interne specifiche del server DNS nel log di debug.

Impostazioni del log di debug del server DNS tramite PowerShell

IMPORTANTE: Anche se la proprietà “MaxMBFileSize” può suggerire che la dimensione del file è definita in MB, è in realtà definita in byte. Quindi, se desideri impostare una dimensione del file di 10MB, devi impostare il valore a 10485760 (10 * 1024 * 1024).

Fai anche attenzione al carattere finale del nome per “LogFilePath”!
Poiché voglio avere nomi di file carini e la proprietà “EnableLogFileRollover” abilitata, il nome del file di log termina con un trattino basso. Il server aggiunge un timestamp come suffisso al nome del file fornito quando crea il log. Con questo approccio, ho una chiara separazione tra il nome dei server e il timestamp.

L’immagine seguente mostra il comportamento diverso della proprietà “EnableLogFileRollover” sul nome del file:


IMPORTANTE: È anche MOLTO IMPORTANTE comprendere il comportamento del processo di rollover. Non ci sono impostazioni di dimensione complessiva del log! Ciò significa che, se il rollover è abilitato, il server crea un nuovo file ogni volta che viene raggiunta la dimensione massima MaxMBFileSize specificata, ma non c’è limite al numero di file che possono essere creati.

Ciò significa che DEVI PREOCCUPARTI DEI FILE DI LOG e dello SPAZIO LIBERO SUL TUO SERVER!

Se abiliti il file di log di debug con un approccio “set-and-forget”, e hai un carico produttivo sul tuo server, potresti riempire il tuo disco. A seconda della quantità di query e del livello di dettagli, questo potrebbe arrivare fino a diversi gigabyte al giorno se hai molti client DNS.

ANCORA, NON FARE SET-AND-FORGET QUI!

Devi avere la tua strategia per gestire i file di log. Non c’è pulizia automatica.

Ecco un esempio di come puoi abilitare il file di log di debug tramite PowerShell:

# Specifica i parametri desiderati per il log di debug del server DNS
$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
}

# Applica le impostazioni definite
Set-DnsServerDiagnostics @dnsDebugLogParameter

Nel prossimo capitolo, daremo un’occhiata alle mie idee su “come consumare le informazioni dai log di debug generati”. In esso, faccio riferimento al mio modulo PowerShell [DNSServer.DebugLogParser][dNSServerDebugLogParserDef] per analizzare i file di log di debug creati dal servizio Windows.
Il modulo è disponibile nella PowerShell Gallery e nel mio [account GitHub][githubProfile]. Il repository GitHub contiene anche [documentazione aggiuntiva con una guida all’uso in un ambiente di dominio][dnssLogParserRepository]. Lì puoi trovare script da applicare probabilmente sui tuoi server.

Per quanto riguarda il focus dell’articolo, non entrerò nei dettagli operativi in un probabile ambiente di produzione. Spero di aver fatto una chiara affermazione sopra che devi preoccuparti di strategie aggiuntive prima di abilitare tali log.

Consumo dei dati

OK, seguendo quanto sopra, hai dati sui tuoi vari server. Questo significa che hai spazzatura sparsa ovunque. Nel passo successivo, devi occuparti del processo di consumo dei dati e probabilmente portarli in un luogo centrale.

Sicuramente, non sarà una sorpresa per te che PowerShell può aiutarti lungo il cammino.

EventLogs

Come accennato in precedenza, il registro eventi “Analytical” può essere molto utile per una rapida risoluzione dei problemi. Mentre stavamo parlando del cosa e del perché nelle sezioni precedenti, ecco un esempio per una sessione di risoluzione dei problemi rapida. Questo può essere pratico in una situazione in cui devi affrontare problemi come “Amico, il tuo server DNS non restituisce nulla quando chiedo ‘xyz’. Che diavolo!”

Tieni presente che il seguente esempio presuppone che tu stia lavorando su una workstation di amministrazione e abbia politiche di firewall appropriate per gestire i tuoi server da remoto. Se stai lavorando direttamente sul server, puoi semplicemente saltare il parametro “-ComputerName” nei comandi o utilizzare il codice nel parametro “-ScriptBlock” direttamente.

Prima di tutto, definiamo alcune variabili, come il server che interroghiamo:

$Server = "DC01"

Puoi specificare uno o più server direttamente.

Ora che abbiamo dichiarato quali server monitorare, possiamo abilitare il registro analitico su quei server. Quando ciò è fatto, aspetta un po’ di tempo o riproduci il problema, quindi disabilita nuovamente il registro.

# Abilita il registro analitico
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:true /q
}

# Aspetta un po' di tempo per raccogliere dati

# Disabilita il registro analitico
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:false
}

Nel passo successivo, cattura i record dal registro. A seconda della quantità di dati, questo potrebbe richiedere del tempo, quindi sii paziente. Dopo che gli eventi sono stati catturati, c’è del lavoro da fare per rendere i dati più utilizzabili.
Sto usando la proprietà Message dei record di EventLog per estrarre i dettagli, perché ha già i ValueNames in atto. Tuttavia, c’è anche la proprietà Properties (🤭 scrivendo questo, sembra un po’ come 🤪 programmazione) con una tabella di tutti i valori ma senza i PropertyNames in atto. Se ti piace lavorare con la proprietà .Properties, devi fare un po’ più di lavoro per ottenere i valori in un formato utilizzabile, il che probabilmente ti darà una maggiore coerenza attraverso la localizzazione e le diverse versioni di Windows…

# Ottieni i record di EventLog dal server(i)
$records = Get-WinEvent -ComputerName $Server -LogName "Microsoft-Windows-DNSServer/Analytical" -Oldest | Where-Object Providername -ne ""

# Elabora i record per arricchire i dati
$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
    
}

Ora che abbiamo i dati in un formato più utilizzabile, possiamo fare qualsiasi cosa.vogliamo con esso.
Possiamo visualizzarlo, esportarlo o fare alcune analisi live con PowerShell.

Ecco alcuni esempi:

# Visualizza i dati
$dataRecords | Format-Table

$dataRecords | Out-GridView

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

Il Format-Table grezzo potrebbe non essere molto utile, perché la console avvolgerà l’output. L’Out-GridView è un po’ più user-friendly, perché fornisce una tabella scorrevole e ordinabile. Con Format-List, puoi avere un’idea dei dettagli di un singolo record, il che ti dà le informazioni su quale proprietà cercare e raggruppare per ulteriori analisi.

# Esporta i dati per usarli in altri strumenti come Excel, PowerBI o quello che preferisci
$dataRecords | Export-Csv -Path "DNSServer-Analytics.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Esportare in CSV e trasferirlo in Excel sembra essere la scelta ovvia in molti casi, perché questo ti dà il potere di altri strumenti per analizzare i dati.

D’altra parte, se desideri fare un’analisi rapida direttamente in PowerShell mentre sei in chiamata di risoluzione dei problemi, questo può essere fatto anche. Ecco alcune idee:

# Analizza i dati... ottieni informazioni direttamente in PowerShell con raggruppamenti di base
$dataRecords | Group-Object TaskDisplayName
$dataRecords | Group-Object QNAME
$dataRecords | Group-Object InterfaceIP
$dataRecords | Group-Object Source

# Alcuni esempi di raggruppamento più avanzati
$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

# Raggruppamento combinato con filtraggio
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Group-Object { "Source '$($_.Source)' - '$($_.QNAME)'" } | Sort-Object Name | Format-Table Count, Name

# Dopo aver esplorato i valori possibili dal raggruppamento di base, possiamo filtrare e elencare i record con i loro dettagli
$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

Mostrando questo, spero di darti alcune idee su come ottenere informazioni dai dati e come usare PowerShell per questo.
Certo, ci sono molte altre opzioni disponibili e questo potrebbe non scalare per dataset molto grandi o su lunghi periodi di tempo. Pertanto, diamo un’occhiata al capitolo successivo…

DebugLogFile

Dare un’occhiata all’opzione del file di log di debug DNS porta a una soluzione per affrontare l’approccio non supervisionato e a lungo termine. Potrebbe anche scalare meglio su grandi dataset all’interno di ambienti più ampi. Il file stesso è basato su testo, quindi può essere letto aprendolo in Notepad. File di log di debug DNS in Notepad

Sfortunatamente, il formato non è perfettamente strutturato, quindi è necessario un certo processamento dei dati per ottenere i dati in un formato più utilizzabile. Quindi, come abbiamo fatto con i log degli eventi prima, andiamo in PowerShell per fare un po’ di magia di parsing.


Mentre facevo alcune ricerche e lavori di intelligenza artificiale sul formato del DebugLogFile, divertentemente, l’IA si è lamentata del fatto che il formato non è perfettamente strutturato per un facile parsing. 🤪


Per affrontare questa sfida, ho creato un modulo PowerShell chiamato [DNSServer.DebugLogParser][dNSServerDebugLogParserDef].
Il modulo fornisce una logica di parsing completa all’interno di un singolo cmdlet. È fondamentalmente un “one-stop-shop” per convertire il “logfile non così parseabile” in un file CSV valido e facile da usare. Il modulo si occupa di tutti i passaggi necessari. All’interno della [cartella assets][dnssLogParserRepositoryExampleFolder] nel [repository GitHub del modulo][dnssLogParserRepository], puoi trovare alcuni file di log di esempio e i loro CSV convertiti da controllare. Ovviamente, puoi e dovresti usare i tuoi file dal tuo ambiente!

Quindi, per darti un esempio rapido del processo di conversione, ecco un semplice esempio su come utilizzare il modulo per convertire un DebugLogFile in un file CSV:

# Importa il modulo (assicurati di installarlo prima)
Import-Module DNSServer.DebugLogParser

# Analizza il DebugLogFile ed esporta in CSV
Convert-DNSDebugLogFile "DnsDebugLog_DC01.log"

Facendo questo con tutte le impostazioni predefinite del comando, ottieni 3 file CSV come output dal processo di conversione.

FileDescrizione
DnsDebugLog_DC01.csvQuesto è il logfile convertito con i suoi dettagli in un formato CSV
DnsDebugLog_DC01_Statistic.csvUn CSV con una statistica che riassume tutti i tipi di record nel log per giorno
DnsDebugLog_DC01_PacketStatistic.csvUn CSV con una statistica per il tipo “Packet” e un riassunto su tutti i client per giorno

Come già delineato nelle sezioni precedenti, i CSV possono essere utilizzati per ulteriori analisi in Excel, PowerBI o quello che preferisci. L’intento di produrre più file è affrontare le sfide dei big data in ambienti più grandi.

A seconda del tuo caso d’uso, probabilmente vuoi solo avere statistiche di utilizzo. Con questo approccio, non è necessario ispezionare tutti i dettagli nel log completo. Potrebbe ridurre notevolmente la quantità di spazio di archiviazione, perché riassume già i dati e ignora tutti i dettagli rumorosi.
Nel caso tu voglia approfondire la ricerca e l’analisi dei dettagli, potresti voler utilizzare il log completo e ignorare le statistiche, perché non forniscono abbastanza dettagli.


Ma non sarebbe bello avere un parametro per specificare quale dei file di output desideri avere?
Dì ciao al parametro -OutputType!

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

Con questo, puoi specificare se vuoi avere solo il log, solo le statistiche o entrambi. Questo ti dà più flessibilità e potrebbe farti risparmiare molto spazio di archiviazione.


Ispezionando i file CSV generati, potresti notare che c’è una colonna vuota chiamata “ComputerName” nei CSV.

Questo perché il log di debug DNS non contiene il nome del server. 🤷‍♂️

Puoi dare vita a questa colonna passando il nome del server al parametro -ComputerName nel comando.

# Specifica manualmente il nome del computer
Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -ComputerName "DC01"

Ricordi il mio consiglio nella sezione Configura il DebugLogFile su mettere il nome del server nel nome dei log? Con un po’ di pratica, puoi inserire il nome del server nel file CSV al volo dividendo il nome del file.

# Estrai automaticamente il nome del computer dal nome del file
$files = Get-ChildItem c:\logs\*.log

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

Questo è particolarmente utile se hai più server e vuoi avere il nome del server nel CSV per una migliore identificazione e analisi.

Un’altra cosa di cui probabilmente vuoi occuparti è il formato della data nel CSV generato. Per impostazione predefinita, viene utilizzato il formato del logfile sottostante.
Questo può comportare sfide quando hai un ambiente internazionale con server localizzati. Probabilmente, il formato della data può variare da server a server. Questo creerà sfide quando vuoi fare alcune analisi sulla data in strumenti come Excel o PowerBI, perché potrebbero non riconoscere correttamente il formato della data. Per affrontare questo, puoi utilizzare un altro parametro nel comando… benvenuto il parametro -OutputCulture.

La mia preferenza personale per il formato della data è il formato ISO, quindi di solito imposto la cultura di output svedese ("sv-SE"), perché utilizza il formato ISO per data e ora. Con questo, posso garantire che il formato della data nel CSV generato sia coerente, ordinabile e facilmente riconoscibile, indipendentemente dalle impostazioni locali.

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

A titolo di nota, c’è anche un parametro -InputCulture se sei a conoscenza del formato esplicitamente utilizzato sul server di origine. Questo parametro si comporta allo stesso modo del parametro -OutputCulture, ma viene utilizzato per specificare la cultura per il parsing della data dal file di log di origine.


Ultimo ma non meno importante, due suggerimenti pratici per l’uso in produzione:
Dopo la conversione del file di log originale in CSV, potresti voler eliminarlo per risparmiare spazio di archiviazione. Il CSV dovrebbe contenere tutte le informazioni in un formato più utilizzabile. Con il parametro -RemoveSourceFile, puoi farlo senza ulteriore sforzo.
E poiché i file di log sono testo semplice e possono essere piuttosto grandi, potresti voler comprimerli dopo la conversione. Con il parametro -CompressOutput, puoi farlo anche al volo.

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

Combinando tutto quanto sopra, puoi avere uno strumento piuttosto potente e flessibile per ottenere dati per ulteriori analisi dai log di debug DNS, mentre prendi anche cura dello spazio di archiviazione e della gestione dei file. Come ultimo esempio, voglio presentare un esempio più completo che puoi utilizzare in un ambiente di produzione:

# ottieni i file di log completamente scritti (ruotati) dalla cartella di log
$files = Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Sort-Object lastwritetime, Name -Descending | Select-Object -Skip 1

# Passando i file nella conversione con tutti i parametri pratici per un uso in produzione
foreach($file in $files) {
    $file | Convert-DNSDebugLogFile -ComputerName $file.BaseName.split("_")[1] -Delimiter ';' -OutputType 'Both' -ContextFilter Packet -OutputCulture sv-SE -CompressOutput -RemoveSourceFile
}

Questo esempio, specialmente con il filtraggio nel processo di selezione dei file, è destinato a essere eseguito direttamente sui server DNS. Ma va bene anche eseguirlo su una macchina dedicata per risparmiare risorse sui server DNS. Se viene eseguito su una macchina dedicata, non è necessario utilizzare Select-Object -Skip 1 nel processo di selezione dei file.


In ogni caso, devi occuparti di raccogliere i file, indipendentemente dal fatto che siano i file elaborati o i file di log originali. Con l’esempio mostrato, il vantaggio è che trasporterai solo file ZIP già compressi. Questo può essere un buon approccio per risparmiare larghezza di banda di rete, specialmente se hai server ampiamente distribuiti con molti dati di log.

Creare Report

Dopo la configurazione e la raccolta dei dati, probabilmente vorrai utilizzarli per creare informazioni e report preziosi. A seconda del tuo caso d’uso, ci sono diversi strumenti disponibili per farlo. Diamo un’occhiata ad alcune delle opzioni.

Sono pienamente consapevole che ci sono molti più strumenti e approcci disponibili, quindi considera le sezioni seguenti solo come esempi di base per avere un’idea delle possibilità.

PowerShell - il colpo veloce

Come già delineato nella sezione Consumo dei dati - EventLogs, puoi fare alcune analisi rapide direttamente in PowerShell importando i dati. Questo può essere utile in sessioni di risoluzione dei problemi rapide, dove vuoi solo catturare rapidamente alcune informazioni di base. Certamente, questa non è la soluzione di prima classe per analisi complesse o report a lungo termine, ma è possibile.

Non entrerò troppo nei dettagli qui, perché abbiamo già coperto le opzioni di raggruppamento e filtraggio di base nella sezione Consumo dei dati - EventLogs. Solo come altro esempio, lo stesso approccio con Group-Object può essere applicato anche ai file CSV dal DebugLogFile:

# Importa i dati dal file CSV generato
$dataRecords = Get-ChildItem C:\Administration\Logs\DNSServer\*_PacketStatistic.csv -File -Recurse | Import-Csv -Delimiter ";" -Encoding utf8

# Riassumi quanti query DNS sono stati effettuati
$dataRecords | Measure-Object Count -Sum

# Quali server sono nei dati
$dataRecords | Group-Object ComputerName -NoElement

# Quale tipo di query DNS è stato raccolto
$dataRecords | Group-Object QuestionType -NoElement

# Quali IP dei client DNS sono in contatto con il server(i)
$dataRecords | Group-Object ClientIP -NoElement

# Quali client DNS stanno parlando con quale server distintamente
$dataRecords | Group-Object { "$($_.ClientIP) --> $($_.ComputerName)" } | Format-Table Name -AutoSize

In particolare, l’ultimo esempio su raggruppamento per ClientIP può essere molto utile per costruire una tabella di correlazione per l’IP e il rispettivo nome del sistema. Questo richiede, ovviamente, un’infrastruttura DNS adeguata con tutti i dispositivi registrati. Ecco come puoi farlo con PowerShell:

# Ottieni l'elenco degli IP client unici dai record dei dati
$clientIPList = $dataRecords | Group-Object ClientIP -NoElement | Select-Object -ExpandProperty Name

# Risolvi gli IP client in nomi host e crea una tabella di mapping
$clientMapping = foreach ($clientIP in $clientIPList) {
    if ($clientIP -in ("127.0.0.1", "0.0.0.0", "::1", ".")) {
        [pscustomobject]@{
            ClientIP = $clientIP
            Name     = "Localhost sul server DNS"
        }
    } else {
        $result = Resolve-DnsName -Name $clientIP -Type PTR -QuickTimeout -ErrorAction SilentlyContinue 
        
        if (([array]$result).count -ge 1) {
            [pscustomobject]@{
                ClientIP = $clientIP
                Name     = (($result.NameHost | Sort-Object) -join "; ")
            }
        } else {
            [pscustomobject]@{
                ClientIP = $clientIP
                Name     = "<nome non risolvibile da DNS>"
            }
        }
    }
}

# Output della tabella di mapping dei client
$clientMapping | Format-Table -AutoSize

# Esporta il mapping dei client in un file CSV per un uso successivo
$clientMapping | Export-Csv -Path "ClientIP_Mapping.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Un tale mapping dei client può essere utile e vantaggioso. I risultati possono apparire così:
refreshed on a regular basis and are easily accessible by multiple users without knowing how to deal with the underlying data.

In caso tu voglia ancora dare un’occhiata al file PowerBI con gli esempi, ecco il [file PowerBI con i dati e gli esempi][pbiStatisticsFile].

Conclusione

Con tutto ciò, sei ora ben equipaggiato per immergerti nel mondo del logging di debug del DNS Server.


Hai le conoscenze per abilitare e configurare il logging di debug, così come per consumare e analizzare i dati generati. Che tu scelga di fare un’analisi rapida in PowerShell, o di creare report dettagliati in Excel o PowerBI, la scelta è tua. Ricorda solo che, con grande potere, viene grande responsabilità, quindi fai attenzione alla quantità di dati che stai raccogliendo e a come li stai utilizzando.

🚀 Buon logging e analisi! 🚀



  • [Microsoft Docs: Debug Logging in DNS Server][msDebugLoggingInDnsServer] - Documentazione ufficiale su come abilitare e utilizzare il logging di debug nel DNS Server.
  • [PowerShell Gallery: DNSServer.DebugLogParser][dNSServerDebugLogParserDef] - Modulo PowerShell per analizzare i file di log di debug del DNS Server.
  • [GitHub Repository: DNSServer.DebugLogParser][dnssLogParserRepository] - Repository GitHub per il modulo DNSServer.DebugLogParser, inclusa documentazione e script di esempio.
  • [PowerQuery Documentation][powerQueryDocLink] - Documentazione ufficiale per PowerQuery, uno strumento potente per la trasformazione e analisi dei dati che può essere utilizzato con Excel e PowerBI.
  • [PowerBI Documentation][powerBIDocLink] - Documentazione ufficiale per PowerBI, uno strumento potente di analisi aziendale che può essere utilizzato per creare report e dashboard interattivi.

Memes da [makeameme.org][makeAMemeLink]