Azure Front Door Premiumでワイルドカードドメイン（例：*.example.com）を検証して運用しているのに、追加したサブドメイン（例：poc.example.com）がいつまでもPendingのまま…という事例があります。本記事では原因と正しい検証手順、ハマりどころ、運用のコツをまとめます。
現象：ワイルドカードは検証済みなのに、追加サブドメインだけ「Pending」から進まない
Azure Front Door Premiumのプロファイルで、すでにワイルドカードのカスタムドメインを追加している状態を想定します。
| 項目 | 状況（例） | 補足 |
|---|---|---|
| 追加済みカスタムドメイン | *.example.com | TXT（_dnsauth.example.com）で検証済み |
| DNS（ルーティング） | *.example.com → <your-frontdoor-endpoint>.azurefd.net | CNAMEでFront Doorへ向けている |
| 証明書 | Azure マネージド証明書 | HTTPSアクセスも正常 |
| 追加したいサブドメイン | poc.example.com | Front Doorに「カスタムドメイン」として追加 |
| 困っていること | ドメイン状態がずっと「Pending」 | TXTやCNAME、表記ゆれ、DNS伝播は確認済み |
ドキュメント（または解説記事）で「既に検証済みのワイルドカード配下のサブドメインは自動承認される」と読める記載があると、追加したサブドメインも自動でValidatedになるはずと期待してしまいます。しかし実務では、この期待どおりに進まず、いつまでもPendingから動かないケースがあります。
まず押さえる：Front Doorの「ドメイン検証」は何を見ているのか
Azure Front Door（Standard/Premium）のカスタムドメインでは、主に次の2つが混同されがちです。
- ドメイン検証（Domain validation）：そのドメイン（ホスト名）を追加してよい所有者かどうかを、DNSのTXTレコードで確認する
- 名前解決（DNSルーティング）：そのドメインでアクセスされたときにFront Doorへ到達するよう、CNAME（またはDNSプロバイダーの相当機能）で向ける
「ワイルドカードの検証が済んでいる」ことは重要ですが、それはあくまでFront Doorに登録した“そのカスタムドメイン”が検証済みという意味です。Front Doorの構成上、*.example.comとpoc.example.comは別のカスタムドメインとして扱われます。ここが今回の落とし穴です。
結論：ワイルドカード検証だけでは、サブドメインは自動承認されない
実際にMicrosoftサポートへ確認した事例では、次の回答が得られました。
*.example.comが検証済みであっても、poc.example.comのようなサブドメインを追加した場合はサブドメインごとにTXTレコードでの検証が必要- 「ワイルドカード配下のサブドメインは自動的に検証承認される」と読める説明は、少なくともこの事例の時点では実際の挙動と一致しない
つまり、Pendingが解消しない原因はDNSのミスというより、期待値（自動承認）と仕様（個別検証）がズレていることにあります。検証済みワイルドカードがあるからといって、サブドメイン側の検証ステップが省略されるわけではありません。
サブドメインを確実に「Validated」にする手順
ここからは、poc.example.comを例に、Pendingを抜けてValidatedへ進める実務手順を整理します。ポイントは「Front Doorが要求してくるTXTレコードを、そのまま正確にDNSへ登録する」ことです。
手順
- Azureポータルで、対象のFront Doorプロファイルを開き、カスタムドメインから
poc.example.comを追加します。 - 追加ウィザードや作成後の画面で案内されるTXTレコード名と値を控えます（多くの場合、ホスト名は
_dnsauth.poc.example.comの形式です）。 - 利用中のDNS（Azure DNSでも外部DNSでも可）に、案内どおりのTXTレコードを登録します。
- 同時に、
poc.example.comがFront Doorエンドポイント（<your-frontdoor-endpoint>.azurefd.net）を向くようにCNAMEを確認します。すでに*.example.comのワイルドカードCNAMEがある場合でも、Front Door側が正しく参照できるかは別なので、実際に引けることを確認します。 - DNSの反映（TTL、権威DNS、地域差）を待ちます。反映には数分で済むこともあれば、環境によっては最大24時間程度かかることがあります。
dnschecker.orgやdigwebinterface.comなどで、複数地域から以下が引けることを確認します。_dnsauth.poc.example.comのTXTレコードpoc.example.comのCNAME（または同等の解決結果）
- Azureポータルに戻ると、Front DoorがDNSを再チェックして、ドメイン状態がPending → Validatedへ変わります。
- それでもPendingのままなら、Microsoftサポートへ問い合わせ、バックエンド側の検証状態やログの確認、必要であれば手動検証の依頼を行います。
ワイルドカードとサブドメインで、必要なDNSレコードはこう違う
| 対象 | 検証（TXT） | ルーティング（CNAME） | よくある勘違い |
|---|---|---|---|
ワイルドカード*.example.com | _dnsauth.example.com に指定値 | *.example.com → <endpoint>.azurefd.net | 「これで配下が全部OK」と思いがち |
個別サブドメインpoc.example.com | _dnsauth.poc.example.com に指定値（個別） | poc.example.com → <endpoint>.azurefd.net | TXTが_dnsauth.example.comのままになりがち |
重要なのは、TXTレコードのホスト名がワイルドカード用とサブドメイン用で異なる点です。ワイルドカードの検証が済んでいる状態でも、poc.example.comを追加した瞬間にFront Doorは「このホスト名の所有確認」を新たに求めるため、_dnsauth.poc.example.com側のTXTがないとPendingが継続します。
Pendingから抜けないときのチェックリスト
「TXTもCNAMEも入れたのにValidatedにならない」場合は、“レコードは存在する”と“Front Doorが要求した形で参照できる”の間でズレていることがほとんどです。現場で効くチェックポイントを優先度順にまとめます。
最優先で確認したいポイント
| チェック項目 | ありがちなNG例 | 対処の方向性 |
|---|---|---|
| TXTのホスト名 | _dnsauth.example.comのまま | _dnsauth.poc.example.comなど、Front Doorが提示したホスト名に合わせる |
| TXTの値 | 前回の検証値が残っている／コピー時に余計な空白や引用符が入る | Azureポータルで提示された値をそのまま貼り付ける（前後の空白も含めて排除） |
| レコードを置くDNSゾーン | 委任先が別ゾーンなのに親ゾーンへ追加している | 権威DNSがどこかを確認し、正しいゾーンに登録する |
| CNAMEの向き | 別のFront Door／別のCDN／古いエンドポイントへ向いている | 実際に解決されたCNAME先が正しいazurefd.netになっているか確認 |
| DNS伝播（地域差） | 自分の環境では引けるが、海外リージョンでは引けない | 複数の外部チェックで確認し、TTLを短くして待つ |
「ゾーン分割（委任）」がある環境は特に注意
企業環境では、サブドメインを別チームが管理するためにDNSゾーンを分割していることがあります。たとえば、poc.example.comを別のDNSゾーンとして委任している場合、TXTレコードの作り方（入力する“名前”）が管理画面上で変わります。
| DNSゾーン | 追加すべきTXTのFQDN | DNS管理画面での「名前」欄（例） | 起きやすいミス |
|---|---|---|---|
example.com | _dnsauth.poc.example.com | _dnsauth.poc（画面仕様により異なる） | _dnsauthだけ入れてしまい、_dnsauth.example.comに作ってしまう |
poc.example.com（別ゾーン） | _dnsauth.poc.example.com | _dnsauth | _dnsauth.pocと入力して二重になる（_dnsauth.poc.poc.example.com） |
「どのDNSが権威か」は、NSレコードを確認すると判断しやすいです。権威DNSが複数ある場合、片方だけ更新されていると地域によって結果が割れ、Pendingが長引く原因になります。
ローカルでも確認できる最低限コマンド
外部サイトでのチェックに加えて、手元の端末でも引けるかを確認すると切り分けが早くなります。
# TXTの確認（Windowsなら nslookup、macOS/Linuxなら dig など）
nslookup -type=txt _dnsauth.poc.example.com
# CNAMEの確認
nslookup -type=cname poc.example.com
このとき、期待しているTXT値が返ること、およびCNAMEがFront Doorのエンドポイントを指すことが確認できれば、少なくともDNS側の土台は整っています。ここまで揃ってもPendingが続く場合は、Front Door側の再検証タイミングや内部状態が影響している可能性があります。
なぜ「ワイルドカード検証済み」でも個別検証が必要になりやすいのか
「ワイルドカードで所有証明したのに、なぜサブドメインごとにTXTが必要なのか？」は当然の疑問です。仕様として理解しておくと、運用トラブルを減らせます。
- サブドメインが別管理の可能性：企業では、
api.example.comはAチーム、shop.example.comはBチームのように委任していることがあり、親ドメインの検証だけで自動承認してしまうと、想定外のホスト名をFront Doorに紐付けられるリスクが増えます。 - Front Doorの設定単位が「カスタムドメイン」ごと：ワイルドカードと個別サブドメインは別の設定オブジェクトとして扱われ、検証状態・証明書・ルーティングの関連付けが個別に持たれます。
- 証明書発行・更新フローの都合：Azure マネージド証明書は自動化されていますが、対象ホスト名が増えるほど検証の整合性を保つ必要があり、結果的にホスト名単位の検証が安全側に倒れやすいです。
この背景を踏まえると、ドキュメントの「自動承認」という表現は、実装や条件によっては誤解を招きやすいポイントと言えます。実務では“追加するカスタムドメインは、追加するたびに検証が走る”前提で設計すると安定します。
運用上の注意：サブドメインが増えるほど「検証作業」がボトルネックになる
poc.example.comだけなら手作業でも対応できますが、www、api、app、dev、stg…と増えていくと、TXTの追加・削除・棚卸しが地味に効いてきます。ここでは、ミスと手戻りを減らすための運用ポイントをまとめます。
手順をテンプレ化して「人の判断」を減らす
- 「Front Doorが提示したTXTホスト名と値を、そのまま登録する」という原則を手順書に固定する
- DNSゾーンが分割されている場合は、どのゾーンに入れるかの判断基準（NS確認など）を先に明文化する
- 検証用TXTは、用途が終わったら整理する（ただし運用ルールを決めて、むやみに消して再検証を誘発しない）
チェックを「表」で管理すると事故が減る
サブドメインが多い環境では、DNSとFront Doorの対応関係を一覧化しておくと、引き継ぎや障害対応が早くなります。
| サブドメイン | Front Doorに登録 | TXT（_dnsauth） | CNAME先 | 備考 |
|---|---|---|---|---|
www.example.com | 済 | 済 | <endpoint>.azurefd.net | 本番 |
api.example.com | 済 | 済 | <endpoint>.azurefd.net | WAF有効 |
poc.example.com | 追加中 | 未 | （ワイルドカードで解決） | Pending対処中 |
IaC（Bicep / Terraform など）で「追加作業」を自動化する発想
大量のサブドメインを扱う場合、Front Door側のリソース作成はIaCで統一し、DNS側も可能な範囲でAPI連携するのが現実的です。とくに次の設計が効きます。
- サブドメイン一覧（例：
www、api、poc…）をパラメータ化し、Front Doorのカスタムドメイン定義をループで生成する - Front Doorが提示する検証情報を運用フローに組み込み、DNS登録の作業をチケット化・自動化する
- DNSが外部管理でAPI連携が難しい場合でも、「必要なTXT名・値を出力する」だけで人のミスが減る
ここでの狙いは、“検証を自動承認に期待しない”前提に切り替え、追加・変更のたびに同じ品質で反復できる仕組みにすることです。
よくある質問
ワイルドカードのCNAMEがあるのに、サブドメインにもCNAMEは必要ですか？
DNS的には、ワイルドカードCNAMEが正しく設定されていれば、未定義のサブドメインは同じCNAME先へ解決されます。ただし、Front Door側の検証は「そのホスト名で実際に引けるか」を見るため、結果としてpoc.example.comがCNAMEで正しく解決できることが重要です。外部チェックで実際に引けているかを確認してください。
TXTはワイルドカードでまとめられませんか？（例：_dnsauth.*.example.com）
多くのDNSプロバイダーや検証方式では、検証のために提示されるTXTのホスト名は固定で、_dnsauthの直後に対象ホスト名が含まれる形式になります。実務上は、Front Doorが提示する名前に合わせて、サブドメインごとにTXTを置く運用に倒したほうが確実です。
DNSは反映しているのに、なぜPendingが続くのですか？
よくある原因は次の3つです。
- 正しいレコードを作ったつもりでも、ゾーン分割や管理画面仕様でFQDNが二重になっている
- 権威DNSが複数あり、片系だけ更新されて地域によって参照結果が割れている
- 古いTXTが残っており、Front Doorが期待する値と一致しない（複数値が返ってしまう）
外部サイトの複数リージョンチェックと、権威DNSの状態確認（NS、SOA）をセットで見ると切り分けが早いです。
それでも直らない場合、どこまでが自分でできる範囲ですか？
DNSのTXT/CNAMEが「どの地域からも」正しく引ける状態を作れたら、ユーザー側でできることはほぼやり切っています。そこから先はFront Door側の再検証タイミングや内部状態の問題の可能性があるため、サポートへ連絡して調査してもらうのが最短です。問い合わせ時は、対象ドメイン名、提示されたTXT名と値、dig/nslookupの結果、反映確認に使った外部ツールを添えると会話がスムーズです。
まとめ
- ワイルドカード（
*.example.com）を検証済みでも、サブドメイン（poc.example.com）が自動でValidatedになるとは限りません。 - サブドメインをFront Doorに追加したら、案内されるTXT（多くは
_dnsauth.poc.example.com）をDNSへ追加し、Front Doorが参照できる状態にする必要があります。 - Pendingが長引くときは、TXTのホスト名／値、DNSゾーンの置き場所、権威DNSのばらつき、古いTXTの残骸を優先的に疑うと近道です。
- サブドメインが増える運用では、手順の標準化とIaCの活用で、検証作業のミスと手戻りを大きく減らせます。
コメント