Azure Front DoorでApexドメインのTXT検証が通らない原因とCloudflare＋Azure DNS構成での解決手順

Azure Front Door で apex（ルート）ドメインのカスタムドメインを登録しようとしたとき、「TXT 検証がいつまで経っても通らない」「Failed provisioning で止まる」といったトラブルは珍しくありません。この記事では Cloudflare＋Azure DNS のようなハイブリッド構成で実際に起きたケースをもとに、原因と解決手順を実務目線で整理します。

Azure Front DoorでApexドメインが検証できない典型パターン

シナリオの例として、次のような状況を想定します。

• Azure Front Door（以下 AFD）で calquakemap.com をカスタムドメインとして登録したい
• 検証方法は TXT レコード方式
• AFD ポータルでは _dnsauth.calquakemap.com の TXT レコードを作成するよう指示されている
• 一方、ドキュメントでは _dnsauth という表記もあり混乱
• Azure DNS に _dnsauth と _dnsauth.calquakemap.com の両方を作成したが、dig で TXT が引けない
• サブドメイン（例：www.calquakemap.com）は検証済みだが、一部で「Failed provisioning」と表示される

このようなとき、多くの人は次のようなポイントを疑います。

• TXT レコード名の書き方が違う？（_dnsauth / _dnsauth.calquakemap.com）
• TXT の値（トークン）をコピペミスした？
• AFD 側のバグ？反映待ち？

しかし、実際の原因はもっと根本的でシンプルです。

結論：編集していた DNS ゾーンが「権威 DNS」ではなかった — つまり、インターネットから見たときに、その DNS ゾーンは全く参照されていませんでした。

症状の整理

症状	具体的な状況
TXT 検証が通らない	ポータル上は「検証待ち」のまま、数時間たっても変化なし
dig で TXT が引けない	dig TXT _dnsauth.calquakemap.com +short を実行しても応答が空
サブドメインは問題なく検証済み	www.calquakemap.com などは AFD に正しく紐づいている
一部カスタムドメインが「Failed provisioning」	証明書の発行やバインドが途中で止まっているように見える

真の原因：権威DNSではないゾーンにTXTを作っていた

今回のケースでは、次のような構成になっていました。

• Apex ドメイン（calquakemap.com）の NS は Cloudflare を指している
• 一部サブドメイン（例：www.calquakemap.com）だけが Azure DNS に委任されている
• しかし実務担当者は「Azure DNS に calquakemap.com ゾーンを作成しているから、ここを編集すればよい」と思い込んでいた

その結果、世界中の DNS クライアントは Cloudflare から回答を受け取る一方で、Azure DNS に作成した TXT レコードは誰にも参照されない「孤立ゾーン」になっていました。

AFD が TXT 検証を行うときに参照するのは、もちろんインターネット上の権威 DNS です。したがって、Cloudflare 上に TXT がない限り、検証は永遠に成功しません。

権威DNSとは何か（かんたん再確認）

権威DNS（オーソリタティブ DNS）は、次のように理解すると分かりやすくなります。

• インターネット上で「最終回答」を返す DNS サーバー
• レジストラ（お名前.com, Route53 など）に登録された NS レコードが指している先
• そこに存在しないレコードは、いくら他の場所に作っても外からは見えない

つまり、「Azure DNS にゾーンがある」ことと「Azure DNS が権威 DNS である」ことは全く別物です。レジストラの NS が Cloudflare を指しているなら、Cloudflare こそが権威 DNS になります。

apexとサブドメインで権威DNSが分かれる構成

次のような NS 構成は、CDN やマルチクラウド構成でよく見られます。

名前	タイプ	値（NS）	権威DNS
calquakemap.com	NS	ns1.cloudflare.com. ns2.cloudflare.com.	Cloudflare
www.calquakemap.com	NS	ns1-01.azure-dns.com. ns2-01.azure-dns.net. …	Azure DNS

この場合、

• calquakemap.com や _dnsauth.calquakemap.com は Cloudflare が権威
• www.calquakemap.com や _dnsauth.www.calquakemap.com は Azure DNS が権威

となるため、apex 用の TXT を Azure DNS に置いても AFD からは見えない、ということになります。

実務での解決手順（再現性重視）

1. まず「どこが権威DNSか」を確定する

