DNS 運用における「ゴーストドメイン問題」との向き合い方：現象・原因と対策

DNS の運用において、専門家でさえ遭遇すること稀な**「エッジケース」が存在します。レジストリによって引き下げられたドメインであっても、アップタイムチェッカーは数日間も「正常（UP）」**として認識され続けることがあります。

これは

.de

（ドイツ）ゾーンで特に顕著に発生する現象であり、他のレジストリや国コードトップレベルドメイン（ccTLD）、グローバルトップレベルドメイン（gTLD）でも同様の仕様が存在します。多くの監視サービスはこの問題を検知できておらず、製品が数年間運用されてもこの「ゴースト」との共存を余儀なくされます。

本稿では、なぜこの問題が発生するのか、および我々が行う小さな改修について解説します。

---

現象の現れ方

ドメイン名がレジストリによって削除・停止された後、依然として「存在している」と誤認識される原因は以下の通りです。

• 厳格な検証ポリシーによる早期停止

  • .de

    （DENIC）：期限までに保有者情報が検証されないと、まずゾーンから削除され、完全に消去されます。

  • .eu

    （EURid）：データを検証できない場合は、「撤回済み（no longer registered）」状態に遷移します。

  • .fr

    （AFNIC）：適格性及び連絡可能性のチェックで失敗すると、ドメインの停止乃至削除が可能です。
  • 共通点：レジストリ側がデリゲーション（名前サーバーへの委譲）を引き上げた場合でも、ドメイン自身のオーソリタブ・ネームサーバーは依然として旧来の回答を続けるため、DNS レコード上にはまだ存在します。

• ICANN gTLD における停止ルール

  • WHOIS 精度プログラムにより、検証リクエストへの回答がない期間が15 日を超えると、レジストラはドメインを

    terminate

    、

    clientHold

    、または停止する義務があります。
  • その結果としてドメインはゾーンから公出版されますが、ネームサーバー自体の挙動が変わらないため「存在」扱いになります。

• エラーの発生と検知バイアス

  • レゾルバ側（ユーザー）：子ゾーンの記録を保持しなくなった場合、

    NXDOMAIN

    （RCODE 3: "名前が存在しない"）エラーが発生し、サイトが表示されません。
  • アップタイムチェッカー側：長期間使用される再帰型レゾルバのキャッシュを保持しているため、「寒いキャッシュ（cold cache）」か「温かいキャッシュ（warm cache）」かの違いが生じます。
  • 結果：サイトは見かけ上正常ですが、実際には削除済みのゴーストドメインです。

バグの位置：なぜ制御できないのか

これはアップタイムチェッカーのサーバー上の設定ミスではありません。DNS の連鎖構造そのものにおける限界です。

DNS の解決フロー（簡易例）

[PHP/curl]
  │
  └──> glibc nsswitch (/etc/resolv.conf -> 127.0.0.53)
       │
       └──> systemd-resolved (ローカルキャッシュ・スタブ)
            │
            └──> アップストリームの再帰型レゾルバ（ホスティングプロバイダ共有または自管）
                 │
                 └──> オーソリタブなネームサーバー（ドメインの DNS プロバイダ）

• バグの本質：実際の解決作業は「アップストリームの再帰型レゾルバ」で行われます。
• 制御不能：我々のサーバーでも、お客様のお服务器でもない**「キャッシュ層」**です。デッド・デリゲーション（無効な委譲）がキャッシュに保存され続けることは、再帰型 DNS の動作原理上避けられません。
• 結論：最も勤勉なチェッカーを配備しても、制御できないグローバルなキャッシュを信頼するため、誤った回答を返してしまう可能性があります。

ゴーストドメインのメカニズム（簡易解説）

この現象は学術的に「ゴーストドメイン問題」と呼ばれ、以下のように段階的に進行します。 ※関連規格：RFC 2181（信頼性規則）、RFC 9499（デリゲーション用語）、IETF ドラフト

draft-ietf-dnsop-ns-revalidation

ステップ 1：最初のルックアップ

1. 再帰型レゾルバが初めてドメインを検索すると、親ゾーン（例：

   .de

   ）へ問い合わせます。
2. 親ゾーンは「ホストしていないが、ネームサーバーは NS1 と NS2 です」という**参照（referral）**を返します。
3. レゾルバはこの NS サーバーを直接問い合わせると、オーソリタブな回答としてアペックス NS RRset が返ってきます。この記録がキャッシュされます。

ステップ 2：優先度の入れ替え

• 親ゾーンからのデータ vs 子ゾーン（アペックス）からのデータ。
• RFC 2181 の規則に従い、子ゾーンのアペックスからのオーソリタブなコピーは親ゾーンの参照よりも優先されます。
• これにより、キャッシュ内の親側情報は子側の情報で置換され、「子側の NS レコードが正解である」という状態が確定します。

ステップ 3：A レコードの有効期限切れとループ

1. 有効期限切れや停止により、子ゾーンからの A レコードが返さなくなります。
2. レゾルバはキャッシュされたアペックス NS RRset を見つけ、再度 NS サーバーを問い合わせます。
3. 重要：レジストリがデリゲーションを引き上げたことを知らないため、オーソリタブネームサーバーは依然として肯定的な回答（旧データ）を行います。
4. 新しい A レコードもキャッシュされ、このループ状態が続きます。

ステップ 5：なぜ再検証が行われないのか？

