Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

Pending Nameserver Update のまま動かないゾーン

最終更新 Markdown で表示Agent セットアップ

ゾーンが Pending Nameserver Update のままになるのは、そのドメインが割り当て済みの Cloudflare ネームサーバーへ委任されていることを、Cloudflare が確認できないときです。

いちばん多い原因は、ネームサーバーの変更がレジストラで完全に公開されていないこと、ドメインが割り当て済みのネームサーバーと完全に一致していないこと、またはレジストラに残った古い DNSSEC レコードが委任を妨げていることです。

このページでは、確認する項目を順に説明し、レジストラの管理画面とは別に、各項目を検証する方法を示します。

ゾーンステータスの評価方法は、ゾーンステータス を参照してください。

1. 割り当てられた Cloudflare ネームサーバーを確認する

Cloudflare ダッシュボードでドメインを開き、Overview ページを表示します。このゾーンに Cloudflare が割り当てたネームサーバーの一覧を、すべてコピーします。ネームサーバーの数とホスト名の形式は、セットアップによって異なります。

セットアップ ネームサーバー数 ネームサーバー名の形式
標準の フルセットアップ 2 <proper_name>.ns.cloudflare.com
Foundation DNS高度なネームサーバー 3 <color>.foundationdns.com<color>.foundationdns.net<color>.foundationdns.org にそれぞれ 1 台ずつ — 3 つすべてをレジストラに設定する必要があります。
セカンダリ DNS としての Cloudflare 2 <proper_name>.secondary.cloudflare.com
カスタムネームサーバー 可変 独自のブランド名

どの形式であっても、ダッシュボードに表示されている値が、親ゾーンが公開すべき値です。別のドメインや別アカウントで以前使った割り当てと同じだと仮定しないでください。詳細は ネームサーバーの割り当て を参照してください。

2. 親ゾーンが実際に公開している内容を確認する

レジストラの管理画面に表示されるのは、レジストラへ 公開を依頼した 内容です。親ゾーン(TLD)がインターネットへ実際に返している内容ではありません。変更が保存されていない、まだ伝播していない、別ドメインに適用された、別のレジストラアカウントに適用された、といった場合に、両者は一致しません。

次のいずれかの方法で、親ゾーンを直接照会します。

方法 A - dig +trace

dig +trace は、ルートゾーンから委任をたどります。+noall +authority +nodnssec を付けると、各階層の委任セクションだけに出力が絞られ、親ゾーンがドメインをどこへ向けているかを確認しやすくなります。ターミナルで次を実行します。

dig +trace example.com NS +noall +authority +nodnssec
  • +trace — 単一の再帰リゾルバーへ問い合わせるのではなく、ルートネームサーバーからドメインまで、委任を段階的にたどります。
  • +noall +authority — 各ホップで返される AUTHORITY セクション以外を隠します。ここに、各親ゾーンが委任先として列挙するネームサーバーがあります。ドメインの直前に表示される最後のホップが親ゾーン(com.co.uk. など)で、その authority セクションが、ゾーンを実際に委任している内容です。
  • +nodnssec — DNSSEC 関連レコード(RRSIGNSECNSEC3、DNSKEY)を隠し、出力を読みやすくします。

出力の最後の空でないセクションは、ゾーンに割り当てられた Cloudflare ネームサーバーだけを返す必要があります(マルチプロバイダー DNS を使う場合は、他プロバイダーのネームサーバーと並んで含まれます)。

方法 B - nslookup

Windows を使っている場合、または nslookup の方がよい場合は、ドメインの NS レコードを照会します。-debug フラグを付けると、authority セクションを含む完全な応答を確認できます。ターミナルで次を実行します。

nslookup -type=ns -debug example.com

初期設定では、nslookup はシステムの構成済みリゾルバーへ問い合わせるため、キャッシュされた回答が返ることがあります。親ゾーンに対する確定的な確認(dig +trace と同等)をするには、最後の引数として TLD ネームサーバーを指定し、直接照会します。.com ドメインの場合は次のようになります。

nslookup -type=ns -debug example.com a.gtld-servers.net

他の TLD については、IANA のルートゾーンデータベース で、その TLD の権威ネームサーバーを確認してください。

出力に、Cloudflare ゾーンへ割り当てられたもの以外のネームサーバーが表示される場合、委任はまだ正しくありません。

方法 C - Web ベースの照会

手元に dignslookup がない場合は、公開の照会ツールを使います。

  • digwebinterface.com - Trace オプションを有効にすると、ルートゾーンから委任をたどります。dig +trace と同等です。
  • whatsmydns.net - 複数リージョンのリゾルバーから見た NS レコードを確認するのに便利です。

ドメインの NS レコードを照会します。結果は、Cloudflare ダッシュボードで割り当てられたネームサーバーと一致する必要があります。

