Cloudflareのネームサーバーはゾーンごとに違う｜19ドメイン分の設定をやり直した話

01 / 本文

結論：Cloudflareのネームサーバーは、ドメインごとに違う組が割り当てられる

Cloudflareにドメインを追加すると、そのゾーン専用のネームサーバーが2本渡される。この2本は、アカウント共通ではない。ゾーンごとに違う。

私のアカウントでは、次の2種類が混在していた。

anna.ns.cloudflare.com / luke.ns.cloudflare.com

dora.ns.cloudflare.com / joaquin.ns.cloudflare.com

最初に設定した数件が anna / luke だったので、それ以降に追加したドメインにも同じ値を入れていた。結果、dora / joaquin を要求するゾーンは、何時間経っても pending のままだった。

02 / 本文

何をしていたか

使っていないドメインが30件近くあった。取得したまま何も置いていない状態で、お名前.comの初期ページが表示されるだけになっていた。

これらを、運営している別のサイトの該当ページへ301転送することにした。Cloudflareを使えば、サーバーを用意せずに転送だけができる。手順はこうだ。

1. Cloudflareにドメインを追加する

2. Aレコードを 192.0.2.1 で作り、プロキシを有効にする

3. ページルールで、全アクセスを転送先へ301で飛ばす

4. お名前.comでネームサーバーをCloudflareのものに変更する

192.0.2.1 は、RFC 5737 で文書用として予約されているアドレスで、どこにも繋がらない。Cloudflareがリクエストを受け止めて転送するだけなので、その先にサーバーは要らない。

03 / 本文

症状：一部だけ通り、大半が pending のまま

最初の数件はすぐに active になった。ところが、その後に追加した分は何時間待っても pending から動かない。

DNSの浸透待ちだと考えて待った。半日経っても変わらなかった。

ここで、確認の方法が間違っていたことに気づく。DNSキャッシュを見ていたのでは、申請がレジストリに届いているのかどうかが分からない。登録原簿を直接見る必要がある。

04 / 本文

確認はwhoisとRDAPで、レジストリに直接聞く

TLDごとに問い合わせ先が違う。

.jp は JPRS の whois。ドメイン名のあとに /e を付けると英語で返る。

.net や .com は Verisign の whois。

.shop は2026年5月にwhoisが廃止され、RDAPに移行した。https://rdap.gmoregistry.net/rdap/domain/<ドメイン> を叩く。

見るべきは Name Server と、Last Updated（最終更新日時）だ。ネームサーバーを変更したのに Last Updated が動いていなければ、申請自体が届いていない。反映待ちではない。

# .jp
whois -h whois.jprs.jp 'example.jp/e' | grep -E 'Name Server|Last Updated'

# .net / .com
whois -h whois.verisign-grs.com example.net | grep -E 'Name Server|Updated Date'

# .shop（whois廃止、RDAP）
curl -H 'Accept: application/rdap+json' \n  https://rdap.gmoregistry.net/rdap/domain/example.shop

05 / 本文

分かったこと：値そのものが違っていた

whoisで見ると、こうなっていた。

設定されていた値：anna.ns.cloudflare.com / luke.ns.cloudflare.com

Cloudflareが要求する値：dora.ns.cloudflare.com / joaquin.ns.cloudflare.com

Last Updated は動いていたので、申請自体は通っていた。違う値で正しく登録されていたわけだ。だから何時間待っても active にならない。

念のため、ゾーンを削除して作り直してみた。割り当ては同じ dora / joaquin だった。ドメイン名から決まる固定値で、引き直すことはできない。

06 / 本文

正しい確認手順

Cloudflare API でゾーンの一覧を取ると、name_servers に必要な値が入っている。これとレジストリの登録値を突き合わせれば、一件ずつ目視しなくて済む。

ゾーンを作った直後に name_servers を控えておくのが確実だ。あとから一覧で引き直すこともできる。

curl -s -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \n  'https://api.cloudflare.com/client/v4/zones?per_page=50' \n  | jq -r '.result[] | "\(.name)	\(.status)	\(.name_servers | join("/"))"'

07 / 本文

activation_check で確認を早める

レジストリ側が正しくなっても、Cloudflareの判定はすぐには変わらない。定期的な確認を待つことになる。

activation_check を叩くと、その場で確認を走らせられる。それでも数分から数十分はかかる。

curl -s -X PUT \n  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \n  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/activation_check"

08 / 本文

もう一つ踏んだ罠：サブドメインのNSレコード

ネームサーバーを移したあと、www だけが古いサーバーを指し続けるドメインがあった。Aレコードは正しく Cloudflare を向いているのに、である。

原因は、www.example.jp に NSレコードが残っていたことだった。これは「wwwの管理は別のサーバーに任せる」という委任の指定で、Aレコードより優先される。

Cloudflareがドメインを取り込むときのスキャンで、旧DNSにあったNSレコードをそのまま持ってきていた。同じ理由で、dev や test などのサブドメインにもNSレコードが並んでいた。移行時は、これらを消す必要がある。

09 / 本文

まとめ

Cloudflareのネームサーバーはゾーンごとに違う。複数ドメインをまとめて設定するときに、同じ値を使い回してはいけない。

反映されないときは、DNSキャッシュではなくレジストリの登録原簿を見る。Last Updated が動いていなければ申請が届いておらず、動いていれば値が違う。

サブドメインにNSレコードが残っていると、Aレコードを設定しても効かない。移行時は消す。

この3点を最初から知っていれば、19件分のやり直しは避けられた。