サイレントキラー:ドメイン有効期限切れによるダウンタイム

ドメインの有効期限切れは、最も恥ずかしいインフラ障害の一つです。理由は次のとおりです:

100%予防可能 — サーバークラッシュとは異なり、ドメインの有効期限は事前に分かっています
人的ミスである — 更新リマインダーが迷惑メールに振り分けられたり、担当の管理者が退職したり、発注書が紛失したりします
すべてに影響する — ウェブサイト、メール、API、CDN — すべてがドメイン名の動作に依存しています
印象が非常に悪い — お客様は「更新を忘れた」のではなく「事業をやめた」と思ってしまいます

ドメイン有効期限切れによるダウンタイムの実例

Marketoのウェブサイト障害(2016年)#

Marketoのウェブサイトドメインが期限切れ
自動更新が無効
サイトが2時間にわたり404エラー
Googleが404ページをキャッシュ
数週間にわたるSEOへの悪影響
原因:更新メールが迷惑メールフォルダに振り分けられた

スタートアップYの全面障害(2019年)#

創業者Aがドメインを購入しDNSを設定後、退職
創業者Bは自動更新になっていると思い込み
創業者C(運用担当)はレジストラアカウントの所有者を知らず
金曜日にドメインが期限切れ
週末にAPIがダウン — 誰も対応できず
原因:ドメインレジストリの一元管理がなく、プロセス文書化もなし

エージェンシーZのメール崩壊(2021年)#

エージェンシーが50のクライアントドメインをホスティング
1ヶ月で5つのドメインが期限切れ
モニタリングなし、自動更新なし
50のクライアント全員がメール機能を喪失
サポート窓口がチケットで溢れる
原因:ドメインの一元管理がなく、手動のスプレッドシート追跡のみ

ドメイン有効期限切れがダウンタイムを引き起こす仕組み

シナリオ1:完全なドメイン期限切れ#

4月15日: mycompany.com が期限切れ
   ↓
ドメインレジストラがドメインを解放
   ↓
競合他社またはスクワッターがドメインを購入
   ↓
mycompany.com が競合サイトまたはパーキングドメインを指す
   ↓
すべてのトラフィック:ウェブサイト、メール、API — すべて失敗
   ↓
100%のビジネスダウンタイム

シナリオ2:レジストラアカウントのロック#

ドメインが期限切れになるが、「猶予期間」が存在する(5〜30日)
猶予期間中、ドメインは動作するがDNS変更ができない
新しいCDNへ移行しようとする → DNS変更不可
新しいサービスを追加しようとする → DNSレコード作成不可
インフラ全体の変更が30日以上凍結

シナリオ3:DNS継続性の断絶#

ドメインが期限切れ、猶予期間も終了
DNSレコードが消失
猶予期間内に更新しても、
DNSが再伝播するのに24〜48時間かかる場合がある
お客様には2日間DNS NXDOMAINエラーが表示される

ドメイン有効期限切れによるダウンタイムのコスト

通常のダウンタイム(数分から数時間)とは異なり、ドメイン有効期限切れによるダウンタイムは数日続きます:

典型的なドメイン有効期限切れの影響:

検知時間:2〜6時間(誰かがサイトのダウンに気付くまで)
根本原因の特定:30〜60分(レジストラのロック?期限切れ?DNSの問題?)
レジストラへの連絡:30分〜2時間(サポート時間はレジストラにより異なる)
ドメイン更新:5〜10分(実際の更新プロセス)
DNS伝播:1〜24時間(DNSキャッシュTTL)
合計ダウンタイム:6〜48時間

財務的影響($1M ARRのSaaSの場合):

損失収益:6〜48時間 ÷ 730時間/月 × $83K/月 = $688〜$5,500
顧客解約:2〜5社の乗り換え(推定$1,000〜2,500)
サポート負担:20〜50件のサポートチケット(推定$500〜1,500)
合計:1ドメインの期限切れにつき$2,700〜9,500

ドメイン有効期限の追跡:手動 vs 自動#

手動アプローチ:スプレッドシートでの追跡

プロセス:

ドメイン名と有効期限のスプレッドシートを作成
マネージャーが毎週手動でスプレッドシートを確認
期限が近づいたドメインがある場合、チームに通知
チームメンバーがレジストラでドメインを更新
更新内容をスプレッドシートに記録

