Rejestrowanie debugowania serwera DNS

O czym to jest?

Jak sama nazwa wskazuje, ten artykuł dotyczy możliwości rejestrowania logów debugowania w serwerze DNS Windows. Czytając ten artykuł, uzyskasz informacje na temat tego, jak zdobyć wgląd w procesy rozwiązywania nazw w swoim środowisku. Może to być bardzo pomocne w rozwiązywaniu problemów i analizie kwestii związanych z DNS. Zanim przejdziemy do szczegółów, najpierw zrozummy, czym jest rejestrowanie logów debugowania serwera DNS i dlaczego - czasami - jest to ważna rzecz i praktyczna pomoc.

W wielu przypadkach serwer DNS jest rolą na kontrolerze domeny w środowisku Active Directory. W każdym przypadku serwer DNS jest krytycznym komponentem infrastruktury sieciowej. Rozwiązywanie nazw jest wszędzie i stanowi podstawową część komunikacji komputerów w sieci.

Ale co się dzieje, gdy coś pójdzie nie tak, lub jeśli ten krytyczny komponent musi być zmieniony z jakiegoś powodu? Może się to zdarzyć z różnych powodów, takich jak:

Rozwiązywanie problemów - Ktoś zgłasza problemy z rozwiązywaniem nazw. Od czasu do czasu do klienta zwracane są błędne adresy IP, a aplikacja przestaje działać.
Migracja i zarządzanie zmianami - Serwery mogą wymagać migracji w inne miejsce. Może do nowego segmentu sieci, do hyperskalera, lub po prostu organizacja zdecydowała się przenieść DNS z Active Directory do urządzeń sieciowych. Klienci mogą wymagać ponownej konfiguracji w tym momencie, aby wskazywały na nowy serwer DNS.
Statystyki i analiza (bezpieczeństwa) - Kto pyta o co? Jakie wzorce można zaobserwować? Jakie rodzaje żądań są składane? Czy są jakieś podejrzane działania?

W takich przypadkach posiadanie wglądu w szczegóły rozwiązywania nazw może być nieocenione. Ten artykuł stara się omówić kilka sposobów na uzyskanie tych informacji. Warto wspomnieć, że mówiąc o “kliencie DNS”, mam na myśli każde urządzenie, które pyta o rozwiązywanie nazw, takie jak stacja robocza, serwer, drukarka, urządzenia infrastruktury IT, a nawet urządzenie IoT.

Możliwości wglądu w serwer DNS Windows

Kiedy mówimy o pytaniu “Jak wydobyć dane z serwera DNS?”, dostępnych jest kilka opcji. Decyzje, Decyzje Przyjrzyjmy się najczęściej stosowanym:

Możliwość - Przechwytywanie pakietów sieciowych

Klasyczne i potężne. Może nie jest to rozwiązanie długoterminowe, ale do szybkiego rozwiązywania problemów lub analizy w czasie rzeczywistym jest to całkowicie wartościowe. Pisałem o tym w moim ostatnim artykule [Przechwytywanie ruchu sieciowego w Windows][captureNetworkTrafficReference], więc nie będę wchodził w szczegóły tutaj.

Możliwość - Rejestrowanie zapory

Jeśli masz segmentację swojej sieci i masz dostęp do logów zapory, możesz uzyskać informacje o tym, kto komunikuje się w sprawie DNS - i wszystkich innych usług - stamtąd. To nie są najbardziej szczegółowe informacje, ponieważ brakuje im szczegółowości i szczegółów specyficznych dla usługi, ale mogą być pomocne i stanowić szybkie zwycięstwo, jeśli już są dostępne. Może to nie być opcja, jeśli masz spłaszczone sieci, prawdopodobnie nie ma zapory między klientami DNS a serwerem DNS. Możesz użyć lokalnej zapory Windows, ale jak zobaczysz w następnych sekcjach, są lepsze opcje w tym przypadku. Niestety, istnieje również prohibicyjny przypadek “silosów organizacyjnych” i “braku komunikacji” między zespołami, gdzie po prostu może nie być możliwe uzyskanie logów zapory, nawet jeśli istnieją.

Możliwość - Logi zdarzeń

Mam nadzieję, że masz skonfigurowane logi zdarzeń, aby rejestrować Wszystkie Zdarzenia na swoim serwerze DNS. Jeśli nie, teraz jest czas, aby to ustawić, ponieważ jest to dobry punkt wyjścia do rejestrowania operacyjnego w usłudze DNS Windows.

Może to nie być najbardziej szczegółowa informacja, ale produkuje podstawowe wglądy w klasyczne logi zdarzeń Windows.

Oprócz klasycznych logów zdarzeń Windows, dostępne są również niektóre specyficzne dla serwera DNS logi aplikacji. Wiele osób zna log “Serwera DNS” w sekcji “Logi aplikacji i usług” w Podglądzie zdarzeń, ale nie są one zbyt interesujące dla prawdziwych wglądów w usługę.