デフォルト設定では、親ゾーンを再照会しないケースが多々あります。主要ソフトウェアの挙動は以下の通りです。

レゾルバ	カッシュ期間 (TTL)	親ゾーン再検証機能	備考
BIND	max-cache-ttl = 1 週間	なし	デフォルトではデリゲーションの再検証制御機能なし
Unbound	cache-max-ttl = 1 日	harden-referral-path (デフォルト：Off)	参照パスのハードニングが未設定の場合あり
PowerDNS Recursor	max-cache-ttl = 1 日	save-parent-ns-set (フォールバック)	再検証ではなく、失敗時の保存機能です
systemd-resolved	システム依存	なし	上流からの設定をそのまま継承

• キャッシュの温もり：頻繁なチェックによってキャッシュが温まっているか？と考える誘惑がありますが、誤解です。
• 真の原因：ゴースト存続期間は、アペックス NS RRset がキャッシュから淘汰されるまでの時間に依存します。
• チェック頻度の限界：生存期間自体が TTL 制限されているため、チェック数を減らしてもゴースト現象を防ぐことはできません。NS の TTL が長くても同様です。

他の監視サービスが行っていること（現状分析）

市場主要社の公開ドキュメント（Pingdom, UptimeRobot, Datadog, Better Stack など）を確認しましたが、この問題に対する防衛策は見つかりませんでした。

• Pingdom のケース
  • 独自に BIND9 DNS サーバーをプローブサーバー上に配置していますが、DNS 記録は当然キャッシュされます。
  • デフォルトの

    max-cache-ttl

    が1 週間の場合、ゴーストドメインが数日間存続する仕組みになっています。
• 他社の対応状況
  • ドメインの有効期限監視はありますが、レジストリレベルでのデリゲーション削除をアップタイムチェックの独立したケースとして扱っているツールはありませんでした。

注記: これは特定のサービスに対する批判ではありません。DNS レイヤ層の問題が HTTP レイヤ製品の下に隠れているため、目に見えないままだった可能性があります。

我々が強化していること：改修の詳細

今回の改修は範囲を絞っています。「我々の方が優れている」のではなく、「自分自身で設定可能なパラメータ（ノブ）を得ることです。

採用したアーキテクチャ

各チェッカーにローカルの再帰型レゾルバを設置し、共有上流へのフォワーディングではなく完全な再帰処理を行います。使用ソフトウェアは

Unbound

です。

主な設定変更（ノブ）

設定項目	デフォルト値	我々の設定	理由
cache-max-ttl	1 日	1 時間	陳腐化したアペックス NS RRset がゴースト化させる期間を制限する
harden-referral-path	Off	On	キャッシュだけでなく、参照パスに沿った NS データも再チェックする

改修の仕組み

1. 短縮されたキャッシュウィンドウ：キャッシュされたアペックス NS RRset が有効期限を迎えると、直ちに次のルックアップ（TLD のネームサーバーなど）を開始し、新しいデリゲーションを探します。
2. 参照パスのハードニング：

   harden-referral-path

   を ON にすることで、レゾルバが下へ降りていく途中で出会う NS データを再チェックし、陳腐化した情報を盲目的に信頼しなくなります。

期待される効果

• ゴーストドメインを完全に不可能にするわけではありません。
• 欺くことができる期間を**「数日間」から「約 1 時間」**まで大幅に短縮します。

より重い選択肢は？

クロス・レゾルバ検証（1.1.1.1, 8.8.8.8 など）や専用ポーリングも検討しましたが、運用コスト（追加ロード、レート制限）を考慮し、まずは自社のレゾルバ強化で現実的なケースをカバーすることを選択しました。

これでは解決しないこと：限界について

DNS キャッシュが存在する理由には正当性があります（頻繁な修正による負荷低減など）。我々が能做到なのは、陳腐化期間を短くするだけです。

• 完全排除の難しさ：アペックス NS RRset が短縮されたウィンドウ内でも変化すれば、依然として逃れてしまう可能性があります。
• 他要因の影響：レジストリのプロパゲーションサイクルやオーソリタブホストの振る舞いなど、我々が制御できない要素もあります。
• 慎重な導入：

  harden-referral-path

  は実験的規格です。そのため、現在 DNSSEC 検証も併せ運用し、ログのみ記録する設定（許可モード）としています。顧客ドメインの署名トラブルを誤動作と勘違いしないよう配慮しています。

ログが安定した後、DNSSEC を強制モードへ切り替える予定です。

お客様へのお願い

もしお客様がレジストラレベルでドメインを所有していない上で、重要なサイトを運用されている場合は以下の対策を検討してください。

• アップタイム監視だけでは不十分
  • アップタイム監視：「サイトはアクセス可能か？」
  • DNS モニタリング：「DNS レイヤは健全か？」
  • 両方併用することで、どちらかが単独では検出できない問題（ゴーストドメインなど）を捉えることができます。

Oh Dear でできること

• DNS チェック機能：モニター単位で DNS モニタリングをオンにできます。
• 監視項目：A, AAAA, MX, NS, TXT レコードの変化を監視し、アラートを発します。
• メリット：追加オプションではなく、すべてのプランに無料で含まれています。

無料トライアル

まだ Oh Dear のお客様でない場合は、クレジットカード不要で 10 日間無料トライアルが可能です。

検出できていないエッジケースにお困りの場合は、是非ご教示ください。より良いツールの実現のために取り組んでまいります。