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

重要

Azure Front Door (クラシック) では、プロファイルの作成、新しいドメインオンボード、またはマネージド証明書はサポートされておらず、2027 年 31 月 31 日 で廃止されます。 サービスの中断を回避するには、Azure Front Door Standard または Premium に移行してください。 詳細については、「Azure Front Door (クラシック) の提供終了を参照してください。

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

ワイルドカード ドメインを使用すると、Azure Front Door プロファイルの構成を簡略化できます。 各サブドメインを個別に追加または指定するように構成を変更する必要はありません。 たとえば、同じルートを使用し、ワイルドカード ドメイン customer1.contoso.com を追加することで、customer2.contoso.com、customerN.contoso.com、および *.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 でカスタム ドメインを構成する」を参照してください。

注意

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

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

注意

  • キー コンテナーから同じワイルドカード証明書を使用することも、サブドメインの Azure Front Door で管理される証明書から使用することもできます。
  • Azure Front Door Standard または Premium プロファイルで既に検証されているワイルドカード ドメインのサブドメインを追加する場合、ドメイン検証は自動的に承認されます。 この条件は、Bring Your Own Certificate に適用されます。 ドメインの所有権は、サブドメインのマネージド証明書に必要です。
  • ワイルドカード ドメインが検証され、既に 1 つのプロファイルに追加されている場合でも、検証されている限り、単一レベルのサブドメインを別のプロファイルに追加できます。

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

ワイルドカードの単一レベルのサブドメインは、必要な数まで追加できます。 たとえば、ワイルドカード ドメイン *.contoso.com の場合、Azure Front Door プロファイルに image.contoso.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) マッピングは、*.contoso.com にマッピングされた endpoint.azurefd.net のような、CNAME レコードの直接マッピングにすることができます。 または、 afdverify 一時マッピングを使用することもできます。 たとえば、afdverify.contoso.com にマッピングされた afdverify.endpoint.azurefd.net は、ワイルドカードの CNAME レコードマップを検証します。

注意

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

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

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

  • 特定のサブドメインに対して異なる WAF ポリシーを持つ。 たとえば、*.contoso.com では、ドメインの所有権を再度証明しなくても foo.contoso.com を追加できます。 ただし、foo.bar.contoso.com の単一レベルのサブドメインではないため、*.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 を有効にする必要があります。 ワイルドカード ドメインの証明書バインドには、ワイルドカード証明書が必要です。 つまり、証明書のサブジェクト名にもワイルドカード ドメインが必要です。

注意

現時点では、独自のカスタム SSL 証明書を使用してのみ、ワイルドカード ドメインに対して HTTPS を有効にすることができます。 ワイルドカード ドメインには、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（*.foo.com/* は配信元グループ A にマップされた）。
  • ルート 2（bar.foo.com/somePath/* はオリジン グループ B にマップされています）。
    bar.foo.com/anotherPath/*に対して要求が到着した場合、Azure Front Doorは、より具体的なドメインの一致に基づいてルート 2 を選択しますが、ルート間で一致するパス パターンが見つかりません。

ルーティング ルール

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

重要

ルート間で一致するパス パターンを使用する必要があります。または、クライアントにエラーが表示されます。

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

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

関連するコンテンツ

  • Last updated on