Efektywnie, dostępne są jeszcze dwa logi zdarzeń serwera DNS w strukturze folderów. Log audytu, który dostarcza informacji operacyjnych o tym, jakie operacje zachodzą w serwerze DNS: Log audytu serwera DNS Z drugiej strony, istnieje mniej znany log analityczny, który można aktywować na żądanie. Dostarcza bardzo szczegółowych informacji o bieżących procesach rozwiązywania nazw, takich jak jakie rodzaje zapytań są składane, jakie rodzaje odpowiedzi są wysyłane itd. Log analityczny serwera DNS Ten log nie jest aktywny domyślnie, ale można go włączyć w celach rozwiązywania problemów i analizy. Niestety, o ile mi wiadomo, log “Analityczny” nie jest w stanie przechodzić do kilku plików, więc może być trudny do użycia w dłuższej perspektywie. Do krótkoterminowego rozwiązywania problemów lub analizy może być to opcja.

Możliwość - Śledzenie zdarzeń

Śledzenie zdarzeń Windows (ETW) jest prawdopodobnie najpotężniejszą opcją, gdy chcesz zagłębić się w wewnętrzne działanie Windows. Niestety, jest to również najbardziej skomplikowane i niezbyt przyjazne dla użytkownika. Mogę omówić ETW szczegółowo w przyszłym artykule, ale na razie nie będę wchodził w szczegóły tutaj.

Możliwość - Plik logów debugowania

Serwer DNS Windows ma również wbudowane rejestrowanie logów debugowania w formie tekstowej, które można łatwo skonfigurować. Ta funkcja pozwala na rejestrowanie tych samych szczegółów, co “Analityczny” log zdarzeń, ale zapisuje je w plikach tekstowych i zapewnia możliwości przechowywania, dzięki czemu można go używać w dłuższej perspektywie.

Może być nieco bardziej przyjazny dla użytkownika niż ETW, ponieważ dostarcza czytelny tekst bez potrzeby korzystania z PerfMon i innych narzędzi ETW. Format pliku logu nie jest jednak idealnie ustrukturyzowany, ale nadal możliwe jest przetworzenie informacji przy pewnym wysiłku.

Jak skonfigurować rejestrowanie

Teraz, gdy mamy opcje na stole, przyjrzyjmy się, jak to skonfigurować. Jak już wspomniano, nie będę omawiać przechwytywania pakietów, rejestrowania zapory ani śledzenia zdarzeń tutaj, ale przyjrzymy się logom zdarzeń i plikowi logów debugowania.

Skonfiguruj log analityczny

Jak już wcześniej wspomniano, log “Analityczny” nie jest domyślnie aktywny. Co więcej, nie jest widoczny domyślnie. Najpierw przejdźmy do odpowiedniej sekcji Logi usług w Podglądzie zdarzeń.

W tym miejscu musisz włączyć logi analityczne i debugowania dla serwera DNS.

Następnie log jest nadal wyłączony i nie będzie pokazywał żadnych wpisów, więc musisz włączyć log.

Dla tych, którzy nie chcą podążać za kliknięciami, oto polecenie wiersza poleceń do włączenia logu analitycznego:

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

Włączając log, serwer zacznie rejestrować informacje. Proszę pamiętać, że nie ma podglądu na żywo zarejestrowanych zdarzeń w logu. Zbieranie danych musi być zatrzymane przez ponowne wyłączenie logu, a następnie możesz zobaczyć zarejestrowane zdarzenia.

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

Następnie możesz zobaczyć zarejestrowane zdarzenia w logu:

Ze względu na charakter logów zdarzeń, dostępny jest również widok danych XML, który zapewnia bardziej ustrukturyzowany widok zarejestrowanych zdarzeń. Oznacza to, że rekordy logów zdarzeń nie zawierają tekstu zrzutu z powyższego zrzutu ekranu, ale zamiast tego zawierają surową strukturę danych, która jest renderowana jako tekst w Podglądzie zdarzeń Windows.

Zdarzenia w logu “Analitycznym” można eksportować za pomocą Podglądu zdarzeń, ale możesz uzyskać więcej elastyczności i kontroli, korzystając z PowerShell do zapytania i eksportu zdarzeń. Rekordy można również zapytać za pomocą PowerShell:

# Zapytaj rekordy z logu analitycznego
$records = Get-WinEvent -LogName "Microsoft-Windows-DNSServer/Analytical" -Oldest

# Pokaż pierwsze 5 rekordów
$records | Select-Object -First 5 | Format-List

Uważaj na wymagany parametr “-Oldest” w poleceniu Get-WinEvent! Cmdlet zwróci błąd w logu analitycznym, jeśli nie określisz tego parametru.

Skonfiguruj plik logów debugowania

Inną, a prawdopodobnie bardzo cenną, opcją jest włączenie pliku logów debugowania DNS. Jak opisano powyżej, jest to plik logu w formacie tekstowym, który można łatwo włączyć i który dostarcza szczegółowych informacji o operacjach rozwiązywania nazw. W zależności od konfiguracji logu debugowania, dostarczane szczegóły mogą się różnić od podstawowych “kto pytał o co” aż po bardzo, bardzo szczegółowe informacje z danymi pakietów, a także wielespecyficznych opcode’ów i flag DNS.

