2026年4月21日の更新確認として押さえたい Azure Front Door ドメイン の要点は、「DNS TXTで所有権を検証し、CNAMEでFront Doorへ流し、TLS証明書の自動更新条件を外さない」ことです。特に本番サイト、SaaS、グローバル配信、Microsoft 365／Azure連携サービスを扱うIT管理者は、カスタムドメインの追加手順だけでなく、証明書更新・再検証・WAF適用までをセットで見直す必要があります。
Microsoft Learnの「Domains – Azure Front Door」は、Azure Front Door Standard／Premiumで使うカスタムドメイン、DNS構成、ドメイン検証、HTTPS/TLS証明書、WAFとの関連付けを整理した公式ドキュメントです。Azure Front Doorのドメインは、アプリケーションのトラフィックを受け取るためのカスタムドメイン名であり、サブドメイン、頂点ドメイン、ワイルドカードドメインを扱えます。(Microsoft Learn)
Azureの最新動向: Azure Front Door ドメインで何を確認すべきか
今回のポイントは、新しい画面操作を覚えることではありません。実務では、ドメイン追加後に証明書が自動更新されない、TXTレコードの値が古くて検証に失敗する、WAFポリシーを付けたつもりが対象ドメインに適用されていない といった運用トラブルを防ぐことが重要です。
Azure Front Door ドメイン運用で確認すべき項目は、次のように整理できます。
| 確認ポイント | 実務で見るべき内容 | 放置した場合のリスク |
|---|---|---|
| DNS TXTレコード | ドメイン所有権の検証に使う。値はAzure Front Doorが発行する | ドメインが承認されず、HTTPS構成や本番切替が進まない |
| DNS CNAMEレコード | インターネットトラフィックをAzure Front Doorへ流す | 旧環境へ流れ続ける、または証明書の自動ローテーション条件を満たさない |
| 証明書方式 | Azure Front Doorマネージド証明書か、Key Vault経由のカスタマー管理証明書か | 更新漏れ、再検証漏れ、証明書切れによる停止 |
| CNAMEの向き先 | Front Doorエンドポイントを直接指しているか | マネージド証明書が自動更新されない可能性 |
| WAFセキュリティポリシー | カスタムドメインとWAFポリシーが関連付けられているか | 攻撃検知・ブロックが想定ドメインに効かない |
Azure Front Doorでは、ドメイン追加時にDNS TXTレコードとDNS CNAMEレコードの2種類を扱います。TXTは所有権検証、CNAMEはトラフィックの流れを制御するためのものです。既存の本番サイトを移行する場合、先にTXTで所有権を検証し、その後CNAMEを切り替えることで、ダウンタイムを避けやすくなります。(Microsoft Learn)
Azure Front Door ドメインの基本
Azure Front Doorの「ドメイン」は、Azure Front Doorプロファイルに追加するカスタムドメインです。DNSゾーンそのものではなく、Front Doorが外部からのHTTP/HTTPSリクエストを受けるための入口と考えると分かりやすいです。
対応する主なドメイン種別は次の3つです。
| ドメイン種別 | 例 | 向いている用途 | 実務上の注意点 |
|---|---|---|---|
| サブドメイン | www.contoso.com、app.contoso.com | 一般的なWebサイト、API、管理画面 | 最も扱いやすい。CNAMEをFront Doorへ直接向ける設計にしやすい |
| 頂点ドメイン | contoso.com | コーポレートサイト、ブランドサイト | CNAMEフラット化などDNSプロバイダー側の仕様確認が必要 |
| ワイルドカードドメイン | *.contoso.com | SaaSのテナント別サブドメイン、大量のサブドメイン運用 | 証明書の自動ローテーションや検証条件を個別に確認する |
サブドメインは運用しやすく、初めてAzure Front Doorを導入する場合に最も扱いやすい選択肢です。頂点ドメインやワイルドカードドメインは便利ですが、DNSプロバイダーの仕様、証明書更新、検証方法まで含めて設計しないと、後から切り替え作業が複雑になります。Azure Front Doorでは、ドメインを複数のルートで使うこともできますが、その場合は各ルートで異なるパスを使う必要があります。(Microsoft Learn)
DNS設定の実務ポイント
Azure Front Door ドメイン設定では、TXTレコードとCNAMEレコードの役割を混同しないことが重要です。
TXTレコードは「このドメインを管理できる権限がある」ことを証明するために使います。一方、CNAMEレコードは「このドメインへのアクセスをAzure Front Doorへ向ける」ために使います。つまり、TXTは検証用、CNAMEは本番トラフィック用です。
TXTレコードは _dnsauth 形式で作成する
Azure Front DoorのTXTレコード検証では、TXTレコード名は _dnsauth.{subdomain} の形式になります。たとえば myapplication.contoso.com を使う場合、レコード名は _dnsauth.myapplication のようになります。TXTレコードの値はAzure Front Doorが発行する一意の値を使い、TTLの例として1時間が示されています。検証が完了した後は、TXTレコードをDNSサーバーから削除できます。(Microsoft Learn)
ただし、運用上は「削除してよい」と「削除すべき」は分けて考えます。将来の再検証や監査を考えると、削除する前に次の情報をチケットや構成管理台帳に残しておくと安全です。
| 記録しておく項目 | 理由 |
|---|---|
| 対象ドメイン名 | 再検証時に対象を取り違えないため |
| TXTレコード名 | _dnsauth のサブドメイン指定を確認するため |
| 発行されたTXT値 | 過去の検証値と新しい検証値を混同しないため |
| 検証完了日時 | 証明書更新や監査時の説明材料になるため |
| DNS管理者・変更者 | DNSチームとAzureチームが分かれている場合の責任分界に必要 |
既存サイトを止めにくい移行手順
本番稼働中のWebサイトをAzure Front Doorへ移行する場合は、いきなりCNAMEを切り替えない方が安全です。先にAzure Front Door側のドメイン設定と所有権検証を終わらせ、最後にCNAMEを切り替えます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | Azure Front Doorプロファイルにカスタムドメインを追加 | ルート、オリジン、WAF方針を先に確認する |
| 2 | DNSにTXTレコードを追加 | Azure Front Doorが発行した最新の値を使う |
| 3 | ドメイン検証が承認済みになるまで待つ | 保留中のままならTXT値、TTL、DNS反映を確認する |
| 4 | CNAMEをFront Doorエンドポイントへ向ける | 証明書自動更新のため、できるだけ直接向ける |
| 5 | HTTPS、ルーティング、WAF、ログを確認 | 切替後のアクセス、証明書、レスポンスヘッダーを確認する |
この順序にすると、DNS切り替え前に構成不備を見つけやすくなります。プロダクトオーナーの視点では、CNAME切り替えを「リリース作業」として扱い、DNS TTL、切り戻し先、ユーザー影響、監視体制を事前に決めておくことが重要です。
ドメイン検証ステータスの見方
Azure Front Doorのドメイン検証では、ステータスを見て次のアクションを判断します。特に「保留中」「再検証の保留中」「タイムアウト」「拒否」は、運用でよく確認する状態です。
| 状態 | 意味 | 取るべきアクション |
|---|---|---|
| 送信中 | カスタムドメイン作成中 | リソース作成完了まで待つ |
| 保留中 | TXTレコードの値が生成され、DNS追加待ち | DNSプロバイダーにTXTレコードを追加する |
| 再検証の保留中 | マネージド証明書の期限が近く、所有権の再検証が必要 | CNAMEがFront Doorを直接指しているか確認し、必要ならTXTを再生成する |
| 承認済み | ドメイン検証が完了している | HTTPS、ルート、WAF、ログを確認する |
| 拒否 | 証明機関側で証明書発行が拒否された | ドメイン名、CAA、TXT値、証明書要件を確認する |
| タイムアウト | 7日以内に正しいTXTが追加されなかった | TXTを再生成し、古い値ではなく新しい値を登録する |
| 内部エラー | 不明なエラー | 更新または再生成を試し、解消しなければAzureサポートへ連絡する |
Microsoft Learnでは、TXTレコードの既定TTLは1時間とされ、再検証のためにTXTを再生成する場合は、前のTXTレコードのTTLに注意するよう案内されています。また、TXTレコードは7日後に期限切れになるため、古い値を使い回すと検証に失敗します。(Microsoft Learn)
実務で失敗しやすいのは、「DNSにはTXTを入れたのに保留中のまま」というケースです。この場合、次の順で確認すると原因を切り分けやすくなります。
- TXTレコード名が
_dnsauth形式になっているか - サブドメイン部分を間違えていないか
- Azure Front Doorで再生成した後の新しい値を使っているか
- DNSプロバイダー側で反映が完了しているか
- 以前のTXTレコードのTTLが残っていないか
- DNSを管理するチームが別の場合、別ゾーンに登録していないか
HTTPS/TLS証明書の選び方
Azure Front Doorのカスタムドメインでは、HTTPSを使うためにTLS証明書を構成します。選択肢は大きく分けて、Azure Front Doorマネージド証明書と、カスタマー マネージド TLS証明書です。
多くの一般的なWebサイトでは、まずAzure Front Doorマネージド証明書を検討するのが自然です。証明書署名要求の作成、証明書のアップロード、保存、インストールをユーザー側で行う必要がなく、Azure Front Doorが更新も管理します。ただし、発行・インストールには数分から1時間、場合によってはそれ以上かかることがあります。(Microsoft Learn)
| 証明書方式 | 向いているケース | 注意点 |
|---|---|---|
| Azure Front Doorマネージド証明書 | 一般的なWebサイト、運用負荷を下げたい環境 | CNAMEの向き先によっては自動更新されない |
| カスタマー マネージド TLS証明書 | 特定CAの利用、証明書ピンニング、複数システムで同一証明書を使う要件 | Azure Key Vault、権限、証明書更新の運用設計が必要 |
| BYOCによる検証 | 既存証明書を使ってドメイン所有権を承認したい場合 | CNまたはSANがカスタムドメインと一致している必要がある |
Azure Front Doorのマネージド証明書はDigiCertから発行されます。一部のドメインでは、CAAレコードで 0 issue digicert.com を明示的に許可する必要があります。また、Azureが証明書を管理するため、ルート発行者や証明書階層は変更される可能性があります。証明書の拇印や証明書チェーンへの固定依存、いわゆる証明書ピンニングが必要な場合は、カスタマー マネージド TLS証明書を検討するべきです。(Microsoft Learn)
証明書の自動更新が効かないパターン
Azure Front Doorマネージド証明書は便利ですが、常に自動更新されるわけではありません。ドメインのCNAMEレコードがFront Doorエンドポイントを直接指している場合は自動ローテーションされますが、それ以外ではドメイン所有権の再検証が必要になることがあります。(Microsoft Learn)
特に次の構成は注意が必要です。
| 構成 | 問題になりやすい理由 | 対策 |
|---|---|---|
| CNAMEがFront Door以外のDNSレコードを指している | 自動ローテーション条件を満たさない可能性がある | 可能ならFront Doorエンドポイントへ直接向ける |
| CNAMEチェーンを使っている | 中間レコードを経由するため、自動更新条件から外れる可能性がある | チェーンを短くし、直接参照に近づける |
| Aレコードを使っている | MicrosoftはFront Door向けにCNAME利用を推奨している | サブドメインではCNAMEを基本にする |
| 頂点ドメインでCNAMEフラット化を使う | DNSプロバイダーの仕様に依存する | 証明書期限前の再検証手順を運用に入れる |
マネージド証明書の期限が近づくと、該当条件では期限の45日前に「再検証の保留中」になることがあります。この状態は、新しいDNS TXTレコードでドメイン所有権を再検証する必要があることを意味します。(Microsoft Learn)
ワイルドカードドメインは便利だが、証明書運用を甘く見ない
SaaSやマルチテナント型アプリでは、tenant-a.example.com、tenant-b.example.com のように多数のサブドメインを発行することがあります。この場合、*.example.com のワイルドカードドメインは管理を簡素化できます。
一方で、ワイルドカードドメインは証明書と検証の扱いが通常のサブドメインより複雑になりやすい領域です。Microsoft Learnでは、ドメイン種別ごとのマネージドTLS証明書の利用可否と自動ローテーションが整理され、ワイルドカードドメインでは自動ローテーションが「いいえ」とされています。(Microsoft Learn)
また、Azure UpdatesではAzure Front Door Standard／Premiumでワイルドカードドメイン向けマネージド証明書のサポートが一般提供として案内されています。つまり、ワイルドカードドメインを使う場合でも「証明書が使えるか」だけでなく、「更新が自動で完結するか」「再検証が必要か」「運用チームが期限を監視できるか」まで確認する必要があります。(Microsoft Azure)
ワイルドカードドメインを採用する判断基準は次のとおりです。
| 判断項目 | 採用しやすいケース | 避けた方がよいケース |
|---|---|---|
| サブドメイン数 | テナントや店舗ごとに大量発行する | 数個の固定サブドメインしかない |
| 運用体制 | 証明書期限、検証状態、DNS変更を監視できる | DNS管理者が不明確、変更履歴が残らない |
| セキュリティ設計 | WAF、ルーティング、ログをテナント単位で設計できる | すべてのサブドメインを同じ扱いにしてしまう |
| リリース速度 | 新規テナント追加を頻繁に行う | 変更頻度が低く、個別サブドメインで十分 |
カスタマー マネージド TLS証明書とKey Vaultの注意点
組織のポリシーで特定の証明機関を使う必要がある場合、クライアントアプリが特定証明書を前提としている場合、または同じ証明書を複数システムで使う場合は、カスタマー マネージド TLS証明書が選択肢になります。
この方式では、証明書をAzure Key Vaultにインポートし、Azure Front Doorから参照します。証明書はシークレットではなく証明書オブジェクトとしてアップロードする必要があり、Key VaultはAzure Front Doorプロファイルと同じAzureサブスクリプション内にある必要があります。異なるサブスクリプションのKey Vaultを選ぶと失敗します。(Microsoft Learn)
証明書要件としては、完全な証明書チェーン、Azure Front Doorで構成したドメインと一致するCN、PFXファイル、application/x-pkcs12 コンテンツタイプなどが求められます。また、Azure Front Doorでは楕円曲線、つまりEC暗号化アルゴリズムを使用した証明書はサポートされていません。(Microsoft Learn)
Key Vault更新時は「Latest」指定が重要
カスタマー マネージド TLS証明書を更新する場合、Key Vault内の証明書を更新するとAzure Front Doorが新しい証明書を自動検出できます。ただし、そのためにはAzure Front Doorで証明書を構成する際に、シークレットバージョンを Latest に設定しておく必要があります。特定バージョンを指定している場合は、新しい証明書バージョンを手動で再選択する必要があります。新しい証明書またはシークレットの自動デプロイには最大72時間かかる場合があります。(Microsoft Learn)
運用では、次のような設計にしておくと証明書切れを防ぎやすくなります。
| 項目 | 推奨する運用 |
|---|---|
| Key Vaultの配置 | Azure Front Doorと同じサブスクリプションに置く |
| 証明書バージョン | 自動更新を期待するなら Latest を使う |
| 更新タイミング | 証明書期限の直前ではなく、余裕を持って更新する |
| 監視 | 証明書期限、Front Doorの反映、Key Vaultアクセス権を監視する |
| アクセス制御 | マネージドIDまたはサービスプリンシパルの権限を明確にする |
BYOC検証で押さえるべきポイント
Azure Front Doorでは、2023年9月以降、BYOC、つまりBring Your Own Certificatesによるドメイン所有権の検証がサポートされています。証明書のCNまたはSANがカスタムドメインと一致している場合、Front Doorはドメイン所有権を承認できます。Azureマネージド証明書を選ぶ場合はDNS TXTレコードによる検証になります。(Microsoft Learn)
証明書タイプを切り替える場合も注意が必要です。証明書タイプの切り替えでは、新しい証明書のデプロイに最大1時間かかる場合があります。ドメイン状態が承認済みであれば、ユーザー管理証明書とマネージド証明書の切り替えでダウンタイムは発生しないとされています。ただし、BYOCからマネージド証明書へ切り替える場合はドメインの再検証が必要です。マネージド証明書からBYOCへ切り替える場合は再検証不要とされています。(Microsoft Learn)
実務では、証明書方式の切り替えを「設定変更」ではなく「リリース作業」として扱うべきです。切り替え前に、検証状態、証明書CN/SAN、Key Vault権限、DNS TXT再生成の有無、監視アラートを確認してください。
WAFをカスタムドメインに適用する時の注意
Azure Front DoorのカスタムドメインでWAFを使うには、Azure Front Doorセキュリティポリシーリソースを使います。セキュリティポリシーは、ドメインとWAFポリシーを関連付ける役割を持ちます。必要に応じて複数のセキュリティポリシーを作成し、ドメインごとに異なるWAFポリシーを適用できます。(Microsoft Learn)
ここで重要なのは、WAFポリシーを作成しただけでは不十分という点です。保護したいカスタムドメインに、正しいセキュリティポリシーが関連付いているかを確認する必要があります。
たとえば、次のような設計が考えられます。
| ドメイン | 用途 | WAF方針 |
|---|---|---|
www.example.com | 一般ユーザー向けWebサイト | OWASPルールを基本に、誤検知を調整 |
api.example.com | 外部API | レート制限、Bot対策、API特有の除外を検討 |
admin.example.com | 管理画面 | 国・地域制限、IP制限、厳しめのルールを検討 |
*.tenant.example.com | SaaSテナント | テナント影響を考慮し、ログ監視から段階導入 |
プロダクトオーナーは、WAFを単なるセキュリティ機能としてではなく、ユーザー影響を伴う配信制御として扱うべきです。ブロックモードへ移行する前に、検知ログを確認し、重要なフォーム送信、ログイン、API呼び出しが誤検知されないかを検証してください。
IT管理者が今すぐ確認すべきチェックリスト
Azure Front Door ドメインをすでに使っている場合は、次の順で棚卸しすると効率的です。
| 優先度 | 確認項目 | 具体的な確認内容 |
|---|---|---|
| 高 | CNAMEの向き先 | Front Doorエンドポイントを直接指しているか |
| 高 | ドメイン検証状態 | 承認済み、保留中、再検証の保留中、拒否、タイムアウトを確認 |
| 高 | 証明書方式 | マネージド証明書か、Key Vault経由の証明書か |
| 高 | 証明書期限 | 期限、再検証予定、監視アラートを確認 |
| 中 | TXTレコード履歴 | 古い検証値を使い回していないか |
| 中 | CAAレコード | DigiCert発行を妨げる設定がないか |
| 中 | Key Vault権限 | マネージドIDまたはサービスプリンシパルのアクセス権があるか |
| 中 | WAF関連付け | 対象ドメインとWAFポリシーが正しく関連付いているか |
| 低 | ルート設計 | 同一ドメインを複数ルートで使う場合、パスの競合がないか |
新規導入の場合は、まずサブドメインで設計し、Azure Front Doorマネージド証明書を使う構成から始めると運用負荷を抑えやすいです。頂点ドメインやワイルドカードドメインは、DNSプロバイダー、証明書更新、WAF設計まで固めてから採用する方が安全です。
プロダクトオーナーが見るべき判断基準
Azure Front Door ドメインの設定はIT管理者の作業に見えますが、実際にはプロダクトの可用性、セキュリティ、リリース速度に直結します。プロダクトオーナーは、次の観点で判断するとよいでしょう。
| 判断軸 | 確認すべき質問 |
|---|---|
| 可用性 | CNAME切り替え時の切り戻し手順はあるか |
| セキュリティ | WAFをどのドメインに、どの強度で適用するか |
| 運用負荷 | 証明書更新をAzureに任せられる構成か |
| グローバル展開 | 国・地域ごとのアクセス制御やレイテンシ要件はあるか |
| SaaS拡張性 | ワイルドカードドメインが必要か、個別サブドメインで十分か |
| 監査対応 | DNS変更、証明書更新、WAF変更の履歴を残せるか |
特にグローバル向けサービスでは、DNS反映、証明書発行、WAF誤検知の影響が国や地域によって見え方に差が出ます。切り替え直後だけでなく、24〜72時間程度はログ、証明書、エラー率、問い合わせ件数を確認する運用にしておくと安心です。
まとめ: Azure Front Door ドメイン運用で次にやること
Azure Front Door ドメインの2026年4月時点の確認ポイントは、カスタムドメインを追加できるかどうかではなく、DNS、証明書、検証状態、WAFを一体で運用できているか です。
まずは既存のAzure Front Doorプロファイルを開き、次の5点を確認してください。
- カスタムドメインの検証状態が承認済みか
- CNAMEがFront Doorエンドポイントを直接指しているか
- 証明書方式と有効期限が把握されているか
- Key Vault証明書を使う場合、
Latest指定と権限が正しいか - WAFセキュリティポリシーが対象ドメインに関連付いているか
本番環境では、TXTレコードの追加やCNAME切り替えを単発作業にしないことが大切です。DNS変更台帳、証明書更新カレンダー、WAF適用範囲、切り戻し手順をセットで整備すれば、Azure Front Doorを安全なグローバル入口として運用しやすくなります。
コメント