Partager via

Domaines génériques dans Azure Front Door

  • Article

Important

Azure Front Door (classique) va être mis hors service le 31 mars 2027. Pour éviter toute interruption de service, il est important de migrer vos profils Azure Front Door (classique) vers le niveau Azure Front Door Standard ou Premium au plus en mars 2027. Pour plus d’informations, consultez Mise hors service d'Azure Front Door (classique).

Les domaines génériques permettent à Azure Front Door de recevoir du trafic pour n’importe quel sous-domaine d’un domaine du plus haut niveau. *.contoso.com est un exemple de domaine générique.

En utilisant des domaines génériques, vous pouvez simplifier la configuration de votre profil Azure Front Door. Vous n’avez pas à modifier la configuration pour ajouter et/ou spécifier chaque sous-domaine séparément. Par exemple, vous pouvez définir le routage pour customer1.contoso.com, customer2.contoso.com et customerN.contoso.com en utilisant la même route et en ajoutant le domaine générique *.contoso.com.

Les domaines génériques vous offrent plusieurs avantages, y compris :

  • Vous n’avez pas besoin d’intégrer chaque sous-domaine dans votre profil Azure Front Door. Par exemple, supposons que vous créez de nouveaux sous-domaines pour chaque client et que vous routez les demandes de tous les clients vers un même groupe d’origines. Chaque fois que vous ajoutez un nouveau client, Azure Front Door comprend comment router le trafic vers votre groupe d’origines, même si le sous-domaine n’a pas été configuré explicitement.
  • Vous n’avez pas besoin de générer un nouveau certificat TLS ou de gérer des paramètres HTTPS spécifiques au sous-domaine pour lier un certificat pour chaque sous-domaine.
  • Vous pouvez utiliser une même stratégie de pare-feu d’applications web (WAF) pour tous vos sous-domaines.

En règle générale, les domaines génériques sont utilisés pour prendre en charge les solutions SaaS (Software-as-a-Service) et d’autres applications multilocataires. Quand vous créez ces types d’applications, vous devez accorder une attention particulière à la façon dont vous routez le trafic vers vos serveurs d’origine. Pour plus d’informations, consultez Utiliser Azure Front Door dans une solution multilocataire.

Notes

Quand vous utilisez Azure DNS pour gérer les enregistrements DNS de votre domaine, vous devez configurer des domaines génériques en utilisant l’API Azure Resource Manager, Bicep, PowerShell et Azure CLI. La prise en charge de l’ajout et de la gestion des domaines génériques d’Azure DNS dans le portail Azure n’est pas disponible.

Ajouter un domaine générique et une liaison de certificat

Vous pouvez ajouter un domaine générique en suivant les étapes similaires pour les sous-domaines. Pour plus d’informations sur l’ajout d’un sous-domaine à Azure Front Door, consultez Configurer un domaine personnalisé sur Azure Front Door en utilisant le portail Azure.

Notes

  • Azure DNS prend en charge les enregistrements génériques.
  • Vous ne pouvez pas vider le cache Azure Front Door pour un domaine générique. Vous devez spécifier un sous-domaine lors du vidage du cache.

Pour accepter le trafic HTTPS sur votre domaine générique, vous devez activer HTTPS sur le domaine générique. La liaison de certificat pour un domaine générique requiert un certificat générique. Autrement dit, le nom du sujet du certificat doit également comporter le nom de domaine générique.

Notes

  • Actuellement, seule l’option consistant à utiliser votre propre certificat SSL personnalisé est disponible pour activer HTTPS pour les domaines génériques. Les certificats Azure Front Door gérés ne peuvent pas être utilisés pour les domaines génériques.
  • Vous pouvez choisir d’utiliser le même certificat générique à partir d’Azure Key Vault ou des certificats gérés Azure Front Door pour les sous-domaines.
  • Si vous voulez ajouter un sous-domaine du domaine générique déjà validé dans le profil Azure Front Door Standard ou Premium, la validation de domaine est approuvée automatiquement.
  • Si un domaine générique est validé et déjà ajouté à un profil, un sous-domaine à niveau unique peut encore être ajouté à un autre profil tant qu’il est également validé.