Istnieją dwa sposoby na włączenie pliku dziennika debugowania, albo przez GUI, albo przez PowerShell.

GUI jest “klasyczny dla Windows”, dość prosty, można znaleźć ustawienia w Menedżerze DNS w sekcji “Debug Logging” właściwości serwera.

Praktyczna wskazówka: Jeśli masz więcej niż jeden serwer DNS (a przypuszczam, że masz), to bardzo dobrym pomysłem jest użycie tych samych ustawień na wszystkich serwerach, aby uzyskać spójne dane w całym środowisku.
Dodatkowo, polecam umieścić nazwę serwera w nazwie pliku dziennika, aby łatwo zidentyfikować źródło danych dziennika.

Nawet jeśli GUI wydaje się przyjazne dla użytkownika i proste, ma swoje wady i ograniczenia. W rzeczywistości nie zapewnia pełnego zakresu opcji konfiguracyjnych i nie jest zbyt skalowalne, jeśli masz więcej niż kilka serwerów. Na przykład, jeśli chcesz włączyć plik dziennika debugowania na 10 lub więcej serwerach, musisz być bardzo skoncentrowany, aby powtarzać te same ustawienia i poprawne zapisy na wszystkich serwerach. Kiedy liczba serwerów przekracza cztery, zazwyczaj wolę podejście “Dev-Ops” zamiast “Click-Ops”.

Moje doświadczenie z własnym lenistwem i niedokładnością w powtarzalnych zadaniach zmusiło mnie do nauki: PowerShell to najlepszy wybór

Nie jest więc zaskoczeniem, że dostępne są polecenia PowerShell do “Pobierania” i “Ustawiania” ustawień dziennika debugowania dla serwera DNS:

# Pobierz ustawienia dziennika debugowania serwera DNS
Get-DnsServerDiagnostic

# Ustaw ustawienia dziennika debugowania serwera DNS
Set-DnsServerDiagnostic

Polecenie Get zwraca wszystkie opcje z GUI razem z dodatkowymi opcjami, które nie są dostępne w GUI, takimi jak ustawienia rollover dla dziennika oraz możliwość dodania więcej specyficznych dla serwera DNS wewnętrznych informacji operacyjnych do dziennika debugowania.

Ustawienia dziennika debugowania serwera DNS za pomocą PowerShell

WAŻNE: Nawet jeśli właściwość “MaxMBFileSize” może sugerować, że rozmiar pliku jest określony w MB, w rzeczywistości jest określony w bajtach. Więc, jeśli chcesz ustawić rozmiar pliku na 10MB, musisz ustawić wartość na 10485760 (10 * 1024 * 1024).

Zwróć także uwagę na końcowy znak nazwy dla “LogFilePath”!
Ponieważ chcę mieć ładne nazwy plików i właściwość “EnableLogFileRollover” włączoną, nazwa pliku dziennika kończy się znakiem podkreślenia. Serwer dodaje znacznik czasu jako sufiks do podanej nazwy pliku, gdy tworzy dziennik. Dzięki temu mam wyraźne rozdzielenie między nazwą serwera a znacznikiem czasu.

Poniższy obrazek pokazuje różne zachowanie właściwości “EnableLogFileRollover” w nazwie pliku:

WAŻNE: RÓWNIEŻ BARDZO WAŻNE jest zrozumienie zachowania procesu rollover. Nie ma ogólnych ustawień rozmiaru dziennika! Oznacza to, że jeśli rollover jest włączony, serwer tworzy nowy plik za każdym razem, gdy osiągnięty zostanie określony MaxMBFileSize, ale nie ma limitu liczby plików, które mogą zostać utworzone.

To oznacza, MUSISZ ZADBAĆ O PLIKI DZIENNY I WOLNE MIEJSCE NA SWOIM SERWERZE!

Jeśli włączysz plik dziennika debugowania metodą “ustaw i zapomnij”, a masz obciążenie produkcyjne na swoim serwerze, możesz zapełnić swój dysk. W zależności od liczby zapytań i poziomu szczegółowości, może to być nawet kilka gigabajtów dziennie, jeśli masz wielu klientów DNS.

POWTARZAM, NIE ROBIĆ USTAW I ZAPOMNIJ TUTAJ!

Musisz mieć swoją strategię, aby zadbać o pliki dziennika. Nie ma automatycznego czyszczenia.

Oto przykład, jak możesz włączyć plik dziennika debugowania za pomocą PowerShell:

# Określ żądane parametry dziennika debugowania serwera 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
}

# Zastosuj zdefiniowane ustawienia
Set-DnsServerDiagnostics @dnsDebugLogParameter