最初にやるべきは、設定画面を開くことではなく dig による NS の確認です。

# apex の権威 NS を確認
dig NS calquakemap.com +short

# サブドメインごとの権威 NS を確認
dig NS www.calquakemap.com +short
dig NS api.calquakemap.com +short

ここで、例えば次のような結果になるかもしれません。

$ dig NS calquakemap.com +short
ns1.cloudflare.com.
ns2.cloudflare.com.

$ dig NS www.calquakemap.com +short
ns1-01.azure-dns.com.
ns2-01.azure-dns.net.
ns3-01.azure-dns.org.
ns4-01.azure-dns.info.

この結果から分かることは次の通りです。

• apex（calquakemap.com）の権威 DNS は Cloudflare
• www.calquakemap.com は Azure DNS に委任されている

つまり、AFD から見て apex の TXT を確認するときは、Cloudflare だけが参照されます。Azure DNS にどれだけレコードを追加しても無意味です。

2. TXT 検証レコードを「権威DNS」に作る

AFD ポータルから TXT 検証を選ぶと、だいたい次のような情報が表示されます。

• ホスト名（名前）：_dnsauth.calquakemap.com
• タイプ：TXT
• 値：ランダムなトークン（例：7J2kp3...）

これを、apex の権威 DNS（今回なら Cloudflare）に登録します。

多くの DNS 管理画面では、ゾーン名は自動で付与されるため、次のように入力します。

項目	入力内容（例）	最終的な FQDN
タイプ	TXT	–
名前	_dnsauth	_dnsauth.calquakemap.com
値	7J2kp3...（AFD発行のトークン）	–
TTL	300 ～ 3600 秒程度	–

Cloudflare や他の DNS サービスでは、「名前」にゾーン名を含めず _dnsauth だけを入れるのが一般的です。UI 上で _dnsauth.calquakemap.com とフルで入れると、かえって意図しない FQDN になるケースもあるので注意しましょう。

ポイント：ドキュメント上で _dnsauth とだけ書かれているのは、「ゾーン相対名で入力しますよ」という意味であって、最終的に公開されるレコードは _dnsauth.<apexドメイン> になります。ポータル側はユーザーに分かりやすく FQDN で表示しているだけです。

3. トラフィック向けの名前解決も同じ権威DNSで設定

TXT 検証が通ったら、次に「実際のトラフィックをどこへ流すのか」を DNS で設定します。選択肢はいくつかあります。

パターンA：Cloudflareを権威DNSのまま使う

• apex：calquakemap.com → AFD のエンドポイントへ CNAME（フラットニング）
• サブドメイン：必要に応じて CNAME や A レコードを設定

例えば、次のようなレコードを Cloudflare 上に作成します。

名前	タイプ	値	備考
calquakemap.com	CNAME（フラットニング）	<your-afd-endpoint>.z01.azurefd.net	Cloudflare の CNAME フラットニング機能を利用
_dnsauth	TXT	AFD のトークン	前述の検証用レコード

このとき、CNAME 検証（afdverify.<domain>）を使う場合は、「プロキシ無効（DNS only）」にすることが重要です。Cloudflare のオレンジクラウドが有効だと、AFD から CNAME を正しくたどれないことがあります。

TXT 検証（_dnsauth）は基本的にプロキシの影響を受けませんが、運用上混乱しそうな場合は一時的に DNS only にしておくとトラブルシュートがしやすくなります。

パターンB：Azure DNS を権威DNSに切り替える

もし Azure 側で DNS を統一したい場合は、

1. レジストラの NS を Azure DNS の NS に変更
2. Azure DNS のゾーンに TXT（_dnsauth）、CNAME/ALIAS を作成

という手順になります。この場合は、Cloudflare 側のレコードは最終的に不要です。ただし、NS の切り替えは全世界に伝播するまで最大 48 時間程度かかることがあるため、サービス影響が出ないように慎重に計画しましょう。

4. DNS反映の確認

レコードを作成したら、必ずクライアント側（ローカル PC など）から dig で確認します。

# TXT レコードが正しく見えるか
dig TXT _dnsauth.calquakemap.com +short

# CNAME 検証を使っている場合
dig CNAME afdverify.calquakemap.com +short

ここで、

• TXT の値として AFD が発行したトークンが見えている
• CNAME が <afd-verify-endpoint>.azurefd.net のような値を返している

