ブログ一覧

DNS が古い環境からドメイン切り替え直後のサイトを検証する — DoH と curl --connect-to

Web開発者向け

サイトのドメインを新しいホスティング（例: Cloudflare Workers のカスタムドメイン）へ切り替えた直後、「ちゃんと新しい方に向いたか」を確認したいのに、手元の環境の DNS が古い IP を返し続けて検証にならないことがあります。

  • curl https://example.com/ が旧サーバーのレスポンスを返し続ける（cf-ray ヘッダーがない、server: nginx など切り替え前の顔）
  • dig は外部 DNS（ポート 53）がブロックされていて使えない、あるいはキャッシュされた古い結果を返す
  • ブラウザで見られる環境なら確認できるが、CI・コンテナ・プロキシ配下ではそれもできない

Docker コンテナやプロキシ経由の開発環境で特に起きやすい状況です。本記事では、DoH（DNS over HTTPS）で本物の最新 DNS を引き、`curl --connect-to` で名前解決を上書きして検証する手順をまとめます。

前提: HTTPS の外向き通信（443 番）は通る環境を想定しています。例は Cloudflare への切り替えですが、任意の移転先で使えます。

手順1: DoH で「今の本当の」IP を引く

ポート 53 の DNS がブロックされていても、DoH は ただの HTTPS リクエストなので通ります。Google Public DNS の JSON API が手軽です。

curl -s "https://dns.google/resolve?name=example.com&type=A"
{
	"Status": 0,
	"Answer": [
		{ "name": "example.com.", "type": 1, "TTL": 300, "data": "104.21.x.x" }
	]
}

これで、ローカルのキャッシュやプロキシに汚染されていない権威側の現在値が取れます。Cloudflare に切り替えたなら、Cloudflare の IP レンジ（104.21.x.x など）が返ってくるはずです。

ここで返る値と手元の名前解決（getent hosts example.com 等）がズレていれば、「切り替えは済んでいるのに手元のリゾルバが古い」ことが確定します。手元の DNS を疑う根拠がまずこれで得られます。

手順2: curl --connect-to で名前解決を上書きして接続する

DoH で得た IP へ、ドメイン名の文脈（SNI・Host ヘッダー・証明書検証）を保ったまま接続します。

curl -sv --connect-to example.com:443:104.21.x.x:443 https://example.com/ -o /dev/null

--connect-to は「example.com:443 への接続を 104.21.x.x:443 に差し替える」オプションです。URL は本物のドメインのままなので、TLS の SNI も証明書検証も Host ヘッダーも本番同様に行われます。似たオプションの --resolve example.com:443:104.21.x.x でも同じことができます。

/etc/hosts を書き換える方法と違い、コマンド単発で済み、書き戻し忘れの事故もありません。

手順3: 「新しい方に着いた」ことをヘッダーで確認する

レスポンスが 200 ならOK、ではありません。どちらのサーバーが返したのかを確認します。Cloudflare 配下なら見るべきは:

< cf-ray: 8xxxxxxxxxxx-NRT
< server: cloudflare

cf-ray は Cloudflare を通ったリクエストに必ず付くヘッダーです。切り替え前のサーバー（server: nginx 等で cf-ray なし）との区別がこれで付きます。あとは主要ページ・サイトマップ・リダイレクトを同じ要領で叩けば、手元の DNS が腐っていても切り替えの検証が完了します。

切り替え直後の「エラーに見えて正常」な現象

この検証中に遭遇しがちな、対処不要の現象を 2 つ挙げておきます。

TLS ハンドシェイクが数分間失敗する

切り替え直後に ERR_SSL_VERSION_OR_CIPHER_MISMATCH（curl だと TLS ハンドシェイク失敗）が出ることがあります。これは新ホスト側の証明書の発行・配備が完了するまでの窓で、Cloudflare のカスタムドメインなら数分で自然に解消します。この窓の間に設定を疑っていじり回すと、むしろ壊します。数分待ってから再検証が正解です。

旧 URL（workers.dev など）が 404 になる

Cloudflare Workers の場合、カスタムドメインをバインドすると workers.dev 側の URL は 404 を返すようになります。これは仕様（ルーティングがカスタムドメインへ移る）で、壊れたわけではありません。

ドメイン切り替えには DNS 以外の罠もあります。特に管理画面の認証がパスキーの場合は切り替え前に読んでおいてください: 「パスキーはドメインに縛られる — 独自ドメイン移行で管理者ログインできなくなる理由と対策」。

まとめ

  • 手元の DNS が古くても、DoH（`https://dns.google/resolve`）は HTTPS なので通り、権威側の現在値が引ける
  • curl --connect-to <host>:443:<実IP>:443 で名前解決だけ上書きし、SNI・証明書・Host は本番同様のまま検証できる
  • 到達確認は 200 だけでなく `cf-ray` などのヘッダーで「どちらのサーバーか」を見る
  • 切り替え直後の TLS エラー（証明書配備待ち）と workers.dev の 404 は正常。待つ・気にしないが正解

参考リンク

ブログ一覧