W następnym rozdziale przyjrzymy się moim pomysłom na “jak wykorzystać informacje z wygenerowanych dzienników debugowania”. W tym odniesieniu odwołuję się do mojego własnego modułu PowerShell [DNSServer.DebugLogParser][dNSServerDebugLogParserDef] do analizy takich plików DebugLogFiles utworzonych przez usługę Windows.
Moduł jest dostępny w PowerShell Gallery oraz na moim [koncie GitHub][githubProfile]. Repozytorium GitHub zawiera również [dodatkową dokumentację z przewodnikiem użytkownika w środowisku domenowym][dnssLogParserRepository]. Tam znajdziesz skrypty, które można prawdopodobnie zastosować na swoich serwerach.

Jeśli chodzi o temat artykułu, nie będę wchodził w więcej szczegółów dotyczących operacyjnych szczegółów w prawdopodobnym środowisku produkcyjnym. Mam nadzieję, że jasno wyraziłem powyżej, że musisz zadbać o dodatkowe strategie przed włączeniem takich dzienników.

Konsumpcja danych

OK, postępując zgodnie z powyższym, masz dane na swoich różnych serwerach. To oznacza, że masz bałagan rozprzestrzeniony wszędzie. W następnym kroku musisz zadbać o proces konsumpcji danych i prawdopodobnie przenieść je w jedno centralne miejsce.

Na pewno nie będzie to dla Ciebie zaskoczeniem, że PowerShell może Ci w tym pomóc.

Dzienniki zdarzeń

Jak wspomniano wcześniej, dziennik zdarzeń “Analytical” może być bardzo przydatny do szybkiego rozwiązywania problemów. Podczas gdy rozmawialiśmy o tym, co i dlaczego w poprzednich sekcjach, oto przykład szybkiej sesji rozwiązywania problemów. Może to być praktyczne w sytuacji, gdy musisz zmierzyć się z problemami takimi jak “Człowieku, twój serwer DNS nic nie zwraca, gdy pytam o ‘xyz’. Co jest grane!”

Pamiętaj, że poniższy przykład zakłada, że pracujesz na stacji roboczej administratora i masz odpowiednie zasady zapory, aby zdalnie zarządzać swoimi serwerami. Jeśli pracujesz bezpośrednio na serwerze, możesz po prostu pominąć parametr “-ComputerName” w poleceniach lub użyć kodu w parametrze “-ScriptBlock” bezpośrednio.

Przede wszystkim zdefiniujmy kilka zmiennych, jak serwer, który zapytujemy:

$Server = "DC01"

Możesz określić jeden lub więcej serwerów bezpośrednio.

Teraz, gdy zadeklarowaliśmy, które serwery obserwować, możemy włączyć dziennik analityczny na tych serwerach. Gdy to zrobisz, poczekaj chwilę lub powtórz problem, a następnie wyłącz dziennik.

# Włącz dziennik analityczny
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:true /q
}

# Poczekaj chwilę, aby zebrać dane

# Wyłącz dziennik analityczny
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:false
}

W następnym kroku przechwyć rekordy z dziennika. W zależności od ilości danych, może to zająć trochę czasu, więc bądź cierpliwy. Po przechwyceniu zdarzeń trzeba wykonać pewną pracę, aby uczynić dane bardziej użytecznymi.
Używam właściwości Message rekordów EventLog, aby wyodrębnić szczegóły, ponieważ ma już wprowadzone ValueNames. Istnieje również właściwość Properties (🤭 pisząc to, brzmi to jak 🤪 programowanie) z tabelą wszystkich wartości, ale bez wprowadzonych PropertyNames. Jeśli chcesz pracować z właściwością .Properties, musisz wykonać dodatkową pracę, aby uzyskać wartości w użytecznym formacie, co prawdopodobnie zapewni Ci większą spójność w różnych lokalizacjach i wersjach systemu Windows…

# Pobierz rekordy EventLog z serwera(ów)
$records = Get-WinEvent -ComputerName $Server -LogName "Microsoft-Windows-DNSServer/Analytical" -Oldest | Where-Object Providername -ne ""

# Przetwórz rekordy, aby wzbogacić dane
$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
    
}

Teraz, gdy mamy dane w bardziej użytecznym formacie, możemy robić, co tylko chcemy z tym.
Możemy je wyświetlić, wyeksportować lub przeprowadzić na nich analizę w czasie rzeczywistym za pomocą PowerShell.

Oto kilka przykładów:

# Wyświetl dane
$dataRecords | Format-Table

$dataRecords | Out-GridView

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

Surowy Format-Table może nie być zbyt wartościowy, ponieważ konsola zawija wyjście. Out-GridView jest nieco bardziej przyjazny dla użytkownika, ponieważ zapewnia przewijalną i sortowalną tabelę. Dzięki Format-List możesz uzyskać wgląd w szczegóły pojedynczego rekordu, co daje ci informacje o tym, jaką właściwość należy śledzić i grupować w dalszej analizie.

# Eksportuj dane, aby użyć ich w innych narzędziach, takich jak Excel, PowerBI lub cokolwiek innego
$dataRecords | Export-Csv -Path "DNSServer-Analytics.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Eksportowanie do CSV i przenoszenie go do Excela wydaje się typowym rozwiązaniem w wielu przypadkach, ponieważ daje ci moc innych narzędzi do analizy danych.

