2026年8月13日、米アリゾナ州フェニックスを襲った嵐が、世界的なドメインレジストラ（ドメイン名の登録受付・管理を行う事業者）Namecheapのサービスを止めた。同社の一部の中核業務を収容するデータセンター「RadiusDC: Phoenix」で冷却システムが故障し、機器周辺の温度が危険水準に達した。サービス停止を指示したのはNamecheapではなくデータセンター事業者のRadiusDC側で、Namecheapは顧客インフラを過熱による損傷から守るためこれに従った[1]。
この障害でとりわけ示唆的なのは、止まったものと止まらなかったものの内訳だ。Namecheapの公式説明によれば、DNSのゾーン解決（名前解決）は継続していた。止まったのはDNS管理のほうだ[1]。BasicDNS・PremiumDNSによるURLリダイレクトも応答自体は続き、止まったのはその管理機能だった。
つまり、既存のDNSレコードは引き続き引かれていたが、そのレコードを変更する手段が失われた。障害中に別の宛先へ切り替えようとしても、切り替える操作そのものができない。本記事ではこの構造を整理し、日本企業の情報システム部門が自社のドメイン・DNS依存関係をどう点検すべきかを検討する。
予備知識
- レジストラ: ドメイン名の登録受付・管理を行う事業者。お名前.comやNamecheapなどが該当する。
- 権威DNSサーバー: 自ドメインのレコードに責任を持って応答するDNSサーバー。ここが応答すれば名前解決は成立する。
- コントロールプレーン / データプレーン: 設定を変更する経路（管理面）と、実際のトラフィックを処理する経路（データ面）。今回はデータ面が生きたままコントロールプレーンだけが落ちた。
- セカンダリDNS: プライマリDNSとは別事業者・別インフラで同じゾーン情報を提供する冗長構成。
自社のドメイン・DNSがどの事業者にどう依存しているかを棚卸しする前に、レジストリ・レジストラ・DNSサーバーの役割分担を正しく理解しておきたい担当者向けの定番教科書。
何が起きたのか——止まったもの、止まらなかったもの
発端は2026年8月13日、フェニックス周辺を襲った大規模な嵐による冷却システムの故障だった。RadiusDC: Phoenixは高い冗長性を備えたTier 3データセンターであり、Namecheapは公式説明の中で「25年の歴史で経験したことがない、きわめて異例の事象だった」としている[1]。
冷却が失われた状態で稼働を続ければ機器の過熱と恒久的な損傷を招くため、RadiusDCの指示でサービスがオフラインにされた。冷却が回復して温度が安全域に戻るまで機器は停止したままとされ、その後、段階的に復旧が進んだ。ホスティングやメールはサーバー・ネットワーク・ストレージ・データベースといった複数の層に依存するため、一斉に戻すのではなく順序立てて戻す必要があったと同社は説明している[1]。
影響範囲を公式説明の記述に沿って整理すると、次のようになる[1]。
| 対象 | 状態 |
|---|---|
| DNSゾーン解決（名前解決） | 継続 |
| DNS管理 | 停止 |
| URLリダイレクト（BasicDNS / PremiumDNS）の応答 | 継続 |
| URLリダイレクトの管理 | 停止 |
| 共用・VPS・専用ホスティング、EasyWP | 停止（Webサイトが不達・低速・エラー） |
| Private Email | 送信不可、受信も配送されず（※） |
| 課金処理の一部 | 停止 |
| サポート（ライブチャット・メール） | 停止 |
※ 受信メールについて同社は「自動的に失われることを意味しない。送信側のメールサーバーは受信側が一時的に応答しない場合に再送を試みるため、メッセージは通常より遅れて到着する」と説明している[1]。
同社は再発防止として、欧州・アジアを含む各データセンター間でさらに冗長性を高める方針を表明した[1]。裏を返せば、障害発生時点では地理的冗長化が不十分だったということでもある。
なお、この障害についてはX上の初期投稿でデータセンター事業者がPhoenixNAPだと報じられたが、Namecheapは公式に「事業者はRadiusDCであり、PhoenixNAPは本件に関与していない」と訂正している[1]。二次情報を引くときに混同しやすい点なので注意したい。
外部ベンダー起因の障害が発生した際、自社側でどう初動対応し復旧までの体制を回すかを体系的に学べる一冊。
なぜ「クラウド利用済み」でも防げないのか
自社の本番システムをAWSやAzureなど複数リージョン構成のクラウドで冗長化していても、ドメイン登録・DNS管理という「入り口」を単一のレジストラに委ねていれば、そこが単一障害点になる。
ただし今回の事例が示した危険は、よく言われる「名前解決が止まってサービスが見えなくなる」という形ではなかった。名前解決は生きていた。危険だったのは、障害の最中に何ひとつ切り替えられなかったことのほうだ。ホスティングが落ちている状況で、DNSレコードを別の待機系へ向け直したくても、その操作を受け付ける管理画面もAPIも同じデータセンターの中にあった。
この構造的な弱点は目立ちにくい。本番アプリケーションの冗長化は稟議や設計レビューの対象になりやすい一方、ドメイン登録やDNS設定は初期構築時に一度決めたら見直されないことが多く、監査の対象からも漏れやすい。「名前解決さえ生きていれば大丈夫」という整理では、今回のような管理面の停止を評価できない。
権威DNSサーバの代表格であるISC BIND 9で、DNSSEC（DNS応答の改ざんを電子署名で検証する仕組み）の検証をすり抜けられる脆弱性が見つかった。Internet Systems Consortium（ISC）は2026年7月2[…]
復旧を待つ間に何ができたか——事前準備がすべてを決める
障害が始まってからできることは、実はほとんどない。管理面が落ちている以上、その時点でレコードを変更する手段がないからだ。有効なのは、すべて事前の設計判断になる。
セカンダリDNSの併用は、今回のケースでは名前解決を救う手段としては働かない（名前解決は元々生きていた）。意味を持つのは別の側面で、プライマリのレジストラとは別の事業者にゾーンを持たせておけば、そちらの管理面が生きている限りレコードを操作できる。冗長化の目的をデータ面ではなくコントロールプレーンに置き直すと、評価が変わる。
TTLの設計も同様に事前の話だ。TTLを長めに取っておけば権威サーバーが完全に無応答になってもキャッシュで延命できるが、逆に切り替えたいときの反映が遅くなる。障害発生後にTTLを短くしようとしても、その変更操作自体が管理面を通るため間に合わない。
メールの代替経路は、MXレコードを複数の配信経路に分散しておくこと。今回のように受信サーバーが停止した場合、送信側の再送で最終的には届くとはいえ、遅延が業務に直結する用途では別経路が要る。
いずれも設定自体は難しくないが、「なぜ今それをやるのか」という説明が必要になるため、平時の稟議では後回しにされがちだ。今回のような具体的な障害事例は、その説明材料として使える。
| 対策 | 何を守るか | 今回のケースで効いたか |
|---|---|---|
| セカンダリDNS（別事業者） | 名前解決＋別系統の管理面 | 名前解決は不要だったが、管理面の確保として有効 |
| TTLを長めに設計 | 権威サーバー無応答時の延命 | 名前解決が生きていたため出番なし |
| 代替MXレコード | メール受信の継続 | 有効（受信停止を回避できた） |
| 別レジストラでの予備ドメイン | 緊急告知手段の確保 | 有効（サポート窓口も停止していた） |
社内向けのDNS運用は、長らくVPN専用機器やActive Directory統合DNSサーバーなど、パブリックDNSとは別建ての基盤で行われてきた。ネットワーク・インフラ運用チームにとって、この二重構成は監査ログの分断や設定ドリフトの温[…]
日本企業のドメイン・DNS管理、盲点はどこにあるか
日本企業の多くは、コーポレートサイトや基幹システムのドメインをお名前.comやGMOグローバルサインなど国内レジストラで管理している。一方で、マーケティング部門が立ち上げたキャンペーンサイトや、海外子会社・買収先企業が引き継いだドメインは、Namecheapのような海外レジストラで登録されたまま、情報システム部門の管理台帳に載っていないケースが少なくない。いわゆるシャドーITの一形態である。
この「見えないドメイン」は、平時は問題にならない。しかし、そのドメインが顧客向けサービスやメール配信のMXレコードに使われていた場合、今回のような海外レジストラ側の障害がそのまま自社の対外的な障害として顕在化する。情報システム部門が把握していない依存関係は、障害発生時の初動対応も遅れる。今回はサポート窓口自体も停止していたため、事業者への問い合わせという手段も封じられていた[1]。
日本企業とグローバル企業を単純比較すると、社内のドメイン管理体制には次のような違いが出やすい。
| 観点 | 典型的な日本企業 | グローバル展開企業 |
|---|---|---|
| ドメイン管理の一元化 | 部門ごとに個別契約されがち | 情シスがドメイン管理台帳を一元管理 |
| 海外レジストラの利用 | 稟議を通しにくく限定的 | 現地法人・買収先経由で分散しやすい |
| セカンダリDNSの採用 | コスト対効果の説明が難しく後回し | SLA要件として標準採用されることが多い |
情シス担当の次の一手は、社内の全ドメインとDNS管理事業者を棚卸しし、管理台帳に載っていないドメインがないか確認すること。そのうえで「名前解決が止まったら」ではなく「管理画面にログインできなくなったら」という問いで既存構成を点検すると、今回のような事象を評価できる。決裁側の判断材料は、セカンダリDNS導入の追加コストと、切り替え不能な時間が事業に与える損失との比較になる。
2026年7月15日（太平洋夏時間、日本時間では16日早朝）、Google Cloud（グーグルが提供するクラウド基盤サービス）のオランダ拠点で電源網の異常が発生し、冷却設備の停止を経て、europe-west4-a（オランダに置かれたア[…]
まとめ
今回の障害から取り出すべき教訓は「レジストラが落ちると名前解決が止まる」ではない。Namecheapの公式説明では名前解決は継続しており、止まったのは管理面だった。データ面が生きていても、設定を変更する経路が同じデータセンターに同居していれば、障害の最中に打てる手はなくなる。自社のドメイン・DNS構成を点検するときは、「応答が返るか」ではなく「変更できるか」を軸に見直したい。棚卸しと、コントロールプレーンを別系統に分ける設計判断は、いずれも平時にしかできない。
よくある質問（FAQ）
Q. ドメインのレジストラを複数に分けることはできますか？
A. 1つのドメインを複数のレジストラで同時管理することはできない。ただし、DNSサーバー（名前解決を行う仕組み）はレジストラとは別の事業者を併用でき、これがセカンダリDNSと呼ばれる一般的な冗長化手法になる。
Q. 今回、名前解決が生きていたなら実害は小さかったのですか？
A. 名前解決の継続はドメインが「引ける」ことを意味するだけで、その先のホスティングやメールは停止していた[1]。加えてDNS管理・課金・サポートも止まっており、利用者側から見れば復旧を待つ以外の手がない状態だった。
Q. 自社のドメインがどのレジストラで管理されているか、簡単に確認する方法はありますか？
A. WHOIS検索（各種WHOIS照会サービスやコマンドラインのwhoisコマンド）でドメインごとの登録レジストラを確認できる。社内の全ドメインを洗い出したうえで一括照会すれば、管理台帳との差分を把握できる。