Définir explicitement un sous-domaine

Vous pouvez ajouter autant de sous-domaines à un seul niveau du domaine générique que vous le souhaitez. Par exemple, pour le domaine générique *.contoso.com, vous pouvez aussi ajouter des sous-domaines à votre profil Azure Front Door pour image.contosto.com, cart.contoso.com, etc. La configuration que vous spécifiez explicitement pour le sous-domaine est prioritaire sur la configuration du domaine générique.

Vous pouvez être amené à ajouter explicitement des sous-domaines dans ces situations :

  • Vous devez définir une route pour un sous-domaine différente de celles du reste des domaines (du domaine générique). Par exemple, vos clients peuvent utiliser des sous-domaines comme customer1.contoso.com, customer2.contoso.com, etc., et ces sous-domaines doivent tous être routés vers vos serveurs d’applications principaux. Cependant, vous pouvez aussi router images.contoso.com vers un conteneur Stockage Blob Azure.
  • Vous devez utiliser une stratégie de pare-feu d’applications web différente pour un sous-domaine spécifique.

Les sous-domaines comme www.image.contoso.com ne sont pas des sous-domaines de même niveau de *.contoso.com.

Ajout de domaines génériques

Vous pouvez ajouter un domaine générique sous la section pour les hôtes frontaux ou les domaines. Comme pour les sous-domaines, Azure Front Door (classique) vérifie qu’il existe un mappage d’enregistrement CNAME pour votre domaine générique. Ce mappage DNS (Domain Name System) peut être un mappage d’enregistrement CNAME direct comme *.contoso.com mappé à endpoint.azurefd.net. Ou vous pouvez utiliser le mappage temporaire afdverify. Par exemple, afdverify.contoso.com mappé à afdverify.endpoint.azurefd.net valide le mappage d’enregistrement CNAME pour le domaine générique.

Notes

Azure DNS prend en charge les enregistrements génériques.

Vous pouvez ajouter autant de sous-domaines à un seul niveau que le domaine générique dans les hôtes frontaux, jusqu’à la limite des hôtes frontaux. Cette fonctionnalité peut être nécessaire pour :

  • Définir d’un itinéraire différent pour un sous-domaine par rapport au reste des domaines (comparé au domaine générique).

  • Avoir une stratégie de pare-feu d'applications web différente pour un sous-domaine spécifique. Par exemple, *.contoso.com permet d’ajouter foo.contoso.com sans devoir à nouveau prouver la propriété du domaine. Mais cela n’autorise pas foo.bar.contoso.com, car il ne s’agit pas d’un sous-domaine de niveau unique de *.contoso.com. Pour ajouter foo.bar.contoso.com sans validation supplémentaire de la propriété du domaine, vous devez ajouter *.bar.contoso.com.

Vous pouvez ajouter des domaines génériques et leurs sous-domaines avec certaines limitations :

  • Si un domaine générique est ajouté à un profil Azure Front Door (classique) :
    • Le domaine générique ne peut être ajouté à aucun autre profil Azure Front Door (classique).
    • Les sous-domaines de premier niveau du domaine générique ne peuvent pas être ajoutés à un autre profil Azure Front Door (classique) ou un profil Azure Content Delivery Network.
  • Si un sous-domaine d’un domaine générique est déjà ajouté à un profil Azure Front Door (classique) ou un profil Azure Content Delivery Network, le domaine générique ne peut pas être utilisé pour un autre profil Azure Front Door (classique).
  • Si deux profils (Azure Front Door ou Azure Content Delivery Network de Microsoft) possèdent plusieurs sous-domaines d’un domaine racine, les domaines génériques ne peuvent être ajoutés à aucun des deux profils.

Liaison de certificats

Pour accepter le trafic HTTPS sur votre domaine générique, vous devez activer HTTPS sur le domaine générique. La liaison de certificat pour un domaine générique requiert un certificat générique. Autrement dit, le nom du sujet du certificat doit également comporter le nom de domaine générique.