Z drugiej strony, jeśli chcesz przeprowadzić szybką analizę bezpośrednio w PowerShell podczas rozmowy dotyczącej rozwiązywania problemów, można to również zrobić. Oto kilka pomysłów:

# Analizuj... uzyskaj informacje z danych bezpośrednio w PowerShell z podstawowym grupowaniem
$dataRecords | Group-Object TaskDisplayName
$dataRecords | Group-Object QNAME
$dataRecords | Group-Object InterfaceIP
$dataRecords | Group-Object Source

# Kilka bardziej zaawansowanych przykładów grupowania
$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

# Grupowanie połączone z filtrowaniem
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Group-Object { "Source '$($_.Source)' - '$($_.QNAME)'" } | Sort-Object Name | Format-Table Count, Name

# Po zbadaniu możliwych wartości z podstawowego grupowania, możemy filtrować i wyświetlać rekordy z ich szczegółami
$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

Pokazując to, mam nadzieję, że dam ci kilka pomysłów na to, jak uzyskać wgląd w dane i jak używać PowerShell do tego.
Oczywiście, dostępnych jest wiele innych opcji, a to może nie skalować się dla bardzo dużych zbiorów danych lub przez dłuższy czas. Dlatego przyjrzyjmy się następnemu rozdziałowi…

DebugLogFile

Zwrócenie uwagi na opcję pliku dziennika debugowania DNS przynosi rozwiązanie do radzenia sobie z podejściem długoterminowym i bezobsługowym. Może to również lepiej skalować się w dużych zbiorach danych w większych środowiskach. Sam plik jest oparty na tekście, więc można go otworzyć w Notatniku. Plik dziennika debugowania serwera DNS w Notatniku

Niestety, format nie jest idealnie zorganizowany, więc konieczne jest przetwarzanie danych, aby uzyskać je w bardziej użytecznym formacie. Tak jak zrobiliśmy to wcześniej z dziennikami zdarzeń, przejdźmy do PowerShell, aby przeprowadzić trochę magii parsowania.

Podczas prowadzenia badań i pracy z AI nad formatem pliku DebugLogFile, zabawnie, AI narzekało, że format nie jest idealnie zorganizowany do łatwego parsowania. 🤪

Aby stawić czoła temu wyzwaniu, stworzyłem moduł PowerShell o nazwie [DNSServer.DebugLogParser][dNSServerDebugLogParserDef].
Moduł ten zapewnia kompleksową logikę parsowania w ramach jednego cmdletu. To w zasadzie “wszystko w jednym” do konwersji “niezbyt parsowalnego pliku dziennika” na ważny i łatwy do użycia plik CSV. Moduł zajmuje się wszystkimi niezbędnymi krokami. W [folderze zasobów][dnssLogParserRepositoryExampleFolder] w [repozytorium GitHub modułu][dnssLogParserRepository] znajdziesz kilka przykładowych plików dziennika i ich przekonwertowane pliki CSV do sprawdzenia. Oczywiście, możesz i powinieneś używać własnych plików z twojego środowiska!

Aby dać ci szybki przykład procesu konwersji, oto prosty przykład, jak użyć modułu do konwersji pliku DebugLogFile na plik CSV:

# Importuj moduł (upewnij się, że go wcześniej zainstalowałeś)
Import-Module DNSServer.DebugLogParser

# Parsuj plik DebugLogFile i eksportuj do CSV
Convert-DNSDebugLogFile "DnsDebugLog_DC01.log"

Wykonując to z wszystkimi domyślnymi ustawieniami polecenia, otrzymasz 3 pliki CSV jako wynik procesu konwersji.

Plik	Opis
DnsDebugLog_DC01.csv	To jest przekonwertowany plik dziennika z jego szczegółami w formacie CSV
DnsDebugLog_DC01_Statistic.csv	Plik CSV z statystyką podsumowującą wszystkie typy rekordów w dzienniku na dzień
DnsDebugLog_DC01_PacketStatistic.csv	Plik CSV ze statystyką dla typu “Packet” i podsumowaniem wszystkich klientów na dzień

Jak już wspomniano w poprzednich sekcjach, pliki CSV mogą być używane do dalszej analizy w Excelu, PowerBI lub cokolwiek innego. Celem produkcji wielu plików jest stawienie czoła wyzwaniom big data w większych środowiskach.

W zależności od twojego przypadku użycia, prawdopodobnie chcesz tylko mieć statystyki użycia. Dzięki temu podejściu nie musisz przeglądać wszystkich szczegółów w pełnym dzienniku. Może to znacznie zmniejszyć ilość przechowywanych danych, ponieważ już podsumowuje dane i ignoruje wszystkie hałaśliwe szczegóły.
Jeśli chcesz głęboko analizować szczegóły, możesz chcieć użyć pełnego dziennika i zignorować statystyki, ponieważ nie dostarczają wystarczających szczegółów.

Ale czyż nie byłoby miło mieć parametr do określenia, które z plików wyjściowych chcesz mieć?
Przywitaj się z parametrem -OutputType!

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

