Domínios curinga no Azure Front Door

  • Artigo

Importante

O Azure Front Door (clássico) será desativado em 31 de março de 2027. Para evitar qualquer interrupção do serviço, é importante que você migre seus perfis do Azure Front Door (clássico) para a camada Standard ou Premium do Azure Front Door até março de 2027. Para obter mais informações, consulte Desativação do Azure Front Door (clássico).

Os domínios curinga permitem que o Azure Front Door receba tráfego para qualquer subdomínio de um domínio de nível superior. Um exemplo de domínio curinga é *.contoso.com.

Usando domínios curinga, você pode simplificar a configuração do perfil do Azure Front Door. Você não precisa modificar a configuração para adicionar ou especificar cada subdomínio separadamente. Por exemplo, você pode definir o roteamento para customer1.contoso.com, customer2.contoso.com e customerN.contoso.com usando a mesma rota e adicionando o domínio curinga *.contoso.com.

Os domínios curinga oferecem várias vantagens, incluindo:

  • Você não precisa integrar cada subdomínio ao seu perfil do Azure Front Door. Por exemplo, suponha que você crie subdomínios para cada cliente e encaminhe todas as solicitações dos clientes para um só grupo de origem. Sempre que você adiciona um novo cliente, o Azure Front Door entende como rotear o tráfego para seu grupo de origem, mesmo que o subdomínio não esteja explicitamente configurado.
  • Você não precisa gerar um novo certificado TLS (Transport Layer Security) ou gerenciar configurações HTTPS específicas do subdomínio para vincular um certificado para cada subdomínio.
  • Você pode usar uma só política de WAF (firewall do aplicativo Web) para todos os seus subdomínios.

Normalmente, domínios curinga são usados para dar suporte a soluções de SaaS (software como serviço) e a outros aplicativos multilocatário. Ao criar esses tipos de aplicativo, você precisa considerar especialmente como rotear o tráfego para os servidores de origem. Para obter mais informações, consulte Usar o Azure Front Door em uma solução multilocatário.

Observação

Quando usa o DNS do Azure para gerenciar os registros DNS do domínio, você precisa configurar domínios curinga usando a API do Azure Resource Manager, o Bicep, o PowerShell e a CLI do Azure. O suporte para adicionar e gerenciar domínios curinga no DNS do Azure no portal do Azure não está disponível.

Adicionar um domínio curinga e uma associação de certificado

Você pode adicionar um domínio curinga seguindo etapas semelhantes para subdomínios. Para obter mais informações sobre como adicionar um subdomínio ao Azure Front Door, consulte Configurar um domínio personalizado no Azure Front Door usando o portal do Azure.

Observação

  • O DNS do Azure dá suporte a registros curinga.
  • Não é possível limpar o cache do Azure Front Door para um domínio curinga. Você precisa especificar um subdomínio ao limpar o cache.

Para aceitar o tráfego HTTPS em seu domínio curinga, você deve habilitar o HTTPS nele. A associação de certificado para um domínio curinga requer um certificado curinga. Ou seja, o nome da entidade do certificado também deve ter o domínio curinga.

Observação

  • No momento, apenas usar sua própria opção de certificado SSL personalizado está disponível para habilitar HTTPS para domínios curinga. Os certificados gerenciados do Azure Front Door não podem ser usados para domínios curinga.
  • Você pode optar por usar o mesmo certificado curinga de Azure Key Vault ou de certificados gerenciados do Azure Front Door para subdomínios.
  • Se você quiser adicionar um subdomínio do domínio curinga já validado no perfil padrão do Azure Front Door Standard ou Premium, a validação de domínio será aprovada automaticamente.
  • Se um domínio curinga for validado e já tiver sido adicionado a um perfil, um subdomínio de nível único ainda poderá ser adicionado a outro perfil, contanto que também seja validado.

Definir um subdomínio explicitamente

Você pode adicionar quantos subdomínios de nível único do domínio curinga desejar. Por exemplo, para o domínio curinga *.contoso.com, você também pode adicionar subdomínios ao seu perfil do Azure Front Door para image.contosto.com, cart.contoso.com e assim por diante. A configuração especificada explicitamente para o subdomínio tem precedência sobre a configuração do domínio curinga.

Talvez seja necessário adicionar explicitamente subdomínios nestas situações:

  • Você precisa definir uma rota diferente para um subdomínio do que o restante dos domínios (do domínio curinga). Por exemplo, seus clientes podem usar subdomínios como customer1.contoso.com, customer2.contoso.com e assim por diante, e esses subdomínios devem ser roteados para os servidores de aplicativos principais. No entanto, talvez você também queira rotear images.contoso.com para um contêiner de blob do Armazenamento do Azure.
  • Você precisa usar uma política de WAF diferente para um subdomínio específico.

Subdomínios como www.image.contoso.com não são um subdomínio de nível único de *.contoso.com.

Adicionando domínios curinga

Você pode adicionar um domínio curinga na seção para hosts ou domínios de front-end. Semelhante aos subdomínios, o Azure Front Door (clássico) valida que há um mapeamento de registro CNAME para seu domínio curinga. Esse mapeamento DNS (Sistema de Nomes de Domínio) pode ser um mapeamento de registro CNAME direto, como *.contoso.com mapeado para endpoint.azurefd.net. Ou você pode usar o mapeamento temporário afdverify. Por exemplo, afdverify.contoso.com mapeado para afdverify.endpoint.azurefd.net valida o mapa de registros CNAME para o curinga.

Observação

O DNS do Azure dá suporte a registros curinga.