Notes

Actuellement, seule l’option consistant à utiliser votre propre certificat SSL personnalisé est disponible pour activer HTTPS pour les domaines génériques. Les certificats Azure Front Door gérés ne peuvent pas être utilisés pour les domaines génériques.

Vous pouvez choisir d’utiliser le même certificat générique à partir d’Azure Key Vault ou des certificats gérés Azure Front Door pour les sous-domaines.

Si un sous-domaine est ajouté pour un domaine générique auquel un certificat est déjà associé, vous ne pouvez pas désactivé le protocole HTTPS pour le sous-domaine. Le sous-domaine utilise la liaison de certificat pour le domaine générique, à moins qu’une autre clé Key Vault ou un autre certificat géré par Azure Front Door ne le remplace.

Stratégies WAF

Les stratégies de pare-feu d’applications web peuvent être attachées à des domaines génériques similaires aux autres domaines. Une stratégie de pare-feu d’applications web peut être appliquée au sous-domaine d’un domaine générique. Les sous-domaines héritent automatiquement de la stratégie WAF du domaine générique si aucune stratégie WAF explicite n’est associée au sous-domaine. Toutefois, si le sous-domaine est ajouté à un autre profil à partir du profil de domaine générique, le sous-domaine ne peut pas hériter de la stratégie WAF associée au domaine générique.

Les stratégies de pare-feu d’applications web peuvent être attachées à des domaines génériques similaires aux autres domaines. Une stratégie de pare-feu d’applications web peut être appliquée au sous-domaine d’un domaine générique. Pour les sous-domaines, vous devez spécifier la stratégie de pare-feu d’applications web à utiliser, même s’il s’agit de la même stratégie que celle du domaine générique. Les sous-domaines n’héritent pas automatiquement de la stratégie de pare-feu d’applications web du domaine générique.

Si vous ne souhaitez pas qu’une stratégie de pare-feu d'applications web s’exécute pour un sous-domaine, vous pouvez créer une stratégie vide sans ensemble de règles géré ou personnalisé.

Itinéraires

Lors de la configuration d’une route, vous pouvez sélectionner un domaine générique comme origine. Vous pouvez également avoir un comportement de routage différent pour le domaine générique et pour les sous-domaines. Azure Front Door choisit la correspondance la plus spécifique pour le domaine parmi les différentes routes. Pour plus d’informations, consultez Comment les demandes sont mises en correspondance avec une règle de routage.

Important

Vous devez avoir des modèles de chemin correspondants dans vos routes, sans quoi vos clients verront des échecs.

Par exemple, supposons que vous avez deux règles de routage :

  • Route 1 (*.foo.com/* mappé au groupe d’origine A)
  • Route 2 (bar.foo.com/somePath/* mappé au groupe d’origine B). Si une demande arrive pour bar.foo.com/anotherPath/*, Azure Front Door sélectionne la route 2 en vertu d’une correspondance de domaine plus spécifique, seulement pour ne trouver aucun modèle de chemin correspondant dans les routes.

Règles de routage

Lors de la configuration d’une règle d’acheminement, vous pouvez sélectionner un domaine générique comme hôte frontend. Vous pouvez également avoir un comportement de routage différent pour le domaine générique et pour les sous-domaines. Azure Front Door choisit la correspondance la plus spécifique pour le domaine parmi les différentes routes. Pour plus d’informations, consultez Comment les demandes sont mises en correspondance avec une règle de routage.

Important

Vous devez avoir des modèles de chemin correspondants dans vos routes, sans quoi vos clients verront des échecs.

Par exemple, supposons que vous avez deux règles de routage :

  • Route 1 (*.foo.com/* mappé au pool de back-ends A)
  • Route 2 (bar.foo.com/somePath/* mappé au pool de back-ends B). Si une demande arrive pour bar.foo.com/anotherPath/*, Azure Front Door sélectionne la route 2 en vertu d’une correspondance de domaine plus spécifique, seulement pour ne trouver aucun modèle de chemin correspondant dans les routes.

Étapes suivantes