Dzięki temu możesz określić, czy chcesz mieć tylko dziennik, tylko statystyki, czy oba. To daje ci większą elastyczność i potencjalnie oszczędza dużo miejsca na dysku.

Przeglądając wygenerowane pliki CSV, możesz zauważyć, że jest pusta kolumna o nazwie “ComputerName” w plikach CSV.

Dzieje się tak, ponieważ dziennik debugowania DNS nie zawiera nazwy serwera. 🤷‍♂️

Możesz ożywić tę kolumnę, przekazując nazwę serwera do parametru -ComputerName w poleceniu.

# Ręcznie określ nazwę komputera
Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -ComputerName "DC01"

Czy pamiętasz moją radę w sekcji Skonfiguruj plik DebugLogFile o umieszczaniu nazwy serwera w nazwie pliku dziennika? Praktykując, możesz wprowadzić nazwę serwera do pliku CSV w locie, dzieląc nazwę pliku.

# Automatycznie wyodrębnij nazwę komputera z nazwy pliku
$files = Get-ChildItem c:\logs\*.log

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

Jest to szczególnie pomocne, jeśli masz wiele serwerów i chcesz mieć nazwę serwera w pliku CSV dla lepszej identyfikacji i analizy.

Inną rzeczą, o którą prawdopodobnie chcesz zadbać, jest format daty w wygenerowanym pliku CSV. Domyślnie używany jest format z podstawowego pliku dziennika.
Może to prowadzić do problemów, gdy masz międzynarodowe środowisko z zlokalizowanymi serwerami. Prawdopodobnie format daty może się różnić w zależności od serwera. To stworzy wyzwania, gdy chcesz przeprowadzić analizę daty w narzędziach takich jak Excel czy PowerBI, ponieważ mogą one nie rozpoznać formatu daty poprawnie. Aby temu sprostać, możesz skorzystać z innego parametru w poleceniu… witaj parametr -OutputCulture.

Moim osobistym preferowanym formatem daty jest format ISO, więc zazwyczaj ustawiam szwedzką kulturę wyjściową ("sv-SE"), ponieważ używa ona formatu ISO dla daty i czasu. Dzięki temu mogę zapewnić, że format daty w wygenerowanym pliku CSV jest spójny, sortowalny i łatwy do rozpoznania, niezależnie od ustawień lokalnych.

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

Na marginesie, istnieje również parametr -InputCulture, jeśli jesteś świadomy używanego formatu na serwerze źródłowym. Ten parametr działa tak samo jak parametr -OutputCulture, ale jest używany do określenia kultury do parsowania daty z pliku dziennika źródłowego.

Na koniec, dwa praktyczne wskazówki do użytku produkcyjnego:
Po konwersji oryginalnego pliku dziennika na CSV, możesz chcieć go usunąć, aby zaoszczędzić miejsce na dysku. Plik CSV powinien zawierać wszystkie informacje w bardziej użytecznym formacie. Dzięki parametrowi -RemoveSourceFile możesz to zrobić bez dodatkowego wysiłku.
A ponieważ pliki dziennika są zwykłym tekstem i mogą być dość duże, możesz chcieć je skompresować po konwersji. Dzięki parametrowi -CompressOutput możesz to zrobić również w locie.

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

Łącząc wszystko powyższe, możesz mieć dość potężne i elastyczne narzędzie do pozyskiwania danych do dalszej analizy z dzienników debugowania DNS, jednocześnie dbając o storage space and file management. Jako ostatni przykład, chcę przedstawić bardziej kompletny przykład, który możesz wykorzystać w środowisku produkcyjnym:

# get the fully written (rolled over) log files from the log folder
$files = Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Sort-Object lastwritetime, Name -Descending | Select-Object -Skip 1

# Passing the files into conversion with all the practical parameters for a production use
foreach($file in $files) {
    $file | Convert-DNSDebugLogFile -ComputerName $file.BaseName.split("_")[1] -Delimiter ';' -OutputType 'Both' -ContextFilter Packet -OutputCulture sv-SE -CompressOutput -RemoveSourceFile
}

Ten przykład, szczególnie z filtrowaniem w procesie wyboru plików, jest przeznaczony do uruchomienia bezpośrednio na serwerach DNS. Ale równie dobrze można go uruchomić na dedykowanej maszynie, aby zaoszczędzić zasoby na serwerach DNS. Jeśli działa na dedykowanej maszynie, nie musisz używać Select-Object -Skip 1 w procesie wyboru plików.

W każdym przypadku musisz zadbać o zbieranie plików, niezależnie od tego, czy są to ostatecznie przetworzone pliki, czy oryginalne pliki dziennika. W pokazanym przykładzie zaletą jest to, że będziesz transportować tylko już skompresowane pliki ZIP. To może być dobrym podejściem do oszczędzania przepustowości sieci, szczególnie jeśli masz szeroko rozproszone serwery z dużą ilością danych dziennika.

Tworzenie raportów

