Laboratório de Troubleshooting: Map an existing custom DNS name to an App Service
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relatou que o domínio api.contoso.com para de responder corretamente toda vez que o App Service é reiniciado ou sofre um swap de slot. O ambiente usa o plano Standard S2 em uma única região. O App Service foi criado há seis meses e nunca teve IP dedicado configurado. O administrador verifica o registro DNS no provedor externo e encontra o seguinte:
api.contoso.com. 3600 IN A 40.112.72.205
O administrador também confirma que o domínio personalizado está corretamente adicionado na configuração do App Service e que o certificado TLS está ativo. Nos últimos 30 dias, houve três ocorrências do problema, sempre após operações de manutenção na plataforma.
Qual é a causa raiz do problema observado?
A) O TTL de 3600 segundos faz com que o DNS em cache aponte para o IP antigo após a reinicialização, causando janela de indisponibilidade
B) O registro A aponta para o endereço IP de entrada compartilhado do App Service, que não é estável e pode mudar após reinicializações ou operações de plataforma
C) O swap de slot invalida o certificado TLS vinculado ao domínio personalizado, interrompendo a resolução
D) O plano Standard S2 não garante IP de entrada estático e exige upgrade para Premium para uso com registros A
Cenário 2 — Decisão de Ação
A equipe identificou que o domínio portal.fabrikam.com não está respondendo. Investigando, o administrador descobre que o App Service foi excluído e recriado com um novo nome (fabrikam-portal-v2) durante uma migração de infraestrutura realizada na semana anterior. O registro DNS externo ainda aponta para o nome antigo:
portal.fabrikam.com. 300 IN CNAME fabrikam-portal.azurewebsites.net
O App Service novo está saudável, acessível via fabrikam-portal-v2.azurewebsites.net, e o domínio personalizado portal.fabrikam.com ainda não foi adicionado ao novo recurso. O time de negócios exige que o domínio volte a funcionar em no máximo 20 minutos. Alterar registros DNS no provedor externo tem propagação estimada de 5 a 10 minutos no ambiente atual.
Qual é a ação correta a tomar neste momento?
A) Atualizar o registro CNAME externo para fabrikam-portal-v2.azurewebsites.net antes de adicionar o domínio personalizado no novo App Service
B) Adicionar o domínio personalizado portal.fabrikam.com no novo App Service primeiro e, somente após a validação, atualizar o registro CNAME externo
C) Recriar o App Service com o nome original fabrikam-portal para que o registro CNAME existente volte a funcionar sem nenhuma alteração de DNS
D) Adicionar um registro A apontando para o IP do novo App Service enquanto o CNAME antigo ainda existe, criando redundância temporária
Cenário 3 — Causa Raiz
Um administrador tentou mapear shop.alpineski.com para um App Service existente. O domínio já estava sendo usado em outro sistema legado que foi desativado há dois meses. O provedor DNS externo tem os seguintes registros ativos:
shop.alpineski.com. 3600 IN CNAME alpineski-shop.azurewebsites.net
shop.alpineski.com. 3600 IN TXT ms-domain-verification=8f3a92b1c4d6e...
Ao tentar adicionar o domínio no portal do Azure, a operação falha com a seguinte mensagem:
The hostname 'shop.alpineski.com' is already assigned to another Azure resource.
Custom domain validation failed.
O administrador confirma que o App Service alpineski-shop existe, está ativo e pertence à mesma assinatura. O certificado gerenciado está configurado e a camada do plano é Premium P1v3.
Qual é a causa raiz da falha?
A) O registro TXT de verificação está associado a um App Service anterior e o Azure está rejeitando a reutilização do mesmo valor
B) O domínio shop.alpineski.com já está vinculado como domínio personalizado em outro App Service dentro da plataforma Azure, mesmo que o sistema legado tenha sido desativado
C) O plano Premium P1v3 tem conflito de validação com domínios que possuem histórico em outros planos de serviço
D) A coexistência de um registro CNAME e um registro TXT no mesmo subdomínio causa ambiguidade na validação do Azure
Cenário 4 — Sequência de Diagnóstico
Um usuário reporta que crm.woodgrove.com retorna erro 404 Not Found ao ser acessado pelo navegador. O administrador sabe que o domínio foi configurado recentemente. Os seguintes passos de investigação estão disponíveis, fora de ordem:
[P1] Verificar se o domínio personalizado está adicionado na configuração do App Service
[P2] Testar resolução DNS com: nslookup crm.woodgrove.com
[P3] Acessar o App Service diretamente via URL azurewebsites.net para confirmar que está saudável
[P4] Verificar se o registro TXT de verificação de propriedade existe no DNS externo
[P5] Confirmar se o App Service está no plano correto que suporta domínios personalizados
Qual é a sequência de diagnóstico correta?
A) P3, P2, P4, P1, P5
B) P5, P3, P2, P4, P1
C) P2, P3, P5, P4, P1
D) P3, P5, P2, P4, P1
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O sintoma central é a falha recorrente após reinicializações e operações de manutenção, não após mudanças de DNS ou expiração de cache. Isso é a pista decisiva: o problema se repete de forma previsível a cada evento de plataforma.
A causa raiz é o uso de um registro A apontando para o endereço IP de entrada compartilhado do App Service. Esse IP não é garantido como estável em planos sem IP dedicado. Operações como reinicializações, swaps de slot ou rebalanceamento de infraestrutura podem alterar o IP atribuído ao App Service, invalidando o registro A configurado externamente.
A alternativa A é o distrator com maior poder de atração: o TTL alto parece suspeito, mas ele apenas controla por quanto tempo o valor em cache é mantido. Se o IP não mudasse, o TTL seria irrelevante para o problema. O TTL elevado agravaria a duração da falha, mas não seria sua causa.
A alternativa C é tecnicamente falsa: swaps de slot não invalidam certificados TLS corretamente vinculados.
A alternativa D distorce a realidade: o suporte a IP dedicado não é uma função do tier do plano de forma tão direta quanto descrito, e essa não é a causa do comportamento observado.
O distrator mais perigoso é o A: um administrador que agisse reduzindo o TTL acharia que corrigiu o problema, mas a falha continuaria ocorrendo após cada reinicialização.
Gabarito — Cenário 2
Resposta: B
A restrição crítica aqui é a janela de 20 minutos. A sequência correta é primeiro adicionar o domínio personalizado no novo App Service e depois atualizar o DNS, não o contrário.
Se o CNAME for atualizado antes de o domínio ser adicionado ao novo App Service, haverá um intervalo em que o DNS já aponta para fabrikam-portal-v2.azurewebsites.net, mas o App Service ainda não reconhece o host portal.fabrikam.com. Requisições chegando nesse intervalo receberão erro 404 ou comportamento indefinido, prolongando a indisponibilidade.
Ao adicionar o domínio no App Service primeiro, o Azure valida e registra o vínculo. A atualização do CNAME em seguida garante que, no momento em que o tráfego começa a chegar pelo novo nome, o destino já está preparado para aceitá-lo.
A alternativa C ignora a restrição de tempo e criaria um trabalho desnecessário de recriar infraestrutura sem garantia de que o nome original estaria disponível.
A alternativa D criaria um estado incoerente: um registro A e um CNAME no mesmo nome de domínio causam comportamento imprevisível dependendo do resolvedor DNS, além de não resolver o problema estrutural.
Gabarito — Cenário 3
Resposta: B
A mensagem de erro é a pista mais objetiva: The hostname is already assigned to another Azure resource. Isso indica que o domínio shop.alpineski.com ainda está registrado como domínio personalizado em outro App Service dentro da plataforma Azure, mesmo que o sistema legado tenha sido "desativado". Desativar um sistema não significa necessariamente que o vínculo de domínio personalizado foi removido do App Service correspondente.
A informação sobre o sistema legado desativado há dois meses é a informação irrelevante propositalmente inserida: ela induz o leitor a assumir que o domínio foi liberado, quando na verdade o vínculo no App Service antigo pode ainda existir mesmo com o serviço parado ou sem uso.
A solução correta seria localizar o App Service anterior (ou seu registro remanescente) e remover o domínio personalizado de lá antes de adicioná-lo ao novo recurso.
A alternativa A atrai quem foca no registro TXT, mas o valor de verificação é gerado por App Service e pode ser reutilizado; não é ele que causa o conflito descrito na mensagem de erro.
A alternativa D é tecnicamente incorreta: a coexistência de CNAME e TXT em um subdomínio é válida e é exatamente o que o processo de mapeamento exige.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: P3, P2, P4, P1, P5.
O raciocínio diagnóstico correto parte do mais simples e elimina variáveis progressivamente:
| Passo | Ação | Justificativa |
|---|---|---|
| P3 | Acessar via .azurewebsites.net | Confirma que o App Service está saudável antes de investigar DNS |
| P2 | Testar resolução DNS | Verifica se o nome resolve e para qual destino |
| P4 | Verificar registro TXT | Confirma se a propriedade foi declarada corretamente no DNS externo |
| P1 | Verificar domínio no App Service | Confirma se o vínculo foi criado na plataforma |
| P5 | Confirmar plano do App Service | Valida restrição de SKU, que é verificação de configuração, não de estado |
Começar por P5 (plano do serviço) seria prematuro: é uma verificação de pré-requisito estático que raramente muda após a configuração inicial. Começar por P4 (registro TXT) antes de confirmar que o App Service responde seria investigar o DNS sem saber se o destino existe.
A alternativa C coloca P2 como primeiro passo, o que faz sentido superficialmente, mas ignora que validar o estado do App Service primeiro isola o problema: se o serviço não responde nem pelo nome padrão, o DNS é irrelevante.
Árvore de Troubleshooting: Map an existing custom DNS name to an App Service
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz da árvore) |
| Azul | Pergunta diagnóstica (decisão binária ou de estado) |
| Vermelho | Causa identificada (requer investigação adicional) |
| Verde | Ação recomendada ou resolução direta |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa diretamente no ambiente, sem assumir nenhuma resposta. Siga o caminho correspondente até alcançar um nó vermelho (causa) ou verde (ação). Nós laranjas indicam que uma verificação adicional é necessária antes de prosseguir. O objetivo é chegar ao nó terminal pelo caminho mais curto de evidências confirmadas, não pelo caminho mais curto de suposições.