Você pode adicionar quantos subdomínios de nível único do domínio curinga em hosts front-end, até o limite dos hosts front-end. Essa função pode ser necessária para:

  • Definir uma rota diferente para um subdomínio do que o restante dos domínios (do domínio curinga).

  • Ter uma política de WAF diferente para um subdomínio específico. Por exemplo, *.contoso.com permite adicionar foo.contoso.com sem ter que provar novamente a propriedade do domínio. Mas isso não permite foo.bar.contoso.com porque não é um subdomínio de nível único do *.contoso.com. Para adicionar foo.bar.contoso.com sem validação de propriedade de domínio adicional, é necessário adicionar *.bar.contoso.com.

Você pode adicionar domínios curinga e seus subdomínios com determinadas limitações:

  • Se um domínio curinga for adicionado a um perfil do Azure Front Door (clássico):
    • O domínio curinga não pode ser adicionado a nenhum outro perfil do Azure Front Door (clássico).
    • Os subdomínios de primeiro nível do domínio curinga não podem ser adicionados a outro perfil do Azure Front Door (clássico) ou a um perfil de rede de distribuição de conteúdo do Azure.
  • Se um subdomínio de um domínio curinga já estiver adicionado a um perfil do Azure Front Door (clássico) ou a um perfil de Rede de Distribuição de Conteúdo do Azure, o domínio curinga não poderá ser usado para outro perfil do Azure Front Door (clássico).
  • Se dois perfis (Azure Front Door ou Rede de Distribuição de Conteúdo do Azure) tiverem vários subdomínios de um domínio raiz, os domínios curinga não poderão ser adicionados a nenhum dos perfis.

Associação de certificado

Para aceitar o tráfego HTTPS em seu domínio curinga, você deve habilitar o HTTPS nele. A associação de certificado para um domínio curinga requer um certificado curinga. Ou seja, o nome da entidade do certificado também deve ter o domínio curinga.

Observação

No momento, apenas usar sua própria opção de certificado SSL personalizado está disponível para habilitar HTTPS para domínios curinga. Os certificados gerenciados do Azure Front Door não podem ser usados para domínios curinga.

Você pode optar por usar o mesmo certificado curinga de Azure Key Vault ou de certificados gerenciados do Azure Front Door para subdomínios.

Se um subdomínio for adicionado a um domínio curinga que já tenha um certificado associado a ele, você não poderá desabilitar o HTTPS para o subdomínio. O subdomínio usa a associação de certificado para o domínio curinga, a menos que uma Key Vault diferente ou o certificado gerenciado do Azure Front Door a substitua.

Políticas do WAF

As políticas de WAF podem ser anexadas a domínios curinga, semelhante a outros domínios. Uma política de WAF diferente pode ser aplicada a um subdomínio de um domínio curinga. Os subdomínios herdam automaticamente a política de WAF do domínio curinga se não houver nenhuma política de WAF explícita associada ao subdomínio. No entanto, se o subdomínio for adicionado a um perfil diferente do perfil de domínio curinga, o subdomínio não poderá herdar a política de WAF associada ao domínio curinga.

As políticas de WAF podem ser anexadas a domínios curinga, semelhante a outros domínios. Uma política de WAF diferente pode ser aplicada a um subdomínio de um domínio curinga. Para os subdomínios, você deve especificar a política de WAF a ser usada mesmo que seja a mesma política que o domínio curinga. Os subdomínios não herdam automaticamente a política de WAF do domínio curinga.

Se não quiser que uma política de WAF seja executada para um subdomínio, você poderá criar uma política de WAF vazia sem conjuntos de regras gerenciados ou personalizados.

Rotas

Ao configurar uma rota, você pode selecionar um domínio curinga como uma origem. Você também pode ter um comportamento de rota diferente para domínios e subdomínios curinga. O Azure Front Door escolhe a correspondência mais específica para o domínio em diferentes rotas. Para obter mais informações, consulte Como é feita a correspondência entre as solicitações e uma regra de roteamento.

Importante

Você precisa ter padrões de caminho correspondentes em suas rotas ou seus clientes verão falhas.

Por exemplo, suponha que você tenha duas regras de roteamento:

  • Rota 1 (*.foo.com/* mapeado para o grupo de origem A)
  • Rota 2 (bar.foo.com/somePath/* mapeado para o grupo de origem B). Se uma solicitação chegar para bar.foo.com/anotherPath/*, o Azure Front Door selecionará a rota 2 com base em uma correspondência de domínio mais específica, apenas para não encontrar padrões de caminho correspondentes entre as rotas.

Regras de roteamento

Ao configurar uma regra de roteamento, você pode selecionar um domínio curinga como um host de front-end. Você também pode ter um comportamento de rota diferente para domínios e subdomínios curinga. O Azure Front Door escolhe a correspondência mais específica para o domínio em diferentes rotas. Para obter mais informações, consulte Como é feita a correspondência entre as solicitações e uma regra de roteamento.

Importante

Você precisa ter padrões de caminho correspondentes em suas rotas ou seus clientes verão falhas.

Por exemplo, suponha que você tenha duas regras de roteamento:

  • Rota 1 (*.foo.com/* mapeado para o pool de back-end A)
  • Rota 2 (bar.foo.com/somePath/* mapeado para o pool de back-end B). Se uma solicitação chegar para bar.foo.com/anotherPath/*, o Azure Front Door selecionará a rota 2 com base em uma correspondência de domínio mais específica, apenas para não encontrar padrões de caminho correspondentes entre as rotas.

Próximas etapas