【Core SSoT】インシデント・レポート：DNSドリフトによるサイトダウン障害とDNSガバナンス

⚠️ THE GENERATIVE SSoT: POST-MORTEM & INFRASTRUCTURE GOVERNANCE 本ドキュメントは、2026年10月2日に発生した docs.moshimo.ok.st へのアクセス障害（タイムアウト）に関する徹底的な原因調査、および二度と人為的ミスを許容しないための絶対的な再発防止策（DNSガバナンス）を定義する。

1. 障害の事象と徹底的な原因分析 (Root Cause Analysis)

1.1 事象

https://docs.moshimo.ok.st/ へブラウザからアクセスすると、ページが表示されず「ネットワークタイムアウト（Connection timed out）」となる。

1.2 徹底的な調査と原因特定

デプロイスクリプト（deploy_secure_docs.nu）は正常に完了していたが、外部からのアクセスのみが遮断されていた。ネットワークレベルでの調査（dig および whois）を実施した結果、以下の致命的な**「DNSの不整合（DNSドリフト）」**が特定された。

• 正解のIPアドレス: ap01.ok.st = 163.44.119.9 (ConoHa VPS / 本番Nginxサーバー)
• 誤った設定（現在のDNS）: docs.moshimo.ok.st = 121.83.117.238 (OPTAGE Inc. / eo光の一般回線IP)

【結論】 Cloudflare等のDNS管理画面において、docs.moshimo.ok.st のAレコードが、本番サーバー（ap01.ok.st）ではなく、**加藤CTOの自宅またはオフィスのローカル回線（eo光）のIPアドレスに向いたまま放置されている人為的ミス（設定漏れ）**が根本原因である。 デプロイ処理自体は ap01.ok.st へIP直指定でアップロードを行っていたため「成功」していたが、閲覧者（ブラウザ）は誤ったIP（eo光のルーター）へリクエストを送り、ポート443が開放されていないためタイムアウトしていた。

2. 絶対的な再発防止策 (Recurrence Prevention)

インフラ設定におけるヒューマンエラーをシステムレベルで遮断するため、以下のガバナンスを即時適用する。

2.1 [ルール] サブドメインの Aレコード(IP直打ち) の絶対禁止

今後、*.ok.st のサブドメインを発行する際は、IPアドレスを直接指定する「Aレコード」での運用を固く禁ずる。 必ず、親サーバー名への**「CNAMEレコード」**として登録しなければならない。

• ❌ 誤: docs.moshimo.ok.st -> A -> 163.44.119.9 (IPが変わると死ぬ)
• ✅ 正: docs.moshimo.ok.st -> CNAME -> ap01.ok.st (ap01のIPが変わっても追従する)

2.2 [実装] デプロイ時の DNS Validation 強制

deploy_secure_docs.nu 実行時に、単にファイルを転送するだけでなく、「デプロイ先のドメインが、本当に本番サーバーのIPを向いているか」をデプロイ前にチェックし、一致しなければHard-Failさせるロジックを組み込む。

3. 即時復旧のためのアクション (Immediate Remediation)

本障害を解決し、直ちに会議用資料を閲覧可能にするための手順。

1. DNSレコードの修正 (加藤CTO タスク): Cloudflare または DNSレジストラ（ムームーDNS等）の管理画面に入り、docs.moshimo.ok.st のレコードを以下のように修正する。
   • タイプ: CNAME
   • 名前: docs.moshimo
   • ターゲット: ap01.ok.st
2. 反映の確認: 手元のターミナルで dig docs.moshimo.ok.st を実行し、163.44.119.9 が返ってくればDNSの修正は完了。
3. ブラウザ確認: 再度 https://docs.moshimo.ok.st/ へアクセスすれば、先ほどデプロイした資料が即座に表示される。