Po skonfigurowaniu i zebraniu danych, prawdopodobnie chcesz je wykorzystać do tworzenia cennych spostrzeżeń i raportów. W zależności od twojego przypadku użycia, dostępne są różne narzędzia, aby to zrobić. Przyjrzyjmy się niektórym z opcji.

Jestem w pełni świadomy, że istnieje wiele innych narzędzi i podejść, więc traktuj poniższe sekcje jako podstawowe przykłady, aby uzyskać wgląd w możliwości.

PowerShell - szybki strzał

Jak już wspomniano w sekcji Konsumpcja danych - EventLogs, możesz przeprowadzić szybką analizę bezpośrednio w PowerShell, importując dane. Może to być przydatne w szybkich sesjach rozwiązywania problemów, gdzie chcesz szybko uzyskać podstawowe informacje. Oczywiście, nie jest to rozwiązanie pierwszej klasy do złożonej analizy lub długoterminowego raportowania, ale jest to możliwe.

Nie będę wchodził w szczegóły, ponieważ już omówiliśmy podstawowe opcje grupowania i filtrowania w sekcji Konsumpcja danych - EventLogs. Jako kolejny przykład, to samo podejście z Group-Object można zastosować na plikach CSV z DebugLogFile:

# Import the data from the generated CSV file
$dataRecords = Get-ChildItem C:\Administration\Logs\DNSServer\*_PacketStatistic.csv -File -Recurse | Import-Csv -Delimiter ";" -Encoding utf8

# Summarize how many DNS queries were made
$dataRecords | Measure-Object Count -Sum

# What servers are in the data
$dataRecords | Group-Object ComputerName -NoElement

# What kind of DNS queries were collected
$dataRecords | Group-Object QuestionType -NoElement

# What DNS clients IPs are in contact with the server(s)
$dataRecords | Group-Object ClientIP -NoElement

# What DNS clients are talking to which server distinctly
$dataRecords | Group-Object { "$($_.ClientIP) --> $($_.ComputerName)" } | Format-Table Name -AutoSize

Szczególnie ostatni przykład na grupowaniu według ClientIP może być bardzo przydatny do budowania tabeli korelacji dla IP i odpowiedniej nazwy systemu. Oczywiście wymaga to odpowiedniej infrastruktury DNS z wszystkimi zarejestrowanymi urządzeniami. Oto jak możesz to zrobić za pomocą PowerShell:

# Get the list of unique client IPs from the data records
$clientIPList = $dataRecords | Group-Object ClientIP -NoElement | Select-Object -ExpandProperty Name

# Resolve the client IPs to hostnames and create a mapping table
$clientMapping = foreach ($clientIP in $clientIPList) {
    if ($clientIP -in ("127.0.0.1", "0.0.0.0", "::1", ".")) {
        [pscustomobject]@{
            ClientIP = $clientIP
            Name     = "Localhost na serwerze 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     = "<nazwa nie do rozwiązania przez DNS>"
            }
        }
    }
}

# Output the client mapping table
$clientMapping | Format-Table -AutoSize

# Export the client mapping to a CSV file for further use
$clientMapping | Export-Csv -Path "ClientIP_Mapping.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Taka mapa klientów może być przydatna i pomocna. Wyniki mogą wyglądać tak:

Excel - klasyczna i elastyczna opcja

Użycie Excela to prawdopodobnie najczęstsze podejście do szybkiej i elastycznej analizy opartej na CSV. I nie ma w tym nic złego, ponieważ Excel oferuje wiele opcji filtrowania, grupowania i wizualizacji danych, aby uzyskać cenne informacje. Jest również dość przyjazny dla użytkownika i większość ludzi jest z nim w pewnym stopniu zaznajomiona. Jedynym minusem jest to, że może nie skalować się zbyt dobrze w przypadku bardzo dużych zbiorów danych.

Do szybkiej analizy na temat “Kto korzysta z moich serwerów DNS do jakiego rodzaju zapytań?”, Excel jest całkowicie w porządku. Po prostu umieść wygenerowane pliki CSV PacketStatistic w folderze i powiedz Excelowi, aby zaimportował folder za pomocą zakładki danych.

Wybierając folder, Excel automatycznie zaimportuje wszystkie pliki CSV w nim i połączy je w jedną tabelę. Ponieważ pliki packetstatistic nie są zbyt duże, powinno to działać całkiem dobrze nawet w średniej wielkości środowiskach z kilkoma serwerami.
Po zaimportowaniu danych możesz wykorzystać funkcje Excela do analizy i wizualizacji danych według własnego uznania. Przy nieco większym zaangażowaniu w logikę importu danych w PowerQuery, lub użyciu dodatkowych kolumn formuł później, możesz skorelować adresy IP klientów z plików CSV z plikiem ClientIP_Mapping.csv z powyższego przykładu, aby uzyskać nazwy klientów w tej samej tabeli.
Korzystając z funkcji “Tabela przestawna” w połączeniu z diagramami przestawnymi, wizualizacja danych jest dość łatwa i oferuje wiele opcji do analizy. Może to być przegląd, jak pokazano powyżej, lub wykresy czasowe.