ことを確認します。もし何も返ってこない場合は、

• 権威 DNS を間違えていないか
• TTL のせいで古い情報がキャッシュされていないか
• ローカル DNS キャッシュが残っていないか

を順番に疑いましょう。場合によっては +trace オプションを使うと、どこで解決が止まっているかが見えてきます。

dig TXT _dnsauth.calquakemap.com +trace

5. Azure Front Door ポータルでの「Revalidate」

DNS 側の準備が整ったら、AFD ポータルに戻ってカスタムドメインの画面から Revalidate（再検証） を実行します。

• TXT 検証の場合：TXT レコードを見に行き、トークンが一致すれば検証成功
• CNAME 検証の場合：CNAME をたどって AFD のエンドポイントに正しく向いているかを確認

もし、前回発行したトークンから時間が経っている場合は、トークンを再発行して TXT を更新 → 再度 Revalidate する、という手順を踏むと成功しやすくなります。

Cloudflare＋Azure DNSハイブリッド構成での具体例

ここで、最初のシナリオをもう少し具体的に整理してみます。

想定構成

• レジストラの NS：Cloudflare の NS を設定
• apex：Cloudflare が権威 DNS
• www.calquakemap.com：NS を Azure DNS に委任
• AFD：calquakemap.com と www.calquakemap.com をカスタムドメインとして追加したい

このときの「レコードの正しい置き場所」は次のようになります。

用途	レコード名	置き場所	備考
apex の TXT 検証	_dnsauth.calquakemap.com	Cloudflare	AFD から apex を検証するため
apex のトラフィック向け CNAME	calquakemap.com	Cloudflare	フラットニングで AFD へ転送
www の TXT 検証	_dnsauth.www.calquakemap.com	Azure DNS	www のカスタムドメイン検証用
www の CNAME	www.calquakemap.com	Azure DNS	通常の CNAME または ALIAS で AFD へ転送

このように、apex とサブドメインで「どの DNSに何を作るか」を明確に分けて考えることが重要です。すべてを Azure に寄せたい場合でも、移行中は一時的にハイブリッド状態になることが多いので、構成図や表にして整理しておくとトラブルを防げます。

「Failed provisioning」の対処方法

AFD のカスタムドメイン一覧で、ステータスが Failed provisioning になってしまうことがあります。これは多くの場合、

• 検証は通ったが、証明書の自動発行が途中で失敗した
• DNS の変更と証明書発行のタイミングが噛み合わず、内部状態が中途半端になっている

といった状況です。対処の流れは次のようになります。

1. DNS が本当に正しいか再確認

• _dnsauth.<domain> の TXT が正しく引けるか
• 必要に応じて CNAME（afdverify.<domain>）も確認
• Cloudflare のプロキシ設定が邪魔していないか

2. Revalidate を実行

DNS 設定が正しいと確信できたら、AFD 側で Revalidate（再検証）を実行します。これで正常系に戻るケースが多いです。

3. それでもダメな場合は「削除 → 再追加」

内部状態が壊れている場合、次の手順が有効です。

1. 問題のカスタムドメイン設定を一度削除
2. 数分待ってから、同じドメインを改めて追加
3. 新しく発行された TXT / CNAME 情報で DNS を更新
4. 改めて Revalidate を実行

このとき、古い _dnsauth や afdverify が複数残っていないかも確認しておきましょう。古いトークンが残っていると、どの値が正しいのか分からなくなりがちです。

よくあるつまずきポイントチェックリスト

実務でハマりやすいポイントをチェックリストとして整理しておきます。トラブル時には上から順番に潰していくと効率的です。

• NS が実際にどこを向いているか確認したか？（apex とサブドメインで異なっていないか）
• TXT の名前は _dnsauth.<apexドメイン> になっているか？（ゾーン相対名か FQDN かを理解して入力したか）
• TXT の値をコピペミスしていないか？（余計な空白・改行・全角文字はないか）
• CNAME 検証を使うなら、Cloudflare 等のプロキシを一時的に OFF（DNS only）にしたか？
• AFD 側で Revalidate やトークン再発行を実行したか？
• 古い _dnsauth / afdverify が複数残っていないか？
• ローカルや中間の DNS キャッシュをクリアして再確認したか？

用語の整理：Apexドメイン・権威DNS・フラットニング