結果に応じた対応

照会結果に応じた次の手順は、次の表を使って判断します。

親ゾーンでの結果 意味と対応
このゾーンに割り当てられた Cloudflare ネームサーバーと完全に一致する。 委任は正しいです。ダッシュボードがまだ Pending の場合は、Cloudflare の次の有効化チェックを待つか、API でトリガー します。その後、手順 4 へ進み、DNSSEC を確認します。
Cloudflare ネームサーバーだが、割り当て済みの名前とは異なる。 ドメインが別の Cloudflare アカウントに追加されているか、以前使っていたネームサーバーをレジストラに設定した可能性が高いです。このゾーンの Overview ページに表示されている値そのものをレジストラに設定してください。Foundation DNS の高度なネームサーバーでは、3 つすべての値が必要です。
別プロバイダーのネームサーバー。 レジストラが変更を公開していません。手順 3 へ進みます。
ネームサーバーが返されない。 ドメインはまだ委任されていません。登録直後であれば、親 TLD の伝播を待ってから(最大 24 時間)再テストします。
Cloudflare と他プロバイダーのネームサーバーが混在する。 マルチプロバイダー DNS を使うセットアップの場合にのみ有効です。そうでなければ、レジストラで Cloudflare 以外のレコードを削除します。

3. レジストラで変更が実際に保存されたかを確認する

親ゾーンが正しい Cloudflare ネームサーバーを返さない場合、レジストラは変更を公開していません。よくあるパターンは次のとおりです。

  • レジストラ UI でネームサーバー変更を入力したが、保存または送信していない。
  • 別ドメイン、サブドメイン、または別のレジストラアカウントで変更した。
  • ドメインが TransferRegistrar LockRedemption のいずれかの状態にあり、ネームサーバー変更ができない。先にその保留状態を完了またはキャンセルします。
  • レジストラが追加の確認手順を要求する(メール確認、管理者承認、二要素認証のプロンプト)。
  • レジストラが変更を遅延公開する。想定される伝播時間は、レジストラのサポートへ確認してください。
  • ドメインがリセラー管理で、ネームサーバー設定を一段上で変更する必要がある。レジストラでネームサーバーを更新する を参照してください。

レジストラ側の変更を直したら、手順 2 の確認を再実行します。

4. 古い DNSSEC DS レコードを確認する

手順 2 で親ゾーンに正しい Cloudflare ネームサーバーがあるのに、ゾーンがまだ Pending の場合は、以前の DNS プロバイダーの DNSSEC が残っていないかを確認します。

DS レコードは DNS プロバイダーではなくレジストラにあり、DNS プロバイダーを移すときは削除または更新する必要があります。そうしないと、DNSSEC の信頼チェーンが切れ、リゾルバーはドメインに対して SERVFAIL を返します。

DS レコードを確認するには、次を実行します。

dig DS example.com

DS レコードが返り、Cloudflare で意図的に DNSSEC を設定していない場合、それらは以前のプロバイダーの古いレコードであり、有効化を妨げます。

削除手順は次のとおりです。

  1. レジストラの管理画面にサインインします。
  2. DNSSEC 設定を探します(Advanced DNS または Security にあることが多いです)。
  3. 既存の DS レコードをすべて削除します。
  4. DNS キャッシュへの伝播を待ちます(最大 24 時間)。

古い DS レコードが削除され、キャッシュから消えると、Cloudflare ゾーンは自動で有効化されます。その後、必要に応じて Cloudflare で DNSSEC を有効 にできます。

DNSSEC の設定について詳しくは、DNSSEC を設定するDNSSEC のトラブルシューティング を参照してください。

5. ゾーンがまだ Pending の場合

手順 1〜4 がすべて問題なく、親ゾーンが正しい Cloudflare ネームサーバーを返している場合は、Cloudflare の次の有効化チェックを待ちます。チェック間隔は徐々に長くなります。

Overview ページから、または API でトリガー して、より早いチェックを依頼できます。このエンドポイントにはレート制限があり、最近チェックを依頼しているとエラーが返ることがあります。依頼が成功しても、ゾーンはすぐには有効化されません。優先キューに入り、再チェックの実行タイミングと、その時点でレジストラのネームサーバー変更が反映されているかの両方に応じて、数分から数時間かかることがあります。

親ゾーンが一致し、DS レコードも問題なく、何度か再チェックしてもゾーンが有効化されない場合は、Cloudflare サポートへ問い合わせ、次の情報を添えてください。

  • ドメイン名。
  • ダッシュボードで割り当てられた Cloudflare ネームサーバー。
  • dig +trace <YOUR_DOMAIN> NS の出力。
  • dig DS <YOUR_DOMAIN> の出力。
  • 利用中のレジストラ。

役に立ちましたか?