問題点:

スプレッドシートが同期されなくなる(更新を忘れる)
早期更新を行うと有効期限が変わる
スプレッドシートを確認しないとアラートが出ない
組織全体での一元化が難しい(複数のレジストラ)
各ドメインの所有者が不明確(責任の所在が曖昧)
約10ドメインを超えるとスケールしない

自動アプローチ:一元的なモニタリング

プロセス:

ツールがRDAP/WHOISルックアップですべてのドメインをモニタリング
有効期限の90日前、30日前、14日前、7日前に自動アラート
ツールがメール、Slack、SMS経由でアラートを送信
レジストラAPIが利用可能であれば、ツールが自動更新可能
更新の履歴ログが自動的に保持される

利点:

手動チェックが不要
アラートの見逃しが起こりにくい(複数チャネル)
スプレッドシートのずれがない
数百のドメインまでスケール可能
複数のレジストラに対応

ドメイン有効期限モニタリングの設定方法

ステップ1:ドメインの一元化#

組織を監査します:

どのドメインを所有していますか?
どのレジストラを使っていますか?(GoDaddy、Namecheap、Google Domains、Route 53など)
誰がアクセス権を持っていますか?
どれが重要で、どれが副次的ですか?

インベントリの例:

重要:
  - mycompany.com (GoDaddy)
  - api.mycompany.com (Route 53)
  - mail.mycompany.com (Namecheap)

副次的:
  - mycompany.io (GoDaddy)
  - legacy.mycompany.com (Namecheap)

ステップ2:レジストラで自動更新を有効化#

重要なステップ:ドメイン期限切れの大半は、自動更新がOFFになっていることが原因です

レジストラのアカウント(GoDaddy、Route 53、Namecheap)で:

ドメイン設定に移動
「自動更新」オプションを探す
有効にする
更新期間を設定:最低1年

これにより、モニタリングが失敗しても予期せぬ期限切れを防げます。

ステップ3:Nova Uptimeのモニタリングにドメインを追加#

Nova Uptimeは追加したドメインの有効期限を追跡します:

Nova Uptimeにドメインを追加:go.novauptime.com
Nova UptimeがRDAPルックアップを実行:ドメインレジストリに問い合わせ
domainExpiryDateを保存
domainDaysRemainingを計算
アラートを設定:
- 90日前:イエローアラート
- 30日前:オレンジアラート
- 7日前:レッドアラート
- 期限当日:クリティカルアラート

ステップ4:アラートチャネルの設定#

Nova Uptimeは以下の経路でアラートを送信します:

メール(ドメイン所有者へ)
Slack(運用チャンネルへ)
通知ページ(ダッシュボード内)
Webhook(カスタム連携)

Slackメッセージの例:

🟠 ドメイン更新リマインダー
ドメイン: api.mycompany.com
有効期限: 2026年5月15日 (30日)
アクション: レジストラで更新
ステータス: https://gum.yourcompany.com/domain/api

ステップ5:更新の追跡#

ドメインを更新したら:

「このドメインを更新しました」ボタンをクリック(期限切れメール内)
Nova Uptimeがドメインを確認済みとしてマーク
翌日、Nova UptimeがWHOIS/RDAPを再チェック
更新を自動検出
確認メールを送信

これにより、更新後の誤検知アラートを防ぎます。

よくあるドメイン有効期限の失敗

失敗1:自動更新がOFF#

❌ 間違い:自動更新が有効だと思い込む
         更新リマインダーが届くだろうと想定する
         結果:ドメインが期限切れ

✅ 正解:今すぐレジストラのアカウントを確認
       自動更新が利用可能なら有効化
       最低1年の更新に設定

失敗2:更新メールが迷惑メールに振り分けられる#

❌ 間違い:レジストラがoperations@company.comに更新リマインダーを送信
         メールが迷惑メールに振り分けられる
         誰も気付かない

✅ 正解:レジストラのメールをホワイトリストに追加
       レジストラのメールをチームに転送
       モニタリングツールで重複アラートを使用

失敗3:ドメインの所有者が一人だけ#