Apexドメイン（ルートドメイン）

Apex ドメインは「ゾーンの頂点」のことで、例えば example.com 自体を指します。www.example.com や api.example.com はサブドメインです。

多くの DNS 実装では、apex には CNAME を直接置けないため、Cloudflare のようなサービスが「CNAME フラットニング」や「ALIAS レコード」といった仕組みを提供しています。

権威DNS（オーソリタティブDNS）

権威 DNSは、インターネットに対して最終回答を返す DNS です。レジストラに登録されている NS レコードが指している先が権威 DNS になります。

• 権威 DNS 以外に作ったレコードは、基本的に外部から見えない
• 「社内の開発用 DNS にだけ置いたレコード」も権威 DNS ではない
• Azure DNS にゾーンを作成しても、NS を向けていなければ権威ではない

AFD の TXT 検証・CNAME 検証は、この権威 DNS に対して行われます。

フラットニング（CNAMEフラットニング / ALIAS）

フラットニングとは、apex に CNAME を配置できない制約を DNS プロバイダー側で吸収する仕組みです。

• ユーザーは DNS 画面上で CNAME のように設定
• 実際には A / AAAA レコードに変換して応答
• Cloudflare の「CNAME フラットニング」、Route 53 の「ALIAS」などが代表例

AFD のような CDN を apex で使う場合、この仕組みを利用するか、Azure DNS の ALIAS レコードを使うことが多くなります。

再発防止のための設計・運用のコツ

最後に、同じようなトラブルを防ぐための設計・運用のポイントをいくつか挙げます。

DNS構成を図や表で必ず共有する

口頭やチャットだけで DNS 構成を共有していると、「ここが権威だと思っていた」系の勘違いが頻発します。最低限、次の情報はチームで共有しておきましょう。

• ドメインごとのレジストラ
• apex の NS が指す先（Cloudflare / Azure DNS / Route 53 など）
• サブドメイン単位で NS 委任している箇所
• 各サブドメインの用途（AFD、App Service、別クラウドなど）

これを図やスプレッドシートにしておくと、新しいメンバーが入ったときも状況を理解しやすくなります。

「まず dig」をチームの文化にする

DNS 周りでトラブルが起きたら、GUI を開く前に dig（または nslookup）を使う癖をつけると、原因特定が圧倒的に早くなります。

• apex の NS を確認する：dig NS example.com +short
• TXT / CNAME を確認する：dig TXT _dnsauth.example.com +short
• 権威までの経路を見る：dig example.com +trace

この「まず dig」を習慣化しておくと、「そもそも見ている DNS が違う」という今回のような事故をかなり防げます。

IaC（Infrastructure as Code）で DNS を管理する

可能であれば、DNS レコードも Terraform や Bicep などでコード管理することをおすすめします。

• どのドメインに、どの DNS サービスを使っているかがコードで明確になる
• レビューで「ここ、権威 DNS 違わない？」と気づきやすくなる
• 本番・検証・開発環境の差分も管理しやすい

特にマルチクラウドやハイブリッド構成では、手作業での DNS 管理はヒューマンエラーの温床になりがちです。

まとめ：未検証の主因は「間違ったDNSにレコードを置いた」こと

Azure Front Door で apex ドメインの TXT 検証が通らない場合、

• TXT 名の書き方ミス
• コピペミス
• 反映待ち

といった要因ももちろんありますが、実務で特に多いのは、

「権威 DNS ではない側に TXT / CNAME を作っていた」

という構成上の問題です。

今回のように apex が Cloudflare、サブドメインが Azure DNS といった構成は決して珍しくありません。そのため、AFD にカスタムドメインを追加するときは、

• 最初に dig NS <domain> +short で権威 DNS を必ず確認する
• 検証用 TXT（_dnsauth.<apex>）とトラフィック用 CNAME/ALIAS を、必ず権威 DNS 側に作成する
• DNS 反映を dig で確認したうえで、AFD 側の Revalidate を行う

という基本ステップを守るだけで、多くのトラブルを未然に防げます。

「AFD のバグかな？」と疑う前に、「そもそもどこが権威 DNS なのか」を疑う。これをチームの共通認識としておけば、今後 Azure Front Door で apex ドメインを扱う際も、よりスムーズに安全な運用ができるはずです。