Domínios curinga no Azure Front Door
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 migrar seus perfis do Azure Front Door (clássico) para a camada Azure Front Door Standard ou Premium até março de 2027. Para obter mais informações, consulte Aposentadoria (clássica) do Azure Front Door.
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 seu perfil do Azure Front Door. Não é necessário 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 *.contoso.com
curinga .
Os domínios curinga oferecem várias vantagens, incluindo:
- Você não precisa integrar cada subdomínio em seu perfil do Azure Front Door. Por exemplo, suponha que você crie novos subdomínios a cada cliente e encaminhe todas as solicitações dos clientes para um único 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.
- Não é necessário 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 única política de firewall de aplicativo Web (WAF) para todos os seus subdomínios.
Comumente, os domínios curinga são usados para oferecer suporte a soluções SaaS (software como serviço) e outros aplicativos multilocatário. Ao criar esses tipos de aplicativos, você precisa dar atenção especial à forma como encaminha o tráfego para seus servidores de origem. Para obter mais informações, consulte Usar o Azure Front Door em uma solução multilocatário.
Nota
Ao usar o DNS do Azure para gerenciar os registros DNS do seu 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 DNS do Azure no portal do Azure não está disponível.
Adicionar um domínio curinga e vinculaçã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.
Nota
- O DNS do Azure suporta registos de carateres universais.
- Não é possível limpar o cache da Porta da Frente do Azure para um domínio curinga. Você deve especificar um subdomínio ao limpar o cache.
Para aceitar tráfego HTTPS em seu domínio curinga, você deve habilitar HTTPS no domínio curinga. A associação de certificado para um domínio curinga requer um certificado curinga. Ou seja, o nome do assunto do certificado também deve ter o domínio curinga.
Nota
- Atualmente, apenas usando 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 do 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 que já esteja validado no perfil 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, desde que também seja validado.
Definir um subdomínio explicitamente
Você pode adicionar quantos subdomínios de nível único do curinga desejar. Por exemplo, para o domínio *.contoso.com
curinga, você também pode adicionar subdomínios ao seu perfil da Porta da Frente do Azure 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 resto 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 todos esses subdomínios devem ser roteados para seus principais servidores de aplicativos. No entanto, você também pode querer rotearimages.contoso.com
para um contêiner de blob de Armazenamento do Azure. - Você precisa usar uma política 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 do *.contoso.com
.
Adicionando domínios curinga
Você pode adicionar um domínio curinga na seção para hosts front-end ou domínios. Semelhante aos subdomínios, o Azure Front Door (clássico) valida que há 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
validar o mapa de registro CNAME para o curinga.
Nota
O DNS do Azure suporta registos de carateres universais.
Você pode adicionar tantos subdomínios de nível único do domínio curinga em hosts front-end, até o limite dos hosts front-end. Esta funcionalidade pode ser necessária para:
Definir uma rota diferente para um subdomínio do que o resto dos domínios (do domínio curinga).
Ter uma política WAF diferente para um subdomínio específico. Por exemplo,
*.contoso.com
permite adicionarfoo.contoso.com
sem ter que provar novamente a propriedade do domínio. Mas não permitefoo.bar.contoso.com
porque não é um subdomínio de nível único do*.contoso.com
. Para adicionarfoo.bar.contoso.com
sem validação de propriedade de domínio extra,*.bar.contoso.com
precisa ser adicionado.
Você pode adicionar domínios curinga e seus subdomínios com certas 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 (clássico) do Azure Front Door.
- 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 da Rede de Entrega de Conteúdo do Azure.
- Se um subdomínio de um domínio curinga já tiver sido adicionado a um perfil do Azure Front Door (clássico) ou a um perfil da Rede de Entrega 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 Azure Content Delivery Network) tiverem vários subdomínios de um domínio raiz, os domínios curinga não poderão ser adicionados a nenhum dos perfis.
Vinculação de certificado
Para aceitar tráfego HTTPS em seu domínio curinga, você deve habilitar HTTPS no domínio curinga. A associação de certificado para um domínio curinga requer um certificado curinga. Ou seja, o nome do assunto do certificado também deve ter o domínio curinga.
Nota
Atualmente, apenas usando 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 do Azure Key Vault ou de certificados gerenciados do Azure Front Door para subdomínios.
Se um subdomínio for adicionado para um domínio curinga que já tenha um certificado associado a ele, não será possível desabilitar o HTTPS para o subdomínio. O subdomínio usa a associação de certificado para o domínio curinga, a menos que um certificado gerenciado diferente do Cofre da Chave ou da Porta da Frente do Azure o substitua.
Políticas do WAF
As políticas WAF podem ser anexadas a domínios curinga, semelhantes a outros domínios. Uma política WAF diferente pode ser aplicada a um subdomínio de um domínio curinga. Os subdomínios herdam automaticamente a política WAF do domínio curinga se não houver nenhuma política 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 WAF associada ao domínio curinga.
As políticas WAF podem ser anexadas a domínios curinga, semelhantes a outros domínios. Uma política WAF diferente pode ser aplicada a um subdomínio de um domínio curinga. Para os subdomínios, você deve especificar a política WAF a ser usada, mesmo que seja a mesma política do domínio curinga. Os subdomínios não herdam automaticamente a política WAF do domínio curinga.
Se não quiser que uma política WAF seja executada para um subdomínio, você pode criar uma política WAF vazia sem conjuntos de regras gerenciadas ou personalizadas.
Rotas
Ao configurar uma rota, você pode selecionar um domínio curinga como 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 as solicitações são correspondidas a uma regra de roteamento.
Importante
Você deve 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/*
mapeada para o grupo de origem A) - Rota 2 (
bar.foo.com/somePath/*
mapeada para o grupo de origem B) Se uma solicitação chegar parabar.foo.com/anotherPath/*
o , 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 nas rotas.
Regras de encaminhamento
Ao configurar uma regra de roteamento, você pode selecionar um domínio curinga como host 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 as solicitações são correspondidas a uma regra de roteamento.
Importante
Você deve 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/*
mapeada para o pool de back-end A) - Rota 2 (
bar.foo.com/somePath/*
mapeada para o pool de back-end B) Se uma solicitação chegarbar.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 nas rotas.
Próximos passos
- Saiba como criar um perfil do Azure Front Door.
- Saiba como adicionar um domínio personalizado à sua Porta da Frente do Azure.
- Saiba como habilitar HTTPS em um domínio personalizado.
- Saiba como criar um perfil do Azure Front Door.
- Saiba como adicionar um domínio personalizado à sua Porta da Frente do Azure.
- Saiba como habilitar HTTPS em um domínio personalizado.