次の方法で共有

Azure Front Door のワイルドカード ドメイン

  • [アーティクル]

重要

Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。

ワイルドカード ドメインを使用すると、Azure Front Door で最上位ドメインの任意のサブドメインのトラフィックを受信できます。 ワイルドカード ドメインの例は、*.contoso.com です。

ワイルドカード ドメインを使用すると、Azure Front Door プロファイルの構成を簡略化できます。 各サブドメインを個別に追加または指定するように構成を変更する必要はありません。 たとえば、同じルートを使用し、ワイルドカード ドメイン *.contoso.com を追加することで、customer1.contoso.com、customer2.contoso.com、および customerN.contoso.com のルーティングを定義することができます。

ワイルドカード ドメインには、次のようないくつかの利点があります。

  • Azure Front Door プロファイルで各サブドメインをオンボードする必要はありません。 たとえば、すべての顧客に新しいサブドメインを作成し、すべての顧客の要求を 1 つの配信元グループにルーティングするとします。 新しい顧客を追加するたびに、サブドメインが明示的に構成されていない場合でも、Azure Front Door はトラフィックを配信元グループにルーティングする方法を理解します。
  • サブドメインごとに証明書をバインドするために、新しい トランスポート層セキュリティ (TLS) 証明書を生成したり、サブドメイン固有の HTTPS 設定を管理したりする必要はありません。
  • すべてのサブドメインに対して 1 つの Web アプリケーション ファイアウォール (WAF) ポリシーを使用できます。

一般的に、ワイルドカード ドメインは、サービスとしてのソフトウェア (SaaS) ソリューションやその他のマルチテナント アプリケーションをサポートするために使用されます。 これらの種類のアプリケーションをビルドするときは、トラフィックを配信元サーバーにルーティングする方法をよく検討する必要があります。 詳細については、「マルチテナント ソリューションで Azure Front Door を使用する」を参照してください。

注意

Azure DNS を使用してドメインの DNS レコードを管理する場合は、Azure Resource Manager API、Bicep、PowerShell、Azure CLI を使用してワイルドカード ドメインを構成する必要があります。 Azure portal で Azure DNS ワイルドカード ドメインを追加、管理することはサポートされていません。

ワイルドカード ドメインと証明書バインドを追加する

サブドメインの場合と同様の手順に従ってワイルドカード ドメインを追加できます。 Azure Front Door へのサブドメインの追加の詳細については、「Azure portal を使用して Azure Front Door でカスタム ドメインを構成する」を参照してください。

Note

  • Azure DNS は、ワイルドカード レコードをサポートしています。
  • ワイルドカード ドメインの Azure Front Door キャッシュを消去することはできません。 キャッシュを消去するときは、サブドメインを指定する必要があります。

ワイルドカード ドメインで HTTPS トラフィックを受け入れるには、ワイルドカード ドメインで HTTPS を有効にする必要があります。 ワイルドカード ドメインの証明書バインドには、ワイルドカード証明書が必要です。 つまり、証明書のサブジェクト名にもワイルドカード ドメインが必要です。

Note

  • 現在のところ、ワイルドカード ドメインに対して HTTPS を有効にするには、独自のカスタム SSL 証明書を使用するオプションしかありません。 Azure Front Door で管理される証明書は、ワイルドカード ドメインには使用できません。
  • キー コンテナーから同じワイルドカード証明書を使用することも、サブドメインの Azure Front Door で管理される証明書から使用することもできます。
  • Azure Front Door Standard または Premium プロファイルで既に検証されているワイルドカード ドメインのサブドメインを追加する場合、ドメイン検証は自動的に承認されます。
  • ワイルドカード ドメインが検証され、1 つのプロファイルに既に追加されている場合、単一レベルのサブドメインも、検証されているのであれば、別のプロファイルに追加できます。

サブドメインを明示的に定義する

ワイルドカードの単一レベルのサブドメインを任意の数追加できます。 たとえば、ワイルドカード ドメイン *.contoso.com の場合、Azure Front Door プロファイルに image.contosto.com や cart.contoso.com などのサブドメインも追加できます。 サブドメインに明示的に指定する構成は、ワイルドカード ドメインの構成よりも優先されます。

次の状況では、サブドメインを明示的に追加することが必要になる場合があります。

  • サブドメインに、(ワイルドカード ドメインからの) 他のドメインとは異なる別のルートを定義する必要がある。 たとえば、顧客が customer1.contoso.com や customer2.contoso.com などのサブドメインを使用しており、これらのサブドメインをすべてメイン アプリケーション サーバーにルーティングする必要があります。 一方、images.contoso.com は Azure Storage BLOB コンテナーにルーティングする必要があります。
  • 特定のサブドメインに対して異なる WAF ポリシーを使用する必要がある。

www.image.contoso.com などのサブドメインは、*.contoso.com の単一レベルのサブドメインではありません。

ワイルドカード ドメインの追加

ワイルドカード ドメインは、フロントエンド ホストまたはドメインのセクションでオンボードできます。 Azure Front Door (クラシック) では、サブドメインと同様に、ワイルドカード ドメインについても CNAME レコード マッピングがあるかが検証されます。 このドメイン ネーム システム (DNS) マッピングは、endpoint.azurefd.net にマッピングされた *.contoso.com のような、CNAME レコードの直接マッピングにすることができます。 または、afdverify 一時マッピングを使用することもできます。 たとえば、afdverify.endpoint.azurefd.net にマッピングされた afdverify.contoso.com は、ワイルドカードの CNAME レコードマップを検証します。

Note

Azure DNS は、ワイルドカード レコードをサポートしています。