❌ 間違い:Johnだけがレジストラアカウントにアクセス可能
         Johnが退職
         新入社員はJohnがドメインを更新したことを知らない
         Johnは後任者にアクセス権を渡さない

✅ 正解:レジストラでチームアカウントを作成
       複数のメンバーがアクセス可能
       ドメインの所有者を文書化
       モニタリングツールを使用(レジストラアクセスから独立)

失敗4:複数のレジストラ、一元管理なし#

❌ 間違い:一部のドメインはGoDaddy、一部はRoute 53、一部はNamecheap
         マネージャーがGoDaddyを確認し、Route 53の確認を忘れる
         Route 53のドメインが期限切れ

✅ 正解:すべてのドメインを一つのレジストラに集約(可能な限り)
       またはすべてのレジストラをチェックするモニタリングツールを使用
       すべての有効期限の単一の信頼できる情報源

失敗5:副次的ドメインの追跡なし#

❌ 間違い:プライマリドメイン(mycompany.com)のみモニタリング
         api.mycompany.com、status.mycompany.comなどを忘れる
         副次的ドメインが期限切れ
         APIダウン、ステータスページダウン

✅ 正解:すべてのドメインを監査(プライマリ、API、ステータスページ、メールなど)
       それぞれを独立してモニタリング
       任意のドメインの期限切れでアラート

ドメイン有効期限モニタリングのベストプラクティス

1. レジストラで自動更新を有効化#

モニタリングがあっても、自動更新はバックアップになります。

2. すべてのドメインをモニタリングツールに追加#

プライマリドメインだけでなく、API、ステータスページ、メール、CDN、サブドメインも対象にしましょう。

3. 複数チャネルにアラートを設定#

運用へのメール + #infrastructureチャンネルへのSlack + レジストラへのメール(通常は自動)

4. ドメインの所有者を文書化#

スプレッドシートまたはwikiページを管理:

ドメイン | レジストラ | 所有者 | チーム | 更新日 | 自動更新
mycompany.com | GoDaddy | ops@company.com | Ops | 2026年5月 | 有効
api.mycompany.com | Route 53 | devops@company.com | Infra | 2026年5月 | 有効

5. 四半期ごとにアラートシステムをテスト#

依存していないテスト用ドメインを意図的に期限切れにして、アラートが発火するか確認しましょう。

6. レジストラアカウントのアクセス権を文書化#

誰がどのレジストラにアクセスできるか?
認証情報はどこに保管されているか?(1Password、チームのVaultなど)
現担当者が退職した場合、誰が所有者になるか?

7. 更新の追跡#

ドメインを更新したら、記録します:

更新日
次回の有効期限
自動更新ステータスの確認
更新を実行した担当者

8. レジストラ移行の計画#

レジストラを切り替える場合:

オフピーク時間帯にドメインを移行
移行中にドメインを期限切れにしない
移行後にDNSが引き続き機能することを確認

Nova Uptimeのドメイン有効期限追跡#

Nova Uptimeでは以下を提供しています:

機能:

RDAP + WHOISルックアップ(レジストラの自動検出)
履歴データ付きの有効期限追跡
残り日数の計算(毎日自動的に再計算)
アラートシステム(90/30/7/1日アラート)
メール + Slack + Webhook通知
更新確認ボタン
毎日のRDAP再チェックによる更新の自動検出
ダッシュボードのドメインカードに有効期限ステータスを表示

連携:

Nova Uptimeにドメインを追加
  ↓
RDAPルックアップ:「mycompany.com は2026年5月15日に期限切れ」
  ↓
毎日:「残り34日」(自動更新)
  ↓
90日前:メールアラート
30日前:メール + Slackアラート
7日前:メール + Slack + SMSアラート
当日:クリティカルアラート、オンコール担当者を呼び出し
  ↓
レジストラで更新を実施
  ↓
「更新しました」ボタンをクリック
  ↓
翌日、Nova UptimeがWHOISを再チェック
  ↓
更新を自動検出し、「更新が確認されました!」メールを送信

まとめ:ドメイン有効期限切れ防止チェックリスト

ドメインを予期せぬ期限切れから守りましょう: Nova Uptime ドメイン有効期限モニタリング。RDAPルックアップ、マルチアラートシステム、更新追跡。🚀