Windows Server DNSのログは目的別に使い分けます。まず既定で有効なDNS Serverの管理・監査イベントを確認し、ゾーン変更や動的更新を追います。個々の問い合わせ名、種類、応答コードまで必要な短時間の障害調査ではAnalyticalログを有効にします。従来のDebug loggingは詳細ですが、ディスクI/Oと個人・社内情報の記録量が大きいため、対象、時間、保存容量を限定してください。
「すべてのパケットを常時記録」は3分で終わる安全な設定ではありません。目的、開始・終了、保存先、最大サイズ、閲覧者、削除日を決めてから詳細ログを有効化します。
最初に見るイベントログ
イベントビューアーでApplications and Services Logs → Microsoft → Windows → DNS-Serverを開きます。管理・監査イベントにはDNSサービス開始/停止、ゾーン・レコード変更、DNSSEC等の運用情報が含まれます。Systemログと合わせ、サービス障害、ネットワーク、ディスク、時刻の異常を同じ時刻で確認します。
監査ログは構成変更を追う用途であり、全クライアントの全問い合わせを常に示すとは限りません。利用者が「名前解決できない」と報告したときは、サーバーイベントだけでなくクライアント側の問い合わせ先、応答、キャッシュ、到達性を同時に採取します。
Analyticalログを表示して有効化する
- イベントビューアーのViewでShow Analytic and Debug Logsを選びます。
- DNS-Server配下に表示されたAnalyticalを右クリックし、Propertiesを開きます。
- 保存方式と最大サイズを決め、Enable loggingを選びます。
- 検証クエリを数回実行し、記録時刻、QNAME、QTYPE、RCODE、応答時間を確認します。
- 問題を再現したらログを無効化してEVTX/ETLを保全し、元の設定へ戻します。
Analyticalログは既定で無効です。高いQPSのサーバーでは性能へ影響する可能性があるため、開始前後のCPU、ディスク、DNS QPS、応答遅延、ドロップを監視します。Microsoftは高負荷環境の例を示していますが、自環境の実測で判断します。
DoHを提供するDNS Serverでは分析イベントに暗号化DNSの問い合わせ、応答、失敗、拒否を示すイベントが含まれます。通常DNSとDoHを分け、証明書、HTTPSリスナー、HTTPステータス、DNS RCODEを混同しません。
PowerShellで現在値を確認する
DNS Serverモジュールの診断設定を読み取り、変更前の値を保存します。版によって利用できるパラメーターが異なるため、`Get-Command`と公式資料を確認します。`Set-DnsServerDiagnostics -All $true`のような全項目有効化を本番で既定例にしません。
Get-DnsServerDiagnostics | Format-List *
Get-WinEvent -ListLog 'Microsoft-Windows-DNSServer/*' | Select-Object LogName,IsEnabled,MaximumSizeInBytesログ有効化をスクリプト化する場合は、対象サーバー、変更前値、最大サイズ、保持、開始・終了時刻を明示します。複数DNSへ同時に展開せず一台で負荷を測ります。コマンド出力には内部ゾーンやサーバー名が含まれるため、安全な保管先を使います。
Debug loggingを使う判断
DNS ManagerのサーバープロパティにあるDebug Loggingは、パケット方向、UDP/TCP、要求/応答、種類、送信元などを選べます。Analyticalイベントで足りないサポート調査だけに限定し、必要なカテゴリへ絞ります。ログファイルをOSボリュームの無制限パスへ置きません。
パケット内容にはクライアントIP、問い合わせ名、内部構成、場合によっては利用者行動を推測できる情報が含まれます。情報セキュリティとプライバシー規程に従い、閲覧権限、暗号化、外部サポートへ渡す際のマスキングを実施します。
容量と保持の設計
最大ログサイズ、上書き方式、保存先の空き容量を決め、80%等の閾値で監視します。「Do not overwrite」を選ぶと満杯後に新しいイベントが記録されないため、アーカイブ運用が必要です。Circular loggingは古い証跡を失うので、調査要件とのトレードオフを明記します。
分析・デバッグログは有効中の表示やエクスポート方式に制約があります。Microsoftのトラブルシューティングが示すとおり、上書き方式によっては一度無効化してから閲覧・エクスポートします。ログが空だからイベントがないと即断しません。
障害再現の取り方
- 問題端末、ユーザー、時刻、接続ネットワーク
- 問い合わせた完全修飾名とレコード種類
- クライアントが実際に使ったDNSサーバー
- 各DNSの応答コード、応答時間、権威/再帰の別
- フォワーダー、条件付きフォワーダー、ルートヒントの経路
- 同時刻のDNS・System・ネットワーク・ファイアウォールログ
既知のテスト名と対象DNSを指定して問い合わせ、成功・失敗を比較します。キャッシュ済み応答だけで上流到達を確認したことにせず、必要ならテスト専用レコードやTTLを使います。本番キャッシュを全消去すると広範な負荷が出るため、影響を評価します。
終了と復元
再現後はAnalytical/Debug loggingを無効にし、変更前の診断値、保存方式、最大サイズへ戻します。ログファイルを別の保護領域へコピーし、ハッシュと採取時刻を記録します。調査用に作ったテストレコードや一時フォワーダーも撤去します。
恒久監視には、全問い合わせの生ログではなく、SERVFAIL率、NXDOMAIN率、応答遅延、QPS、サービス状態、ゾーン転送失敗等の指標を使います。詳細ログはアラート後に期限付きで取得し、平常時の性能とプライバシーを守ります。
ログを集中収集する
複数DNSサーバーではWindows Event ForwardingやSIEMへ監査イベントと主要エラーを集約し、サーバー停止時にも証跡が残るようにします。収集アカウントにはログ読み取りだけを与え、DNS管理権限を兼ねさせません。ログ転送停止自体をアラートし、すべてのDNSが同じ時刻源を使うことを確認します。
生の問い合わせログをSIEMへ常時送る場合、イベント量、ライセンス費用、検索性能、個人情報、保持期限を事前に見積もります。重要ゾーン、SERVFAIL、異常なNXDOMAIN、既知の悪性ドメインなど目的に沿った検出へ絞り、全クエリを無期限保存しません。
DNS変更監査の使い方
レコードやゾーンが変わった場合は、イベントの操作者、対象ゾーン、旧値/新値、変更元DC、時刻を変更票と照合します。動的更新はDHCPやクライアントが行うため、管理者の手動変更と区別します。予期しない削除を見つけても、ログだけを根拠に一括再作成せず、AD複製と正規データを確認します。
重要レコードの変更をアラートする場合、DNSSEC署名、エージング/スカベンジング、DHCP更新の正常イベントをベースライン化します。誤検知が多いルールを無効化して終わらせず、ゾーン・レコード種類・管理経路で条件を調整します。
調査報告に含める内容
報告書にはログ種別、対象サーバー、タイムゾーン、開始/終了、有効化した診断項目、性能変化、関連イベント、仮説、確定事実を分けて記載します。外部へ共有する際は内部ドメイン、クライアントIP、問い合わせ名、ユーザー対応情報を必要最小限にマスキングし、原本はアクセス制御された証跡領域へ保管します。
コメント