DNSレコードが意図せず変更された時に、NS/MX/TXT/CNAME、ドメイン管理者、DNSSEC、証明書、メール認証、ログ保全をどう確認するか。ドメイン乗っ取り・なりすまし疑いの初動対応を整理します。
冒頭要約
DNSレコードが意図せず変わると、Webサイトの向き先、メール配送、SaaSのドメイン所有権確認、TLS証明書の発行、フィッシング対策に影響します。単なる「設定ミス」か、レジストラ・DNSホスティング・SaaS管理者アカウントの不正利用かを分けて確認する必要があります。
まずやるべきことは、すぐに画面上の値を戻すことだけではありません。現在値、期待値、変更者、変更時刻、通知メール、監査ログ、DNSSEC/DS、証明書発行履歴を保全し、どの範囲へ影響したかを確認します。
この記事では、攻撃再現や悪用手順ではなく、情シス、Web担当、開発者、SaaS管理者が「DNSレコードが勝手に変わった疑い」を受けた時の初動対応、確認方法、判断基準をチェックリスト形式で整理します。
この記事は2026年7月9日時点で公開されているNIST、CISA、ICANNの公式情報を参考に、防御・確認・初動判断のために整理しています。攻撃手順、PoC、悪用コード、探索クエリ、第三者ドメインへの検証手順は扱いません。自社で管理権限を持つドメインとDNS基盤に限定して確認してください。
読者別の影響
DNSレコード変更は、ネットワーク担当だけで完結しません。Web、メール、SaaS、クラウド、証明書、広報、法務に波及しやすいため、最初から役割別に見る観点を分けると初動が安定します。
| 読者 | 影響 | まず確認すること |
|---|---|---|
| 個人・一般社員 | メールが届かない、ログイン画面やWebサイトの表示が変わる、偽サイトの疑いが生じる | 自分で再アクセスを繰り返さず、発見時刻、表示内容、受信メール、端末名を情シスへ伝える |
| 情シス・Web担当 | ドメイン管理、DNSホスティング、CDN、Web公開、メール配送の確認が必要になる | NS、A/AAAA、CNAME、MX、TXT、CAA、DSの現在値と期待値を並べる |
| 開発者・DevOps | CI/CD、CDN、API、SaaS検証用TXT、ステージング環境の向き先に影響する | 直近のデプロイ、IaC変更、DNS自動化、APIトークン、レビュー済みPRを確認する |
| SaaS管理者 | Microsoft 365、Google Workspace、メール配信、IdP、CRMなどのドメイン所有権確認やメール認証に影響する | SPF/DKIM/DMARC、SaaS検証レコード、管理者操作ログ、連携アプリを確認する |
| CSIRT・SOC | 不正変更、なりすまし、証明書発行、アカウント侵害、顧客影響の判断が必要になる | 変更履歴、監査ログ、通知、証明書、利用者影響、エスカレーション先をタイムライン化する |
DNSレコード変更とは
DNSログの読み取りと、DNSレコードの変更確認は別の作業です。DNSログの読み方は「端末やサーバーが何を名前解決したか」を見るものです。一方でDNSレコード変更は、自社ドメインの権威情報やレジストラ設定が「誰によって、いつ、何に変わったか」を見る作業です。
実務で特に注意するレコードは、Webの向き先だけではありません。NSやDSは権威DNSやDNSSECに関係し、MXやTXTはメール配送・SPF・DKIM・DMARCに関係します。CAAは証明書発行ポリシー、CNAMEはCDNやSaaS連携、TXTはSaaSの所有権確認にも使われます。
| レコード・設定 | 影響しやすい領域 | 初動で見る理由 |
|---|---|---|
| NS | 権威DNS、ゾーン全体 | ゾーン全体の管理先が変わるため、影響が大きい |
| A/AAAA | Webサイト、API、管理画面 | 表示先や接続先が変わる可能性がある |
| CNAME | CDN、SaaS、サブドメイン | 外部サービス連携やサブドメインの所有状態を確認する |
| MX | メール受信 | メール配送先が変わると情報漏えいや業務停止につながる |
| TXT | SPF、DKIM、DMARC、SaaS所有権確認 | メールなりすまし対策やSaaS連携の信頼性に関係する |
| CAA | TLS証明書発行 | 想定外の認証局から証明書が発行されるリスクを確認する |
| DS/DNSSEC | DNS応答の真正性 | DNSSECの検証失敗や鍵不整合による障害を確認する |
| レジストラロック/EPP status | ドメイン移管・更新・削除 | 不正移管や不正更新の抑止状態を確認する |
不正変更が疑われる時に、画面上の値をすぐ戻すと、変更前後の差分、変更者、通知、操作ログを失うことがあります。可用性を守るための復旧は重要ですが、復旧前後のスクリーンショット、エクスポート、チケット、担当者、時刻を残してください。
まず確認すること：DNSレコード変更チェックリスト
最初の確認では「どの値が怪しいか」だけでなく、「誰が正当な変更として説明できるか」を切り分けます。以下は、そのままインシデントチケットや変更管理メモに転記できる形式です。
| 確認項目 | チェック | 記録例 |
|---|---|---|
| 1. 対象ドメイン・ゾーン | ルートドメイン、サブドメイン、委任ゾーンを分けたか | example.invalid, app.example.invalid, marketing.example.invalid |
| 2. 変更レコード | NS、A/AAAA、CNAME、MX、TXT、CAA、DSのどれが変わったか | MX, TXT(DMARC), CNAME |
| 3. 現在値と期待値 | 現在の公開値、社内台帳、IaC、前回エクスポートを比較したか | 現在値, 変更前バックアップ, IaC定義 |
| 4. 変更時刻 | 管理画面、APIログ、通知メール、チケットの時刻をそろえたか | 2026-07-09 10:24 JST |
| 5. 変更者 | 管理者、APIトークン、委託先、SaaS自動連携を特定したか | [email protected], API token, 委託先 |
| 6. 管理者ログ | レジストラ、DNSホスティング、CDN、SaaS、IdPのログを確認したか | login, MFA, record update, API call |
| 7. レジストラ状態 | registrar lock、clientTransferProhibited、clientUpdateProhibitedなどを確認したか | clientTransferProhibitedあり, update lockなし |
| 8. DNSSEC/DS | DSレコード、署名状態、鍵更新、検証失敗の有無を確認したか | DS変更なし, validation errorなし |
| 9. 証明書発行 | Certificate Transparencyなどで想定外の証明書がないか確認したか | 新規発行なし, 発行元CA確認中 |
| 10. メール認証 | SPF、DKIM、DMARC、メール配送先、転送設定を確認したか | MX変更あり, DMARC p=reject維持 |
| 11. SaaS所有権確認 | 不明なTXT/CNAMEがSaaS検証用として追加されていないか確認したか | 未承認SaaS検証レコードなし |
| 12. 影響範囲 | Web、メール、API、管理画面、顧客、社内利用者への影響を確認したか | メール遅延あり, Web影響なし |
| 13. ログ保持 | 変更履歴、通知メール、スクリーンショット、ゾーンエクスポートを保全したか | CSV export, 画面キャプチャ, チケット添付 |
この表で重要なのは、正当な変更の可能性も同時に確認することです。CDN切り替え、メール配信サービス導入、SaaS検証、証明書更新、委託先作業、IaCの自動反映は、悪意がなくてもDNSを変えます。変更管理の記録がない、変更者が説明できない、ログが欠けている場合に優先度を上げます。
初動対応
やること
- レジストラ、権威DNS、CDN、SaaS、IdP、メール管理画面の監査ログを、同じ時間帯で確認する。
- 現在のDNSゾーン、変更前バックアップ、IaC定義、変更チケット、通知メールを同じフォルダやチケットに保全する。
- NS、MX、TXT、CNAME、CAA、DSなど、影響が大きいレコードから優先して期待値と比較する。
- 不明な管理者セッション、MFA変更、回復メール変更、APIトークン利用、委託先操作がないか確認する。
- 影響を受けるWeb、メール、SaaS、API、顧客導線、証明書を一覧化し、復旧と調査の担当を分ける。
- 正当な緊急復旧を行う場合も、復旧前後の値、担当者、承認者、時刻、理由を残す。
やらないこと
- 変更履歴を確認する前に、すべての値を手作業で上書きしない。
- 不明な向き先へブラウザや業務端末でアクセスして安全性を確かめない。
- 第三者ドメイン、IP、ホスティング先に対して探索的なアクセス、スキャン、検証リクエストを送らない。
- DNSSEC、CAA、DMARCなどの意味を確認せずに削除しない。
- DNSレコードだけで「侵害なし」「不正変更確定」と断定しない。
- Cookie、APIキー、管理画面URL、顧客情報をチケットやチャットへそのまま貼らない。
記録すべきこと
| 記録項目 | 書き方 |
|---|---|
| 観測事実 | example.invalid のMXが 2026-07-09 10:24 JST に変更されていた |
| 根拠ログ | Registrar audit log, DNS hosting activity log, IdP sign-in log, SaaS admin log |
| 変更前後 | 変更前値, 現在値, 期待値, 参照した台帳 |
| 変更者 | ユーザー名, APIトークン名, 委託先, 不明 |
| 影響 | メール配送, Web公開, SaaS所有権確認, TLS証明書, 顧客問い合わせ |
| 実施操作 | 復旧, ロック設定, セッション失効, 管理者MFA確認, 委託先確認 |
| 未確認事項 | 証明書発行履歴は確認中, SaaS監査ログは取得待ち |
ログ保全や変更前後の扱いに迷う場合は、インシデント時の証拠保全とはも合わせて確認してください。
判断基準とエスカレーション条件
DNSレコード変更は、影響範囲が小さく見えても、メール、証明書、SaaS、顧客導線へ広がることがあります。以下の条件に当てはまる場合は、情シス担当だけで閉じず、CSIRT、SOC、Web運用、メール管理者、委託先、法務へ早めに渡します。
| 優先度 | 条件 | 対応 |
|---|---|---|
| 高 | NS、MX、CAA、DS、重要サブドメインのCNAMEが、未承認または説明不能に変更された | 変更履歴を保全し、復旧担当と調査担当を分けて、CSIRT/SOCへ連絡する |
| 高 | レジストラやDNSホスティングの管理者ログイン、MFA、回復先、APIトークンに不審な変更がある | 管理者セッション失効、認証情報の再確認、権限棚卸し、ログ保全を進める |
| 高 | 想定外のTLS証明書発行、メール配送先変更、SaaS所有権確認レコード追加が確認された | 証明書、メール、SaaS、顧客影響を並行確認し、必要に応じて外部連絡を検討する |
| 中 | 変更は正当そうだが、チケットや承認記録がなく、委託先・自動化・IaCの説明が揃っていない | 変更管理の証跡を補完し、再発防止として承認フローと通知先を見直す |
| 中 | TTLやキャッシュの影響で、復旧後も一部利用者に古い値が残る | 影響範囲、TTL、キャッシュ、問い合わせ先を記録し、利用者案内を準備する |
| 低 | 承認済み作業で、変更者、変更時刻、チケット、台帳更新、影響確認が揃っている | 変更記録を残し、DNS台帳と監視条件を更新する |
DNSSECはDNS応答の改ざん検知に役立ちますが、正当な管理権限で誤った値や不正な値が登録された場合の承認管理を代替しません。DNSSEC、レジストラロック、MFA、変更管理、監査ログを組み合わせて運用します。
よくある誤解
Aレコードを戻せば終わり
Webの向き先だけでなく、NS、MX、TXT、CAA、DS、CNAMEも確認します。特にメール認証やSaaS所有権確認のTXTレコードは、見た目のWeb表示に影響しなくても、なりすましや外部連携の判断に関係します。
TTLが短いなら影響はすぐ消える
TTLはキャッシュの目安ですが、すべての利用者や中継DNSが同じタイミングで更新されるとは限りません。障害対応では、変更時刻、TTL、権威DNS、社内DNS、外部監視、利用者報告を分けて記録します。
DNSSECを有効にしていれば乗っ取りは防げる
DNSSECは返ってきたDNSデータの真正性検証に役立ちます。一方で、レジストラやDNS管理画面の正当な権限が悪用された場合、承認フロー、MFA、ロック、監査ログ、鍵運用の確認が必要です。
メールが届いているならMXやTXTは問題ない
メール配送が継続していても、SPF、DKIM、DMARC、転送、メール配信サービス、SaaS検証用TXTが意図せず変わっている場合があります。配送可否だけでなく、認証結果と送信元台帳を確認します。
Whoisだけ見れば管理者が分かる
WhoisやRDAPは手掛かりですが、実際の変更者や管理者操作はレジストラ、DNSホスティング、IdP、SaaS、委託先の監査ログで確認します。表示される登録情報と運用上の権限者は別に管理されていることがあります。
関連用語・関連ページ
| 目的 | 内部リンク |
|---|---|
| 用語を確認する | DNSとは、DNSSECとは、Certificate Transparencyとは、TLSとは、PKIとは |
| メール認証を確認する | SPFとは、DKIMとは、DMARCとは、DMARCレポートの読み方 |
| ログと証拠を整理する | DNSログの読み方、セキュリティログの読み方、インシデント時の証拠保全とは |
| 実務で使う | インターネット公開管理画面の緊急点検チェックリスト、フィッシング確認チェックリスト、漏えい疑い初動テンプレート |
| 比較で理解する | HTTPとHTTPSの違い、TLSとSSLの違い、VPNとプロキシの違い |
| 演習で確認する | アクセスログ解析ミニCTF、ログイン失敗ログの読み取りミニCTF、用語クイズ |
公式情報・参考情報
- NIST SP 800-81 Rev. 3: Secure Domain Name System (DNS) Deployment Guide
- CISA AA19-024A: DNS Infrastructure Hijacking Campaign
- ICANN: About Locked Domain
- ICANN: EPP Status Codes - What Do They Mean, and Why Should I Know?
- ICANN: DNSSEC - What Is It and Why Is It Important?
まとめ
DNSレコードが勝手に変わった疑いでは、設定値の復旧だけで終わらせず、誰が、いつ、どの権限で、どのレコードを、何に変えたのかを記録します。NS、MX、TXT、CNAME、CAA、DS、レジストラロック、DNSSEC、証明書、メール認証を同じタイムラインで確認することが重要です。
不明な管理者操作、想定外の証明書発行、メール配送先変更、SaaS所有権確認レコード、顧客影響が見えた場合は、早めにCSIRT/SOCや関係管理者へ渡してください。次に読むページとして、DNSの通信側を確認する DNSログの読み方 と、ログを失わないための インシデント時の証拠保全とは を合わせると、初動判断の精度を上げられます。
