last_modified: 2026-01-27

生成AIによる自動生成記事に関する免責事項: 本記事は、Webインフラストラクチャにおけるドメイン移行時の挙動に基づき、大規模言語モデルによって作成された解説記事です。記述内容はRFC標準（RFC 2308等）およびCloudflareの仕様に基づき正確性を期していますが、実運用における挙動は上位ISPや経路に依存します。

1. 序論：CNAME変更と過渡的な不達状態#

Webサービスの移行やプロジェクトの再構築において、既存のカスタムドメイン（FQDN）を一旦削除し、直後に新しいターゲットへ再登録する操作は頻繁に行われる。 論理的には、権威DNSサーバー（Authoritative Name Server）上のレコードを書き換えるだけの操作であるが、実際にはクライアント側で DNS_PROBE_POSSIBLE 等のエラーが観測され、接続が確立されるまでに数分から数時間の遅延が生じることがある。

本稿では、この現象の主因である「ネガティブキャッシュ」の挙動と、CDNエッジにおけるSSL/TLS終端処理のタイムラグについて詳述する。

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

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

DNSの基本原則として、フルリゾルバ（キャッシュサーバー）は権威サーバーから取得したAレコードやCNAMEレコードを、設定されたTTL（Time To Live）の期間だけ保持する。これにより、ルートサーバーへの負荷集中を防いでいる。 レコード変更時に古い接続先が参照され続ける「浸透待ち」は、この正引きキャッシュのTTL残存に起因する。

2.2 ネガティブキャッシュ（NXDOMAIN）の滞留#

ドメインの付け替え作業において、一時的にレコードが存在しない「空白の時間」が生じた場合、そのタイミングで発生したクエリに対して権威サーバーは「そのようなドメインは存在しない（NXDOMAIN）」という応答を返す。

RFC 2308で定義される通り、リゾルバはこの「不在である」という事実自体もキャッシュする。これを**ネガティブキャッシュ（Negative Cache）**と呼ぶ。 ネガティブキャッシュのTTLは、権威サーバーのSOAレコード（Start of Authority）内の MINIMUM フィールドによって制御される。

この機構により、ドメイン再登録が完了しても、ネガティブキャッシュの有効期限が切れるまでは、クライアントは「ドメインが存在しない」という誤った（しかしキャッシュ時点では正しかった）情報を参照し続けることになる。

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

DNS解決が正常に行われたとしても、HTTPS接続には以下の層での処理完了が必要となる。

3.1 エッジネットワークへの設定伝播#

Cloudflare Pages等のモダンなCDNホスティングでは、コントロールプレーン（管理画面）での設定変更が、世界中に分散したデータプレーン（エッジサーバー）へ伝播するのに物理的な時間を要する。DNSレコードが更新されても、エッジ側のルーティングテーブルに該当ドメインが登録されていなければ、リクエストは拒絶される（Error 522/523等）。

3.2 SSL/TLS証明書のプロビジョニング#

カスタムドメイン追加時、プラットフォームは自動的にDV（Domain Validation）証明書の発行プロセスを開始する。

1. ACMEチャレンジ: Let’s Encrypt等のCA（認証局）がドメイン所有権を検証。
2. 証明書発行: 署名済み証明書の生成。
3. 配布: エッジノードへの証明書デプロイ。

このプロセスにおいて、CA側のレートリミットやDNS検証の遅延が発生すると、ブラウザ側で ERR_SSL_VERSION_OR_CIPHER_MISMATCH が発生する場合がある。

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

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

4.1 サーバーサイド検証（Control Plane）#

まず、ホスティングプロバイダ（Cloudflare等）の管理画面におけるステータスを確認する。

• Status: Active: DNS検証および証明書発行が完了している。これ以降の問題はクライアントまたは中間経路に限定される。
• Status: Initializing / Verifying: CAによるドメイン検証待ち、または内部処理中である。ユーザー側で介入不能なため、待機が必要。

4.2 クライアントサイド検証（Local Environment）#

サーバー側が正常である場合、ローカル環境のキャッシュ汚染を除去する。

1. OSリゾルバキャッシュの破棄:
   • Windows: ipconfig /flushdns
   • macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. ブラウザキャッシュの破棄: Chrome等はOSとは独立したDNSキャッシュ（Async DNS）を持つ場合があるため、内部設定（chrome://net-internals/#dns）からクリアを行う。

4.3 外部リゾルバによるクロスチェック#

dig コマンド等を用い、ローカルISPのDNSを経由せず、権威サーバーへ直接問い合わせを行うことで、伝播状況を確定させる。

権威サーバーが正しいIPを返答している場合、接続不可の原因は100%「経路途中のキャッシュ」にあると断定できる。

5. 結論#

ドメイン再登録直後の接続エラーは、システムの不具合ではなく、DNSの分散アーキテクチャにおける整合性維持のための仕様（ネガティブキャッシュ）およびセキュリティ確保のためのプロセス（証明書発行）に起因する正常な挙動である。 技術的介入（キャッシュクリア等）により短縮可能なラグには限界があり、最終的な解決策は、TTLおよびプロビジョニング時間が経過するまで「待機」することに帰結する。

補遺：DNSクエリフローにおける障害点の特定#

ドメイン解決要求に対する応答パターンにより、障害箇所を以下のように特定できる。