DNSログで不審なドメイン通信を見つけた時に、問い合わせ元、時刻、応答、NXDOMAIN、Proxy/EDRログとの突合、報告記録までを整理。情シス・SOC・開発者が初動判断に使える確認方法をチェックリスト形式で解説します。
冒頭要約
DNSログは、端末やサーバーが「どのドメイン名を解決しようとしたか」を見るための重要な証跡です。不審なドメイン通信、マルウェア感染疑い、フィッシング後の端末確認、SaaS連携の異常調査で最初の手掛かりになります。
ただし、DNSログだけで「侵害された」「マルウェアが実行された」と断定するのは危険です。名前解決の試行と実際の接続、認証成功、ファイルアクセス、データ送信は別のログで突き合わせる必要があります。
まずやるべきことは、不審ドメインを開くことではありません。時刻、問い合わせ元、応答、ブロック状況、関連するプロキシ・EDR・SIEMログを揃え、事実と推測を分けて記録することです。
この記事は防御・確認・初動判断のためのDNSログの読み方に限定します。攻撃再現、悪用コード、探索クエリ、回避方法、実在する不審ドメインへのアクセス手順は扱いません。ログの閲覧・保全は、自社の権限、個人情報、インシデント対応規程に従ってください。
読者別の影響
DNSログは、ネットワーク担当者だけのものではありません。メール、SaaS、開発端末、サーバー、クラウド環境の確認にもつながるため、立場ごとに見るべき目的を分けると初動が速くなります。
| 読者 | 影響 | まずやること |
|---|---|---|
| 個人・一般社員 | フィッシングリンクを開いたかもしれない時に、端末が外部へ問い合わせた可能性がある | 自分で不審URLを再度開かず、受信時刻、クリック有無、端末名を情シスへ伝える |
| 情シス・ヘルプデスク | 端末、利用者、問い合わせ先、ブロック状況を切り分ける必要がある | DNSログとプロキシ/EDRログを同じ時間帯で確認する |
| 開発者 | 依存パッケージ、CI、開発ツールが外部APIや未知ドメインへ通信することがある | 正規の連携先台帳、CIログ、secret scanning通知と突き合わせる |
| SaaS管理者 | SaaS通知、OAuth連携、外部共有後に未知ドメインへの通信が続く場合がある | IdP、SaaS監査ログ、条件付きアクセス、端末ログを同じタイムラインに並べる |
| SOC・CSIRT | 影響範囲、封じ込め、報告、再発防止の判断が必要になる | IOCとして扱う前に、信頼度、観測範囲、関連アラートを記録する |
DNSログとは何を示すか
DNSログは、一般に「問い合わせ元が、いつ、どの名前を、どのレコードタイプで問い合わせ、どの応答を受けたか」を記録します。RFC 1034/1035はDNSの基本構造とリソースレコードを定義し、RFC 9499はDNS関連用語を現行の用語集として整理しています。
実務で重要なのは、DNSログが「通信の意図または準備」を示すことです。実際にHTTP接続が成功したか、認証情報が送られたか、ファイルが外へ出たかは、DNSログだけでは分かりません。プロキシ、ファイアウォール、EDR、SaaS監査ログ、端末ログを合わせて判断します。
| ログの項目 | 何を見るか | 初動での意味 |
|---|---|---|
| 時刻 | タイムゾーン、秒単位、ログ遅延 | 他ログとの前後関係を確認する |
| 問い合わせ元 | 端末IP、ホスト名、ユーザー、ネットワーク | 影響端末と利用者を絞る |
| FQDN | 問い合わせた完全修飾ドメイン名 | 既知の業務先か、初見か、類似ドメインかを見る |
| レコードタイプ | A、AAAA、CNAME、MX、TXTなど | Web閲覧、メール、検証、CDN利用などの文脈を推測する |
| 応答コード | NOERROR、NXDOMAIN、SERVFAILなど | 解決成功、存在しない名前、障害やブロックの可能性を切り分ける |
| 応答先 | IP、CNAME、ブロックページ、シンクホール | 実接続の有無を別ログで追う入口にする |
| 取得経路 | 社内DNS、Secure DNS、VPN、クラウドDNS | ログが全端末を網羅しているか確認する |
1回だけの名前解決より、同じ端末からの繰り返し、複数端末への広がり、ブロック後の別経路通信、認証ログやEDRアラートとの連動が重要です。
まず確認すること
不審なDNSログを見つけたら、最初に「危険なドメインかどうか」を検索し続けるのではなく、社内で説明可能な事実を揃えます。以下のチェックリストをそのままチケットや初動メモへ転記できます。
| 確認項目 | チェック | 記録例 |
|---|---|---|
| 1. 検知元 | どのDNS基盤、EDR、SIEM、Protective DNS、プロキシで見つかったか | 社内DNS, EDR Network, Secure Web Gateway |
| 2. 時刻 | JST/UTC、開始・終了、繰り返しの間隔を揃えたか | 2026-07-05 09:14 JST - 09:18 JST |
| 3. 問い合わせ元 | 端末名、IP、ユーザー、部署、管理状態を確認したか | device-023, [email protected], 管理端末 |
| 4. ドメイン | FQDN、親ドメイン、類似ドメイン、正規業務先との関係を確認したか | example.invalid のような記録用表記で管理 |
| 5. 応答 | NOERROR、NXDOMAIN、ブロック、シンクホール、応答IPを確認したか | NXDOMAIN, blocked, 10.x.x.x |
| 6. 接続成否 | プロキシ、FW、EDRで実通信が成功したか確認したか | HTTP接続なし, プロキシでblocked |
| 7. 直前のきっかけ | メールクリック、添付開封、SaaS通知、CI実行、ブラウザ拡張更新があったか | 09:12に不審メールを報告 |
| 8. 横展開 | 同じドメインを他端末・サーバー・CIが問い合わせていないか | 同一部署3台, CI runner 1台 |
| 9. 例外・正規理由 | 既知のSaaS、CDN、セキュリティ製品、監視ツールの通信ではないか | 承認済みSaaS台帳に記載なし |
| 10. 次アクション | 隔離、本人確認、パスワード変更、追加ログ保全、CSIRT連絡の要否を決めたか | SOCへエスカレーション |
この表で大切なのは、証跡の粒度をそろえることです。「怪しいドメインが出た」ではなく、「どの端末が、いつ、どのログで、どの応答を受け、実接続があったか未確認/確認済み」と書ける状態にします。
初動対応
やること
- 不審ドメインやURLをブラウザで開かず、DNSログ、プロキシログ、EDRログ、メール原本、SaaS監査ログから確認する。
- 対象端末、ユーザー、IP、時刻、ドメイン、応答、ブロック状況を1つのタイムラインにまとめる。
- 同じドメインを問い合わせた他端末、同じ端末が問い合わせた他ドメイン、同じ時刻帯の認証成功ログを確認する。
- 端末で不審なプロセス、ブラウザ拡張、ダウンロード、メールクリック、SaaS権限変更がないか、権限のあるログで確認する。
- 調査対象の範囲、確認したログ、保持期限、取得できなかったログを記録する。
やらないこと
- 不審ドメインを手元のブラウザ、スマートフォン、業務端末から直接開いて確認しない。
- 実在する第三者のドメインに対して探索的なアクセス、スキャン、検証リクエストを送らない。
- DNSログだけで「感染」「侵害」「無害」と断定しない。
- チケットやチャットへCookie、APIキー、セッショントークン、メール原本の機密情報をそのまま貼らない。
- ログ保全前に端末初期化、アプリ削除、セキュリティ製品の設定変更を急がない。
記録すべきこと
| 記録項目 | 書き方 |
|---|---|
| 観測事実 | device-023 が 09:14 JST に example.invalid を問い合わせ、社内DNSでNXDOMAIN |
| 根拠ログ | DNS Resolver Log, Proxy Log, EDR Network Event, IdP Sign-in Log |
| 未確認事項 | 実HTTP接続の有無はプロキシログで確認中 |
| 実施した対応 | ユーザーへクリック有無を確認, 端末のEDR詳細調査を依頼 |
| 判断者 | 一次確認: 情シス, エスカレーション先: CSIRT |
判断基準とエスカレーション条件
DNSログはノイズも多いため、危険度を「ドメイン単体の評判」だけで決めないことが重要です。以下のように、観測範囲、直前のイベント、接続成否、権限、業務影響で優先度を分けます。
| 優先度 | 条件 | 対応 |
|---|---|---|
| 高 | 複数端末で同じ未知ドメインへ繰り返し問い合わせ、プロキシ/EDRで実通信や認証成功も確認された | CSIRT/SOCへ即時連絡し、端末隔離、ログ保全、影響範囲確認を進める |
| 高 | フィッシングクリック直後、認証成功、MFA変更、SaaS外部共有、管理者操作が続いた | アカウント保護、セッション失効、SaaS監査ログ確認を優先する |
| 中 | 1台の端末で未知ドメインへの問い合わせがあり、ブロック済みだが繰り返しがある | 端末利用者確認、ブラウザ/メール/EDRイベント確認、再発監視を行う |
| 中 | NXDOMAINが短時間に多数出ており、通常業務やアプリ更新では説明しにくい | 端末・プロセス・ユーザー操作の文脈を確認し、必要に応じてEDR調査へ進む |
| 低 | 既知SaaS、CDN、セキュリティ製品、業務アプリの正規通信として説明できる | 台帳へ記録し、必要なら許可ルールや監視除外の根拠を残す |
Protective DNSやプロキシでブロックされた場合でも、端末がなぜそのドメインを問い合わせたかは別問題です。直前にメールクリック、添付開封、拡張機能更新、認証成功、別経路通信がないかを確認します。
よくある誤解
DNSログがあるなら感染している
DNSログは名前解決の記録です。ブラウザのプリフェッチ、メール本文のプレビュー、セキュリティ製品の検査、正規SaaSのCDN利用でもDNS問い合わせは発生します。感染や侵害の判断には、EDR、プロセス、プロキシ、認証、SaaS監査ログが必要です。
NXDOMAINが多いなら必ず攻撃である
NXDOMAINは「その名前が存在しない」という応答です。タイプミス、壊れた設定、アプリのリトライ、古いリンクでも発生します。ただし、短時間に大量、ランダムに見える名前、複数端末への広がり、EDRアラートとの連動がある場合は優先度を上げます。
ブロックされたから調査しなくてよい
ブロックは被害を減らす有効な防御ですが、原因調査の終了ではありません。DNSが止めた後に、別ドメイン、直接IP、VPN外、モバイル回線、別端末から通信が続いていないか確認します。
不審ドメインは開いて見れば早い
実務では、直接アクセスして確認する必要は通常ありません。アクセスによって追加のリスクやログ汚染が発生する可能性があります。組織で承認された隔離分析環境や脅威インテリジェンス基盤がない場合は、自社ログと公式・信頼できる情報源だけで初動判断します。
Secure DNSやDoHを使えばログ問題は解決する
暗号化DNSは通信のプライバシーや改ざん耐性に関係しますが、組織の検知・監査・調査には別の設計が必要です。どこで名前解決を集約し、どのログを保持し、どの端末が例外経路を使えるかを明確にします。
関連用語・関連ページ
| 目的 | 内部リンク |
|---|---|
| 用語を確認する | DNSとは、IOCとは、SIEMとは、SOCとは、プロキシとは |
| ログ全体の読み方を学ぶ | セキュリティログの読み方、SIEMとログ管理、ログ分析の基礎 |
| 実務で使う | フィッシング確認チェックリスト、インターネット公開管理画面の緊急点検チェックリスト、漏えい疑い初動テンプレート |
| 演習で確認する | アクセスログ解析ミニCTF、ログイン失敗ログの読み取りミニCTF、用語クイズ |
| 仕組みを比較する | SIEMとSOARの違い、VPNとプロキシの違い |
まとめ
DNSログの読み方で最初に必要なのは、難しい検索式ではありません。時刻、問い合わせ元、ドメイン、応答、実接続、関連イベントを同じ表に並べ、DNSログだけで断定しないことです。
不審なドメイン通信を見つけたら、まずログを保全し、プロキシ、EDR、IdP、SaaS監査ログと突き合わせます。クリック、認証成功、権限変更、データアクセス、複数端末への広がりがあれば、CSIRT/SOCへ早めに渡します。
次に学ぶなら、ログ全体の入口として セキュリティログの読み方 を確認し、手を動かす練習として アクセスログ解析ミニCTF へ進むと、DNSログを実務判断につなげやすくなります。
公式情報・参考情報
- RFC 9499: DNS Terminology - DNS用語の現行整理。
- RFC 1034: Domain names - concepts and facilities - DNSの基本概念と構造。
- RFC 1035: Domain names - implementation and specification - DNSメッセージとリソースレコードの基礎仕様。
- NIST SP 800-92: Guide to Computer Security Log Management - ログ管理の計画、保持、分析、運用プロセス。
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management - インシデント対応をリスク管理へ組み込むための現行ガイド。
- NSA and CISA: Selecting a Protective DNS Service - Protective DNSの役割、ログ、ブロック後の調査観点。
- CISA Alert: Controlling Outbound DNS Access - 外向きDNS通信の制御と確認観点。
