最初に押さえる判断の軸
DNSの記録は、端末やサービスがどの名前を解決しようとしたかを知る材料になります。普段と違う宛先、繰り返す失敗などを調べる時に役立ちますが、名前を解決した事実だけでは、接続や情報の送信が成功したとは分かりません。端末、認証、ネットワークの記録と時刻を照合します。
暗号化されたDNSやキャッシュ、外部のリゾルバーの利用などにより、中央の記録だけでは見えない経路がある場合があります。監視の対象と取得範囲を明確にします。長いドメイン名や新しい宛先が全て悪意とは限らないため、正規サービスの活動と根拠を比較し、無条件の拒否による業務影響も確認します。

混同しやすい状態を比較する
DNSSECによる応答の検証、DNS通信の暗号化、悪意ある宛先の判定は目的が違います。どれか一つで全ての安全を保証するものではありません。
DNSの記録
どの名前を解決しようとしたか。
成功を推定せず通信と端末
接続したか、どの主体が何をしたか。
根拠を関連付ける判断
正規サービスと変更、取得範囲を照合。
名前を解決したことだけで、接続や漏えいを断定しない。
当サイト独自の説明図。領域の面積や並びは、被害件数・発生確率・出題比率を表していません。
| 確認する対象 | 見落としやすい点 | 判断に使う根拠 |
|---|---|---|
| 名前解決 | 解決で接続成功と判断 | 後続通信と端末記録 |
| 取得範囲 | 中央ログで全端末を把握 | リゾルバーと暗号化経路 |
| 異常 | 珍しい名前は全て悪意 | 正規サービスと利用の根拠 |
確認問題
独自ケースで判断を練習する
新しい長い名前へのDNS要求が見つかりました。導入した監視サービスの正常な通信か、端末の不審活動かは未確認です。
次のうち、ケースの情報から優先する対応はどれでしょうか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解:1。名前の見た目は調査の材料ですが確定の根拠ではありません。導入や変更の記録、端末、後続の通信を照合します。取得していない経路があれば未確認として残します。異常の分類と、必要な制限の判断を分けることで、正規業務を止める誤対応を減らせます。
POINT
当サイト独自の確認問題です。実際の事件・公式問題・過去問を再現していません。
確認と見直しを業務へつなげる
利用するリゾルバーと記録の保持、端末との識別を確認します。検知ルールは正規の新サービスや変更を含めて見直してください。
- 1
経路
名前解決の経路と取得範囲を確認する
- 2
時刻
対象と時刻を他の記録へ対応させる
- 3
照合
正規活動と後続通信を比較する
- 4
見直し
制限の影響と監視を見直す
実施したことと、結果を確認できたことを区別する。
実操作が必要な項目は管理者の承認と組織の手順に従ってください。
要求、応答、接続、操作を別の事実として記録します。ログの欠落を通信がなかった証拠にしないようにします。
実務で見落としやすい条件を掘り下げる
複数の端末が同じリゾルバーを使う場合、ログに見える接続元が端末そのものとは限りません。端末へ対応させる記録を用意し、名前だけで利用者を推定しないようにします。調査の時刻とタイムゾーンも合わせて、異なる活動を混ぜないことが重要です。
遮断した宛先で業務に影響が出た場合は、正規の利用と不審な活動を確認します。全体の拒否を解除する前に必要な対象を絞ります。監視の改善では新しい正常なサービスと、取得できない経路を別々に管理します。
次に読む記事と、理解の確認
サイバーセキュリティの学習ガイドで、このテーマを検知・事故対応とIoTの中に位置付けてください。関連する前提はDNSの仕組みとは、脅威ハンティングの始め方で確認できます。
資格対策との接点は情報・サイバーセキュリティ管理士の概要へ。用語を理解した後は登録不要の無料お試し20問で、別の状況でも判断できるか確かめてください。記事のテーマを全て公式の出題項目とする説明ではありません。