Windows ServerでDNSクエリログとログファイルの解析を有効にする方法は？

この記事では、Windows Serverを実行しているDNSサーバーですべてのユーザークエリに対してDNSログを有効にする方法、DNSログを解析および分析する方法を示します。ブランチオフィスで古いActiveDirectoryドメインコントローラーを廃止する必要があり、どのデバイスがまだDNSサーバーを使用しているかを理解する必要があるときに、このタスクに直面しました。 DNSログを有効にして分析した後、デバイスを見つけて、他のDNSサーバーを使用するように再構成することができました。また、この方法は、Active Directoryネットワークで疑わしいアクティビティ（悪意のあるURL、ボットネットホストなどへのアクセス）があるホストを見つけるのに役立ちます。

もちろん、DNSホストにWireshark、Microsoft Network Monitor、またはpktmonをインストールして、ポート53でトラフィックをキャプチャすることもできますが、WindowsServerで組み込みのDNSクエリログを使用する方が簡単です。

デフォルトでは、DNSログはWindowsServerでは無効になっています。有効にするには：

1. DNSマネージャーを開きます スナップイン（dnsmgmt.msc ）そして必要なDNSサーバーに接続します;
2. プロパティを開き、デバッグログに移動します タブ;
3. デバッグ用のログパケットを有効にします オプション;
4. 次に、ログオプションを構成できます。DNSパケットの方向、プロトコル（UDPおよび/またはTCP）、パケットタイプ（単純なDNSクエリ、更新、または通知）を選択します。
5. IPアドレスでパケットをフィルタリングを使用する オプションで、着信または発信パケットをログに記録するIPアドレスを指定できます（ログサイズを大幅に削減できます）。
   
6. ログファイルのパスと名前 ボックスで、すべてのイベントをログに記録するテキストファイルの名前を指定します。デフォルトでは、DNSログのサイズは500MBに制限されています。到達すると、古いDNSルックアップイベントが新しいもので上書きされます。

また、PowerShellを使用してDNSクエリログを有効にしたり、現在の設定を取得したりできます。

Get-DnsServerDiagnostics

負荷の高いWindowsDNSホストでは、DNSクエリログによってCPU、RAM、およびストレージに余分な負荷がかかる可能性があることに注意してください（ディスクのパフォーマンスは十分である必要があります）。

次に、任意のコンピューターからサーバーに対してDNSクエリを実行します。たとえば、Windows Serverを実行しているDNSホストのIPアドレスが192.168.13.10の場合：

nslookup woshub.com 192.168.13.10

または、PowerShellを使用してDNSアドレスを解決してみてください：

Resolve-DnsName -Name woshub.com -Server 192.168.13.10

DNSルックアップクエリは、要求されたホストのクライアントIPアドレスを返しました。

クエリがDNSサーバーログに表示されていることを確認しましょう。

これを行うには、クライアントIPアドレス（192.168.13.130）でテキストログファイルを検索します。 ）。メモ帳でログファイルを開くか、PowerShellを使用してログファイルをgrepできます。

get-content "C:\Logs\dc01dns.log" | Out-String -Stream | Select-String "192.168.13.130"

イベントの例は次のとおりです。

11/17/2021 6:00:00 AM 0D0C PACKET 00000272D98DD0B0 UDP Rcv 192.168.13.130 0002 Q [0001 D NOERROR] A (8)woshub(2)com(0)

ご覧のとおり、名前を解決するためのDNSクエリ(8)woshub(2)com(0) 受信しました（rcv ）クライアントから192.168.13.130 UDPを介して 、次にDNSサーバーが正常に実行されます（NOERROR ）それに応答しました（snd 。

すべてのフィールドはファイルの先頭に記述されています：

Field # Information Values
------- ----------- ------
1 Date
2 Time
3 Thread ID
4 Context
5 Internal packet identifier
6 UDP/TCP indicator
7 Send/Receive indicator
8 Remote IP
9 Xid (hex)
10 Query/Response R = Response
blank = Query
11 Opcode Q = Standard Query
N = Notify
U = Update
? = Unknown
12 Flags (hex)
13 Flags (char codes) A = Authoritative Answer
T = Truncated Response
D = Recursion Desired
R = Recursion Available
14 ResponseCode
15 Question Type
16 Question Name

特定の形式のため、このようなDNSログファイルを手動で解析および分析することは困難です。したがって、 Get-DNSDebugLog.ps1 を使用して、DNSクエリログをより便利な形式に変換する必要があります。 スクリプト。

このPowerShellスクリプトは私のものではありませんが、現在TechNet Scriptcenterで利用できないため、GitHubリポジトリ（https://github.com/maxbakhub/winposh/blob/main/Get-DNSDebugLog.ps1）に保存しました。

ファイルをディスクにダウンロードします。次に、PowerShellスクリプトを現在のコンソールセッションで実行できるようにします。

Set-ExecutionPolicy -Scope Process Unrestricted

Get-DNSDebugLog.ps1からセッションに関数をインポートします：

. C:\ps\Get-DNSDebugLog.ps1

次に、DNSログをより便利な形式に変換します。

Get-DNSDebugLog -DNSLog C:\Logs\dc01dns.log | format-table

または、結果をCSVファイルにエクスポートしてExcelでさらに分析することもできます（または、PowerShellから直接Excelファイルにアクセスして、必要なDNSクエリを書き込むこともできます）。

Get-DNSDebugLog -DNSLog C:\Logs\dc01dns.log | Export-Csv C:\log\ProperlyFormatedDNSLog.csv –NoTypeInformation

ファイルをExcelにエクスポートし、それを使用してDNSクエリを分析できます（ファイルには、DNSサーバーから要求されたホストIPアドレスとDNS名が含まれています）。

また、 Log Parser 2.2を使用することもできます （https://docs.microsoft.com/en-us/archive/blogs/secadv/parsing-dns-server-log-to-track-active-clients）DNSログファイルを解析および分析します。たとえば、次のコマンドは、各IPアドレスからのDNSクエリの数を表示します。

LogParser.exe -i:TSV -nskiplines:30 -headerRow:off -iSeparator:space -nSep:1 -fixedSep:off -rtp:-1 "SELECT field9 AS IP, REVERSEDNS(IP) AS Name, count(IP) as QueryCount FROM "C:\Logs\dc01dns.log" WHERE field11 = 'Q' GROUP BY IP ORDER BY QueryCount DESC"

この例では、テキストファイルを使用してDNSログを収集しました。 Windows Server 2012以降では、DNSクエリをイベントビューア（Microsoft-Windows-DNS-Server/Audit）に直接記録できます。 ）。しかし、私の意見では、テキストDNSログの分析ははるかに簡単です。

もちろん、DNSクエリを複数のサーバーに記録する場合は、Splunk、ELK、Graylog、Azure Log Analyticsなどのログを収集、保存、処理するための特別なソリューションを使用することをお勧めします。

DNSクエリログを有効にして分析した後、まだDNSサーバーを使用しているデバイスのIPアドレスを見つけて、他のDNSサーバーに再構成しました。古いDCにFSMOの役割が含まれていない場合は、削除できます（ADユーザーのログオンイベントはここでは重要ではありません）。