フロントエンド ホストには、フロントエンド ホストの上限に達するまで、ワイルドカード ドメインの単一レベルのサブドメインを追加できます。 この機能は、次の場合に必要になることがあります。

  • 他のドメイン (ワイルドカード ドメインから) とは異なる、サブドメインの別のルートを定義する。

  • 特定のサブドメインに対して異なる WAF ポリシーを持つ。 たとえば、*.contoso.com では、ドメインの所有権を再度証明しなくても foo.contoso.com を追加できます。 ただし、*.contoso.com の単一レベルのサブドメインではないため、foo.bar.contoso.com は許可されません。 ドメイン所有権の追加検証を行わずに foo.bar.contoso.com を追加するには、*.bar.contoso.com を追加する必要があります。

次の制限事項を踏まえ、ワイルドカード ドメインと、そのサブドメインを追加できます。

  • ワイルドカード ドメインが Azure Front Door (クラシック) プロファイルに追加された場合:
    • そのワイルドカード ドメインは、その他の Azure Front Door (クラシック) プロファイルには追加できません。
    • そのワイルドカード ドメインの第 1 レベルのサブドメインは、別の Azure Front Door (クラシック) プロファイル、または Azure Content Delivery Network プロファイルには追加できません。
  • ワイルドカード ドメインのサブドメインが Azure Front Door (クラシック) プロファイルまたは Azure Content Delivery Network プロファイルに既に追加されている場合、そのワイルドカード ドメインは、他の Azure Front Door (クラシック) プロファイルでは使用できません。
  • 2 つのプロファイル (Azure Front Door または Azure Content Delivery Network) にルート ドメインのサブドメインが複数ある場合、ワイルドカード ドメインはいずれのプロファイルにも追加できません。

証明書バインド

ワイルドカード ドメインで HTTPS トラフィックを受け入れるには、ワイルドカード ドメインで HTTPS を有効にする必要があります。 ワイルドカード ドメインの証明書バインドには、ワイルドカード証明書が必要です。 つまり、証明書のサブジェクト名にもワイルドカード ドメインが必要です。

Note

現在のところ、ワイルドカード ドメインに対して HTTPS を有効にするには、独自のカスタム SSL 証明書を使用するオプションしかありません。 Azure Front Door で管理される証明書は、ワイルドカード ドメインには使用できません。

キー コンテナーから同じワイルドカード証明書を使用することも、サブドメインの Azure Front Door で管理される証明書から使用することもできます。

既に証明書が関連付けられているワイルドカード ドメインにサブドメインが追加されている場合、このサブドメインの HTTPS を無効にすることはできません。 サブドメインは、別の Key Vault または Azure Front Door で管理されている証明書で上書きされない限り、ワイルドカード ドメインの証明書バインドを使用します。

WAF ポリシー

WAF ポリシーは、他のドメインと同様に、ワイルドカード ドメインにもアタッチできます。 ワイルドカード ドメインのサブドメインに、別の WAF ポリシーを適用することもできます。 サブドメインに明示的な WAF ポリシーが関連付けられていない場合、サブドメインはワイルドカード ドメインから WAF ポリシーを自動的に継承します。 ただし、サブドメインがワイルドカード ドメイン プロファイルとは別のプロファイルに追加された場合、サブドメインはワイルドカード ドメインに関連付けられている WAF ポリシーを継承できません。

WAF ポリシーは、他のドメインと同様に、ワイルドカード ドメインにもアタッチできます。 ワイルドカード ドメインのサブドメインに、別の WAF ポリシーを適用することもできます。 サブドメインについては、ワイルドカード ドメインと同じポリシーを使用する場合であっても、使用する WAF ポリシーを指定する必要があります。 サブドメインは、ワイルドカード ドメインから WAF ポリシーを自動的に継承 "しません"。

サブドメインに対して WAF ポリシーを実行したくない場合は、管理されていないルールセット、またはカスタム ルールセットを使用せずに、空の WAF ポリシーを作成します。

ルート

ルートを構成するときは、配信元としてワイルドカード ドメインを選択できます。 また、ワイルドカード ドメインとサブドメインに対し、それぞれ異なるルート動作を適用することもできます。 Azure Front Door では、さまざまなルート間で、ドメインに最も具体的に一致するものが選択されます。 詳細については、「ルーティング規則に対する要求の照合方法」を参照してください。

重要

ルート全体でパス パターンが一致している必要があります。一致しない場合、クライアントにエラーが表示されます。

たとえば、次の 2 つのルーティング規則があるとします。

  • ルート 1 (配信元グループ A にマップされた *.foo.com/*)。
  • ルート 2 (配信元グループ B にマップされた bar.foo.com/somePath/*)。bar.foo.com/anotherPath/* に対する要求が到着した場合、Azure Front Door では、より具体的なドメインの一致に基づいてルート 2 が選択されますが、ルート全体で一致するパス パターンは見つかりません。

ルーティング ルール

ルーティング規則を構成する際には、フロントエンド ホストとしてワイルドカード ドメインを選択できます。 また、ワイルドカード ドメインとサブドメインに対し、それぞれ異なるルート動作を適用することもできます。 Azure Front Door では、さまざまなルート間で、ドメインに最も具体的に一致するものが選択されます。 詳細については、「ルーティング規則に対する要求の照合方法」を参照してください。

重要

ルート全体でパス パターンが一致している必要があります。一致しない場合、クライアントにエラーが表示されます。

たとえば、次の 2 つのルーティング規則があるとします。

  • ルート 1 (バックエンド プール A にマップされた *.foo.com/*)。
  • ルート 2 (バックエンド プール B にマップされた bar.foo.com/somePath/*)。bar.foo.com/anotherPath/* に対する要求が到着した場合、Azure Front Door では、より具体的なドメインの一致に基づいてルート 2 が選択されますが、ルート全体で一致するパス パターンは見つかりません。

次のステップ