Nie zapominaj o tabelach danych wielowymiarowych, takich jak ta, która pokazuje rozkład typów zapytań wśród różnych klientów DNS.

To wszystko powinno być tylko przykładem… i chcę wyraźnie podkreślić, że może to nie odpowiadać twoim potrzebom ani projektowi twojej firmy lub klienta. Traktuj to jako inspirację do stworzenia własnych rozwiązań. Jeśli chcesz przyjrzeć się formułom i logice przestawnej, które użyłem do zbudowania pokazanych przykładów, oto [plik Excel z danymi i przykładami][dnsStatisticsFile].

PowerBI - nowoczesny, potężny wybór

Kiedy mówimy o “wielkich danych” w “dużych środowiskach korporacyjnych”, PowerBI jest silnym konkurentem. Excel może osiągnąć swoje limity, ponieważ nie jest zaprojektowany do obsługi bardzo dużych zbiorów danych. Kiedy masz kilkaset serwerów, liczba plików, a nawet rekordów w plikach szybko może osiągnąć liczby sięgające tysięcy, milionów, a nawet miliardów.

To właśnie tutaj PowerBI pokazuje swoje możliwości, ponieważ jest zapewnia do obsługi dużych zbiorów danych, oferuje potężną analizę i wizualizację, z możliwością automatycznego odświeżania w regularnych odstępach czasu i być konsumowanym przez wielu użytkowników bez potrzeby znajomości obsługi danych.

Logika importu w PowerBI jest taka sama jak w imporcie danych Excela, [PowerQuery][powerQueryDocLink]. W związku z tym oznacza to, że logika importu w PowerBI i Excel jest mniej więcej taka sama. Różnica zaczyna się w sposobie, w jaki PowerBI obsługuje dane po imporcie oraz jak oferuje opcje wizualizacji i udostępniania.
Jestem pewien, że eksperci PowerBI i Fabric mogą chcieć mnie ukarać za porównywanie PowerBI do Excela, ale dla podstawowego zrozumienia, pozostawmy to w ten sposób. Nie będę wchodził w szczegóły dotyczące specyficznych funkcji PowerBI, ponieważ wykraczałoby to poza zakres tego artykułu, ale chcę przynajmniej dać ci kilka pomysłów na to, jak to może wyglądać.

To samo, co wspomniano w poprzedniej sekcji dla przykładów Excela… Wszystko to jest tylko przykładem i może nie odpowiadać twoim potrzebom. Nie włożyłem wiele wysiłku w projektowanie raportów PowerBI, ponieważ chcę tylko dać kilka przykładów dla podstawowego zrozumienia. W zależności od rozmiaru twojego środowiska i ilości danych, twoje raportowanie może wyglądać zupełnie inaczej.

Głównym punktem jest to, że z PowerBI masz moc do tworzenia własnych raportów i pulpitów, które mogą być automatycznie odświeżane.on a regular basis and are easily accessible by multiple users without knowing how to deal with the underlying data.

W przypadku, gdy nadal chcesz spojrzeć na plik PowerBI z przykładami, oto [plik PowerBI z danymi i przykładami][pbiStatisticsFile].

Wnioski

Mając to wszystko, jesteś teraz dobrze przygotowany, aby zagłębić się w świat logowania debugowania serwera DNS.

Masz wiedzę, aby włączyć i skonfigurować logowanie debugowania, a także przetwarzać i analizować wygenerowane dane. Niezależnie od tego, czy zdecydujesz się na szybką analizę w PowerShell, czy na tworzenie szczegółowych raportów w Excelu lub PowerBI, wybór należy do Ciebie. Pamiętaj tylko, że z wielką mocą wiąże się wielka odpowiedzialność, więc miej na uwadze ilość danych, które zbierasz, oraz sposób ich wykorzystania.

🚀 Szczęśliwego logowania i analizowania! 🚀

Powiązane linki

[Microsoft Docs: Logowanie debugowania w serwerze DNS][msDebugLoggingInDnsServer] - Oficjalna dokumentacja dotycząca włączania i korzystania z logowania debugowania w serwerze DNS.
[PowerShell Gallery: DNSServer.DebugLogParser][dNSServerDebugLogParserDef] - Moduł PowerShell do analizy plików dziennika debugowania serwera DNS.
[GitHub Repository: DNSServer.DebugLogParser][dnssLogParserRepository] - Repozytorium GitHub dla modułu DNSServer.DebugLogParser, w tym dokumentacja i przykładowe skrypty.
[Dokumentacja PowerQuery][powerQueryDocLink] - Oficjalna dokumentacja dla PowerQuery, potężnego narzędzia do transformacji i analizy danych, które można wykorzystać z Excelem i PowerBI.
[Dokumentacja PowerBI][powerBIDocLink] - Oficjalna dokumentacja dla PowerBI, potężnego narzędzia analitycznego, które można wykorzystać do tworzenia interaktywnych raportów i pulpitów nawigacyjnych.

Inne linki

Memes z [makeameme.org][makeAMemeLink]

Andi Bellstedt