ドメイン失効リスクの調査方法｜RDAPで期限・ステータス・依存ドメインを洗い出す

ドメインの失効リスクは、有効期限の日付だけを見ても判断できません。期限、自動更新と支払い手段、ステータスコード、連絡先メール、そしてネームサーバーやメールなど「そのドメインが依存している別のドメイン」まで確認して、はじめて実態が分かります。この記事では、RDAP を使った調べ方と、見落としやすい依存先の洗い出し方を、WordPress サイトの運用者向けに順に説明します。

なぜ失効リスクの調査が必要なのか

ドメインが失効すると、Web サイトだけでなく、そのドメインのメールも止まります。WordPress の管理者アカウントのメールアドレスがそのドメインだった場合、パスワードの再設定メールも届かなくなります。さらに、失効後に第三者に再取得されると、旧ドメイン宛てのメールを受け取られたり、外部サービスのアカウント復旧に悪用されたりするおそれがあります。

失効の原因は、更新忘れよりも「自動更新にしていたのに、カードの期限切れで決済できなかった」「通知メールが退職者のアドレスに届いていた」といった、仕組みの穴によるものが目立ちます。調査では、この穴を一つずつ埋めていきます。

調査1: 有効期限とステータスを RDAP で確認する

gTLD（.com や .net など）の登録情報は、従来の WHOIS に代わって RDAP（Registration Data Access Protocol）が正式な取得手段になっています（2026年10月現在）。RDAP は JSON で結果を返すため、スクリプトで扱いやすいのも利点です。

# rdap.org は TLD ごとの RDAP サーバーへ転送してくれるサービス
curl -sL https://rdap.org/domain/example.com | jq '.status, .events'

events の中の eventAction が expiration になっているものが有効期限です。期限だけを取り出すなら次のようにします。

curl -sL https://rdap.org/domain/example.com \
  | jq -r '.events[] | select(.eventAction=="expiration") | .eventDate'

ここで注意したいのは、レジストリ（TLD の管理者）が返す期限と、レジストラ（契約している事業者）の管理画面の期限がずれる場合があることです。.com などでは、期限を過ぎるとレジストリ側で自動的に1年延長された表示になり、レジストラ側では未払いのまま猶予期間に入っている、ということが起こります。最終的な判断はレジストラの管理画面で行い、RDAP は複数ドメインを一括で見るための入口として使います。

ステータスコードの読み方

status に並ぶ値は、ドメインの状態を表します。代表的なものは次のとおりです。

• client transfer prohibited: 移管ロック。通常の状態で、むしろ付いているほうが安全です
• auto renew period: 期限後に自動更新された直後の猶予期間。レジストラで更新処理が完了しているかを確認します
• redemption period: 失効後の回復期間。通常より高い費用と手続きで戻せる場合があります
• pending delete: 削除待ち。この段階になると、原則として元の登録者でも取り戻せません
• client hold / server hold: DNS に載らない状態。未払いや登録情報の不備、紛争などで設定されます

hold が付いていると、期限内でもサイトは表示されません。登録情報の確認メールに応答しなかったことが原因になっている場合もあるため、レジストラからのメールを見直します。

.jp など ccTLD の場合

.jp などの国別ドメインは、期限の考え方や失効後の扱いが gTLD と異なります。RDAP の提供状況もレジストリによって違うため、.jp では JPRS の WHOIS や、契約しているレジストラの管理画面で確認します。

whois -h whois.jprs.jp example.jp/e

末尾の /e を付けると英語表記で結果が返ります。

調査2: 更新の仕組みに穴がないか確認する

期限がまだ先でも、更新の仕組みが機能していなければリスクは高いままです。レジストラの管理画面で次の項目を確認します。

• 自動更新が有効になっているか
• 登録されている支払い手段が有効で、カードの期限が更新日より後か
• 管理者の連絡先メールアドレスが、今も読まれているアドレスか
• 連絡先メールが、そのドメイン自身のアドレスになっていないか

最後の点は見落とされがちです。admin@example.com を example.com の連絡先にしていると、失効した時点でメールが受け取れなくなり、更新を促す通知も、レジストラのアカウント復旧メールも届かなくなります。連絡先には、別のドメインのアドレスを使います。

レジストラのアカウント自体に二段階認証を設定しているかも、あわせて確認しておきます。乗っ取りによる不正な移管や削除も、失効と同じ結果を招きます。

調査3: 依存している別のドメインを洗い出す

自分のドメインをきちんと更新していても、依存している別のドメインが失効すると影響を受けます。調査で差が出るのはこの部分です。

ネームサーバーのドメイン

dig NS example.com +short

表示されたネームサーバーのホスト名が、自社の別ドメイン（例: ns1.example-dns.net）だった場合、そのドメインの失効は example.com の名前解決の停止に直結します。さらに、第三者がそのドメインを取得すると、DNS の応答を書き換えられる危険があります。ネームサーバーのドメインも、調査対象の一覧に加えます。

メールと外部サービス

dig MX example.com +short
dig TXT example.com +short   # SPF に含まれる include: 先も確認

MX や SPF の include: に、すでに使っていないサービスのドメインが残っていないかを確認します。使っていない設定は削除しておくと、相手側のドメインが失効したときの影響を受けずに済みます。

WordPress サイトが読み込んでいる外部ドメイン

テーマやプラグイン、投稿本文で、外部のドメインから JavaScript や画像を読み込んでいる場合、そのドメインが失効して第三者に取得されると、自分のサイトで任意のスクリプトが実行される状態になりかねません。データベースのエクスポートから外部ホストを抜き出すと、全体像をつかめます。エクスポートは本番サーバーの公開ディレクトリの外に保存し、確認後は削除します。

wp db export /tmp/site.sql
grep -oE 'https?://[A-Za-z0-9.-]+' /tmp/site.sql | sort | uniq -c | sort -rn | head -50
rm /tmp/site.sql

テーマ・プラグインのファイルも同じように grep します。すでに提供が終わったサービスのドメインが見つかったら、読み込みを外すか、ファイルを自サーバーに置く形に切り替えます。

調査結果を継続的な監視にする

一度調べただけでは、次の更新時期にまた同じ穴が開きます。調査で作ったドメイン一覧を元に、期限が近いものを定期的に通知する仕組みにしておきます。

#!/bin/bash
# domains.txt に1行1ドメインで記載。期限まで60日を切ったものを表示する
while read -r d; do
  exp=$(curl -sL "https://rdap.org/domain/$d" \
    | jq -r '.events[]? | select(.eventAction=="expiration") | .eventDate')
  [ -z "$exp" ] && { echo "$d: 期限を取得できませんでした"; continue; }
  days=$(( ( $(date -d "$exp" +%s) - $(date +%s) ) / 86400 ))
  [ "$days" -lt 60 ] && echo "$d: 残り ${days} 日 ($exp)"
done < domains.txt

短時間に大量の問い合わせを送ると、RDAP サーバー側で制限されることがあります。実行は1日1回程度にとどめ、取得できなかったドメインはレジストラの画面で個別に確認します。

まとめ

• 失効リスクは、期限、自動更新と支払い、連絡先、ステータス、依存ドメインの5点で調べる
• gTLD の期限とステータスは RDAP で取得でき、最終判断はレジストラの管理画面で行う
• 連絡先メールを同じドメインにしていると、失効時に通知も復旧手段も失う
• ネームサーバー、MX・SPF、サイトが読み込む外部ドメインも調査対象に含める
• 調査結果のドメイン一覧は、期限の定期チェックに流用する

• ドメインの自動更新を設定する方法
• ドメインの猶予期間と償還期間の違い