DNSの障害がサービスを落とす前に防ぐ方法

ドメインの有効期限切れや、たった一つのネームサーバーの設定ミスが、サービス全体をオフラインにしてしまうことがある。そして多くのチームは、顧客が気づいてから初めてその事実を知る。

障害の発生から検知までのその空白こそ、信頼が失われる場所だ。DNS障害は独特の厄介さがある。インフラ層ではサイレントに起き、連鎖的に広がり、そしてほぼ完全に防げるにもかかわらず、チームはドメイン有効期限の追跡、ネームサーバーの監査、伝播確認といった基本的なメンテナンスを後回しにしてしまう——本番環境で何かが壊れるまで。

この記事では、なぜDNSが最も優先度の高い監視ギャップであるのか、そして実際の予防戦略がどのようなものかを解説する。

DNS障害がとりわけ深刻な理由

HTTPエラーにはステータスコードがある。サーバーのクラッシュにはログがある。DNS障害には何もない。ただサービスがインターネットから消えたように見えるだけだ。

仕組みはシンプルだ。ドメインの有効期限が切れると、ネームサーバーはNXDOMAINを返す。ネームサーバーが誤設定されると、ユーザーのリゾルバキャッシュの状況によって、一部のユーザーに対して名前解決がサイレントに失敗する。さらにジオ固有のルーティングやマルチCDN構成を採用していれば、その複雑さは急速に増す。us-east-1では正常に動作するルーティングルールが、東南アジアのユーザーに対してはアラートも出ないまま名前解決を静かに壊すことがある。

ポストモーテムで繰り返し登場する3つの障害パターンがある：

ドメインの有効期限切れ：登録業者の自動更新が、クレジットカードの期限切れによって失敗する。ドメインが失効し、スタック全体がオフラインになる。
ネームサーバーの設定ミス：エンジニアが移行作業中にNSレコードを更新し、タイプミスを混入させる。ユーザーの半数がドメインを解決できなくなる。
TTLの計算ミス：移行中に過度にTTLを短縮するとサンダリングハードの問題を引き起こす。反対にTTLが長すぎると、修正をデプロイしてからも伝播に数時間かかる。

これらはいずれも、高度な攻撃者を必要としない。必要なのは、ただの怠慢だ。

ほとんどのチームが抱える監視のギャップ

標準的な稼働時間監視は、HTTPエンドポイントが200を返すかどうかを確認する。それは必要条件だが、十分条件ではない。DNS解決が上流で失敗した場合、HTTPモニター自体がチェック対象のホスト名を解決できなくなり、「ホストに到達できません」という曖昧なアラートが出て、原因究明に時間がかかる。

本当に必要なのは、独立して動作するDNS層の監視だ：

SOAレコードのチェック：権威ネームサーバーが正常に応答していることを確認する
NSレコードの検証：ネームサーバーがレジストラの設定と一致していることを確認する
ドメイン有効期限の追跡：期限切れの後ではなく、30日前・14日前・7日前にアラートを出す
複数リゾルバによる伝播確認：1か所だけでなく、複数のグローバルな拠点から名前解決をテストする

地域ルーティングを持つCDN構成を運用しているチームは、ある地域では正常に解決できて別の地域では解決できない「スプリットブレインDNS」の状況を検知するために、複数の地理的ノードからのチェックが必要だ。

PulseGuardは、SSL・DNS・セキュリティ監視において30秒間隔のチェックをインフラ層で処理する。専任のSREがDNSダッシュボードを常時監視できない、リーンなチーム・フリーランサー・エージェンシー・小規模エンジニアリング組織向けに設計されている。プラットフォームのMCPアクセスにより、監視データをChatGPTやClaude系のワークフローに直接パイプして、AIによるトリアージを実現することもできる。

DNSインシデント対応プレイブックの構築

検知だけでは不十分だ。インシデント対応プレイブックは、対応時間を短縮し人為的なミスを減らす。障害発生時のアドレナリンが判断力を低下させる前に、ステップバイステップの手順を用意しておくためだ。

DNSプレイブックには、最低限以下の内容を盛り込むべきだ：

即時トリアージ（0〜5分）

複数の場所からdig +trace yourdomain.comを実行するか、オンラインのDNS伝播チェッカーを使用する
NSレコードがレジストラの設定と一致しているか確認する：whois yourdomain.com | grep -i nameserver
ドメインの有効期限を確認する
すべてのネームサーバー間でSOAシリアル番号が一致しているか検証する

エスカレーションのトリガー

2つ以上の地理的リージョンでNSレコードが解決できない：P1、オンコールを呼び出す
ドメインの有効期限まで48時間以内：レジストラへの即時対応
ネームサーバー間のSOAの不一致：DNS伝播中または設定ミスの疑い

復旧手順

ドメインが失効した場合：レジストラの緊急ラインに連絡する。多くは失効後約30日間の猶予期間（リデンプション期間）があるが、通常の更新より大幅にコストがかかる。
NSレコードの設定ミスの場合：レジストラのパネルから以前の設定に戻す。今後の移行作業では、変更前にTTLを低く（300秒）設定しておくこと。
伝播の失敗の場合：TTLは変更中ではなく、変更予定の24〜48時間前に短縮しておくこと。

継続的なDNS監視が実際にどのようなものか

顧客がサポートチケットを起票するまで待つのは、監視戦略ではない。チェックの頻度は、多くのチームが思っている以上に重要だ。ポーリング間隔が5分であれば、DNS障害が発生してからアラートが届くまでに最大5分かかることになる。ECサイトやSaaS製品にとって、それは測定可能な売上損失だ。

PulseGuardの30秒間隔のチェックは、SSL・DNS・セキュリティ監視をバンドルした状態でより狭い検知ウィンドウを提供する。運用上のオーバーヘッドをかけずにカバレッジが必要なチームに実用的な選択肢だ。

実践的なまとめ

今週中にDNS監査を実施しよう。 自組織が管理するすべてのドメイン——メインドメイン、サブドメイン、レガシーリダイレクト——の有効期限を確認する。自動更新のバックアップとして、有効期限の60日前にカレンダーリマインダーを設定しておく。

DNS監視とHTTP監視を分離しよう。 稼働時間チェックは、HTTPチェックが通過したからといってDNS解決を前提とするのではなく、独立してDNS解決を検証すべきだ。

プレイブックは必要になる前に書こう。 DNSインシデント対応手順を文書化しておくこと——1ページのチェックリストでも十分——実際の障害が発生したときの平均復旧時間を大幅に短縮できる。

TTLはマイグレーション中ではなく、前に下げよう。 DNSを変更する24〜48時間前にTTLを300秒に下げる。伝播が確認できたら、元に戻す。

DNS障害は地味で、防げるにもかかわらず、ダメージは不釣り合いに大きい。その重大性に見合った扱いをしよう。