ドメイン再登録時におけるDNS伝播遅延とネガティブキャッシュのメカニズム：DNS_PROBE_POSSIBLEの解析

1. 序論：過渡的状態における不達事象の定義#

Webサービスのホスティング移行や構成再作成において、FQDN（Fully Qualified Domain Name）のDNSレコードを削除し、短時間で再登録する操作を行った際、論理的には設定が完了していても、クライアント側で接続不可状態が継続する現象が確認される。

特にChromiumベースのユーザーエージェントにおいては、単純な NXDOMAIN ではなく DNS_PROBE_POSSIBLE という中間状態のエラーコードが観測されるケースが多い。本稿では、この事象を以下の3つの技術的要因の複合として定義し、そのメカニズムを詳述する。

DNSネガティブキャッシュ（RFC 2308）
Chromium DNS Probing（曖昧性解消ロジック）
SSL/TLSプロビジョニング遅延

2. 理論的背景：DNSにおけるキャッシュ構造とRFC 2308#

2.1 正引きキャッシュとTTL#

DNSフルリゾルバは、権威サーバー（Authoritative Name Server）から取得したリソースレコード（RR）を、当該レコードに設定されたTTL（Time To Live）秒間保持する。レコード更新時の「浸透待ち」は、下位リゾルバにおけるTTL残存に起因する。

2.2 ネガティブキャッシュ（Negative Cache）#

ドメイン削除直後に発生したクエリに対し、権威サーバーは「ドメイン不在（NXDOMAIN）」または「レコード不在（NODATA）」を応答する。RFC 2308の定義に従い、リゾルバはこの「不在である事実」自体をキャッシュする。

ネガティブキャッシュの保持期間（ $TTL_{neg}$ ）は、権威サーバーのSOAレコード（Start of Authority）に含まれる MINIMUM フィールドの値、またはリゾルバの実装上限（通常900秒〜3600秒）のいずれか小さい方に制約される。

TTL_{neg} = \min(\text{SOA.MINIMUM}, \text{Resolver Policy})

この機構により、権威サーバー側でレコードが復旧しても、 $TTL_{neg}$ が経過するまではリゾルバレベルで NXDOMAIN が返却され続ける。

3. クライアントサイドの挙動解析#

3.1 DNS_PROBE_POSSIBLE の発生機序#

Chromium系ブラウザにおいて DNS_PROBE_POSSIBLE は、DNS解決の失敗が「ドメインの不在」によるものか、「ネットワーク経路の障害」によるものかを判別できない状態を示す。

Initial Query: ブラウザがシステムリゾルバ経由でクエリを発行。
Failure / Timeout: リゾルバが応答しない、または信頼できない応答（SERVFAIL等）を返す。あるいは、ネガティブキャッシュと新規レコードの伝播状況が経路上のDNSサーバー間で不整合を起こしている場合。
Probing: ブラウザはパブリックDNS（8.8.8.8等）への直接問い合わせや、ネットワーク接続性の確認（Probe）を開始する。この調査期間中に表示されるプレースホルダーが DNS_PROBE_POSSIBLE である。

3.2 状態遷移#

ドメイン再登録後のクライアント状態は、時間経過 $t$ と共に以下のように遷移する。

フェーズ	エラーコード	技術的状態
$t < t_0$	DNS_PROBE_FINISHED_NXDOMAIN	ネガティブキャッシュが支配的。ドメインは「存在しない」と確定されている。
$t \approx t_0$	DNS_PROBE_POSSIBLE	キャッシュの有効期限切れ前後。リゾルバ間で応答が揺れており、ブラウザが確証を持てない状態。
$t > t_0$	ERR_SSL_VERSION_OR_CIPHER_MISMATCH	DNS解決は成功（IP到達可）。エッジでのSSL証明書配布待ち。
$t_{final}$	HTTP 200 OK	全レイヤーでの伝播完了。

4. インフラストラクチャ層での遅延要因#

4.1 エッジ・コンバージェンス#

Cloudflare Pages等のCDNホスティングにおいて、コントロールプレーン（API/Dashboard）での設定変更は即時完了するが、データプレーン（Edge Server）への設定反映には物理的な伝播遅延を伴う。DNSレコードが解決できても、エッジのルーティングテーブルが更新されていない場合、HTTP 522/523 エラーが発生する。

4.2 証明書発行の競合状態 (Race Condition)#

カスタムドメイン設定時、プラットフォームはACMEプロトコルを用いてDV（Domain Validation）証明書を発行する。このプロセスにはDNS検証が含まれるため、DNS伝播が完了していない段階では証明書発行も失敗・遅延する。

デッドロック: 証明書発行のためにDNS解決が必要だが、DNS解決後の接続には証明書が必要となる（HSTS環境下等）。
エラー: ブラウザはIPアドレスに到達するが、TLSハンドシェイクで有効な証明書が提示されないため、ERR_SSL_PROTOCOL_ERROR 等を送出する。

5. トラブルシューティング仕様#

接続障害時における、問題の切り分けと解決手順を以下に定義する。

5.1 診断マトリクス#

観測事象	障害レイヤー	判定根拠	推奨アクション
NXDOMAIN	DNS (Cache)	上位リゾルバが「不在」をキャッシュ中	待機のみ（介入不可）
DNS_PROBE_POSSIBLE	DNS (Inconsistent)	経路上のDNSサーバー間で情報が不整合	`flushdns` 試行、待機
SSL_ERROR / Mismatch	Application (SSL)	IP到達済。証明書未配布	Cloudflareステータス確認
Error 522 / 523	Origin / Edge	DNS解決済。エッジ設定未反映	ホスティング設定確認

5.2 検証コマンド#

外部リゾルバ（Google Public DNS等）を用いて、権威サーバーの現在の状態を直接確認する。

# 権威サーバーの応答確認（キャッシュをバイパス）
dig @ns.cloudflare.com example.com

# 伝播状況の確認（Google DNS経由）
dig @8.8.8.8 example.com
前者が正しく、後者が NXDOMAIN を返す場合、問題は100%「経路途中のネガティブキャッシュ」に局所化される。

6. 結論#

ドメイン再登録直後の接続エラーは、分散システムにおけるデータ整合性モデル（Eventual Consistency）に起因する不可避な挙動である。特に DNS_PROBE_POSSIBLE は、ネガティブキャッシュの消滅と新規レコードの伝播が交錯する過渡期におけるChromium固有の診断状態を示しており、設定不備を示すものではない。技術的介入（キャッシュクリア等）による短縮効果は限定的であり、TTLおよびSSLプロビジョニング時間が経過するまでの待機が唯一の確定的な解決策となる。