Laboratório de Troubleshooting: Configure Azure DNS
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que VMs em uma VNet chamada vnet-app-eastus não conseguem resolver nomes de outras VMs na mesma VNet usando o sufixo app.internal. A zona DNS privada app.internal existe na assinatura e contém registros A corretos para todas as VMs relevantes. O time informa que a zona foi criada há três dias e funcionou normalmente durante dois dias antes de parar.
A investigação inicial revela as seguintes informações:
Zona privada: app.internal
Registros A presentes: vm-web, vm-api, vm-db (todos corretos)
VNet: vnet-app-eastus (região: East US)
Número de VMs na VNet: 14
NSG da subnet: sem regras bloqueando porta 53
Ao verificar os links de VNet da zona privada, o administrador encontra:
Virtual network links:
Nome: link-vnet-app
VNet: vnet-app-eastus
Status: Unknown
Auto-registration: Enabled
Registration VNets count: 1
O link foi recriado ontem pelo time de rede, que também alterou o prefixo de endereçamento da VNet de 10.1.0.0/16 para 10.2.0.0/16 durante uma janela de manutenção.
Qual é a causa raiz da falha na resolução de nomes?
A) O NSG da subnet está bloqueando consultas DNS na porta 53, apesar de não aparecer explicitamente nas regras listadas por conta de herança de regras de nível de VNet.
B) O link de VNet está com status Unknown porque foi recriado recentemente e ainda está em processo de provisionamento; enquanto não atingir Succeeded, a resolução via zona privada não funciona.
C) Com auto-registration habilitado e 14 VMs na VNet, a zona privada atingiu o limite de registros automáticos, causando falha silenciosa na resolução.
D) A alteração do prefixo de endereçamento da VNet durante a manutenção corrompeu os registros A existentes na zona privada, que agora apontam para IPs fora do novo range.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o perfil do Azure Traffic Manager que recebia tráfego para contoso.com foi configurado como alvo de um registro CNAME no apex da zona (@) hospedada no Azure DNS. A operação foi aceita via uma ferramenta de terceiros que não validou a restrição de apex, resultando em um estado inválido na zona que causa falha de resolução para o domínio raiz.
O ambiente possui as seguintes restrições:
- O domínio
contoso.comé usado em produção com alto volume de acesso - A equipe não tem permissão para modificar diretamente os registros via portal do Azure; as alterações exigem aprovação em um processo de change management com SLA de 4 horas
- Existe um registro alias configurado para
www.contoso.comapontando para o mesmo perfil do Traffic Manager, e esse registro está funcionando corretamente - O time de segurança exige que qualquer alteração em zonas DNS públicas seja registrada com justificativa antes de ser aplicada
Qual é a ação correta a tomar neste momento?
A) Remover imediatamente o registro CNAME do apex via CLI do Azure usando credenciais de emergência, sem aguardar o processo de change management, pois o impacto em produção justifica a exceção.
B) Replicar a configuração do registro alias funcional de www.contoso.com diretamente para @, substituindo o CNAME inválido, usando o mesmo processo de aprovação existente, e iniciar o change request imediatamente para respeitar o SLA de 4 horas.
C) Criar uma nova zona DNS para contoso.com em paralelo, migrar todos os registros para ela e atualizar o registrador externo, evitando a necessidade de alterar a zona com problema.
D) Aguardar a resolução automática do estado inválido, pois o Azure DNS possui mecanismos de autocorreção que detectam registros CNAME em apex e os convertem para o formato correto após um ciclo de sincronização.
Cenário 3 — Causa Raiz
Um desenvolvedor relata que a URL api.dev.contoso.com não resolve a partir de sua máquina local fora do ambiente Azure. A equipe de infraestrutura afirma que a entrada foi criada corretamente. O administrador coleta as seguintes informações durante a investigação:
# Executado na máquina do desenvolvedor (fora do Azure)
$ nslookup api.dev.contoso.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find api.dev.contoso.com: NXDOMAIN
# Executado em uma VM dentro da VNet vnet-dev no Azure
$ nslookup api.dev.contoso.com
Server: 168.63.129.16
Address: 168.63.129.16#53
Name: api.dev.contoso.com
Address: 10.10.5.20
O administrador verifica as zonas existentes no Azure DNS:
Zonas encontradas na assinatura:
contoso.com (pública)
dev.contoso.com (privada, vinculada a vnet-dev)
A zona pública contoso.com possui os seguintes registros:
www CNAME contoso.azurewebsites.net
@ A 20.10.50.100
A equipe menciona que o certificado TLS de api.dev.contoso.com foi renovado na semana passada sem problemas.
Qual é a causa raiz da falha observada na máquina do desenvolvedor?
A) O resolver público 8.8.8.8 está bloqueado por uma política de firewall corporativo, impedindo que consultas externas cheguem ao DNS autoritativo da zona pública.
B) A zona dev.contoso.com foi criada como zona privada, portanto seus registros não são visíveis para resolvers externos; como não há registros para dev.contoso.com na zona pública, o domínio não resolve fora do Azure.
C) A ausência de um registro NS para dev na zona pública contoso.com impede a delegação, mas os registros existem e resolvem corretamente; o problema é cache negativo no resolver do desenvolvedor.
D) O registro A de api.dev.contoso.com aponta para um IP privado (10.10.5.20), que não é roteável pela internet, fazendo com que a resolução retorne NXDOMAIN em resolvers externos.
Cenário 4 — Sequência de Diagnóstico
Uma equipe recebe o seguinte relato: "Criamos uma zona DNS privada nova e registros que deveriam ser resolvidos dentro da VNet não funcionam."
O administrador dispõe dos seguintes passos de investigação:
- Verificar se a VM que origina a consulta está usando
168.63.129.16como servidor DNS - Confirmar que o registro específico existe na zona privada com nome e tipo corretos
- Verificar se existe um link de VNet entre a zona privada e a VNet da VM, e se seu status é Succeeded
- Testar a resolução do nome a partir de uma VM dentro da VNet usando
nslookupoudig - Confirmar que a zona privada foi criada na mesma assinatura e que não há erro de digitação no nome da zona
Qual é a sequência correta de diagnóstico?
A) 1 → 2 → 3 → 5 → 4
B) 4 → 3 → 5 → 2 → 1
C) 5 → 3 → 2 → 1 → 4
D) 2 → 1 → 5 → 4 → 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no campo Status: Unknown do link de VNet. Um link de VNet para uma zona DNS privada precisa atingir o status Succeeded para que a zona seja utilizável para resolução naquela VNet. O status Unknown indica que o provisionamento ainda não foi concluído ou falhou silenciosamente, o que interrompe completamente a resolução via zona privada.
A informação sobre a alteração do prefixo de endereçamento da VNet é o ruído proposital do cenário. Modificar o espaço de endereçamento de uma VNet não afeta os registros DNS de uma zona privada; os registros A contêm IPs fixos que foram criados manualmente ou via auto-registration e não são alterados automaticamente por mudanças de range de VNet.
O distrator mais perigoso é o D, que conecta a alteração de prefixo ao problema de DNS, induzindo o administrador a investigar os registros A quando o verdadeiro problema está na camada do link. Agir com base no D levaria a uma auditoria desnecessária de dezenas de registros sem resolver a causa real. O distrator C também é plausível superficialmente, mas o limite de auto-registration por VNet no Azure DNS é de 1000 registros, não 14.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é o processo de change management com SLA de 4 horas. A ação correta é iniciar imediatamente o change request com a solução técnica já identificada (substituir o CNAME inválido por um registro alias apontando para o Traffic Manager, replicando o padrão que já funciona em www) para respeitar o SLA sem burlar o processo.
A alternativa A representa a armadilha clássica de "o fim justifica os meios": o impacto em produção cria urgência real, mas usar credenciais de emergência para contornar o change management sem aprovação viola o controle de segurança e pode ter consequências disciplinares e de auditoria mais graves do que a interrupção em si.
A alternativa C é uma solução tecnicamente válida em outros contextos, mas criar uma nova zona pública e atualizar o registrador externo implica tempo de propagação de DNS imprevisível (até 48 horas em alguns registradores), o que agravaria o impacto em produção. A alternativa D descreve uma funcionalidade que não existe; o Azure DNS não possui autocorreção de registros inválidos.
Gabarito — Cenário 3
Resposta: B
O diagnóstico é direto quando se observa o contraste entre os dois resultados de nslookup: a resolução funciona perfeitamente dentro da VNet usando o resolver interno do Azure (168.63.129.16) e falha completamente para resolvers externos. Esse comportamento é a assinatura exata de uma zona DNS privada: ela é visível apenas para VNets vinculadas a ela e é completamente invisível para a internet.
A causa raiz é que dev.contoso.com foi criada como zona privada, não pública. Para que api.dev.contoso.com seja resolvível externamente, seria necessário criar uma zona pública dev.contoso.com com os registros apropriados e adicionar registros NS de delegação na zona pública contoso.com.
A informação sobre a renovação do certificado TLS é o ruído proposital: é irrelevante para o diagnóstico de resolução DNS e foi incluída para desviar a atenção para a camada de TLS.
O distrator D representa um erro conceitual importante: NXDOMAIN significa que o nome não existe na perspectiva do resolver, não que o IP retornado é inatingível. Se o resolver externo chegasse a retornar o IP 10.10.5.20, o erro seria de conectividade, não NXDOMAIN. O próprio resultado NXDOMAIN confirma que o resolver nunca encontrou a zona.
Gabarito — Cenário 4
Resposta: C
A sequência correta é 5 → 3 → 2 → 1 → 4, que segue a lógica de diagnóstico progressivo do mais estrutural para o mais operacional:
- Passo 5: Confirmar que a zona existe com o nome correto é o pré-requisito absoluto. Uma zona com erro de digitação ou na assinatura errada invalida todos os passos seguintes.
- Passo 3: Verificar o link de VNet e seu status é o segundo passo, pois sem link funcional com status Succeeded a zona é inacessível para a VNet, independentemente dos registros.
- Passo 2: Confirmar que o registro específico existe com nome e tipo corretos elimina problemas de configuração dentro de uma zona já funcional.
- Passo 1: Verificar o servidor DNS da VM confirma que ela usa o resolver do Azure (
168.63.129.16), sem o qual a zona privada nunca seria consultada. - Passo 4: O teste prático com
nslookupoudigé o último passo, pois valida o resultado depois que todas as camadas estruturais foram verificadas.
O erro central das sequências incorretas é iniciar pelo teste prático (passo 4) antes de verificar a infraestrutura, o que pode gerar confusão: um teste negativo não informa em qual camada o problema está se as verificações estruturais não foram feitas antes.
Árvore de Troubleshooting: Configure Azure DNS
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta de diagnóstico |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se a falha de resolução ocorre dentro ou fora do Azure. A primeira bifurcação separa dois universos de diagnóstico completamente distintos: problemas em zonas privadas (visíveis apenas dentro de VNets) e problemas em zonas públicas (visíveis pela internet). Siga as perguntas fechadas em cada nó respondendo o que você observa no ambiente, sem pular etapas. Sempre que atingir um nó de validação em laranja, execute o comando indicado antes de avançar, pois ele confirma ou descarta a hipótese corrente. O caminho termina quando você chega a uma causa em vermelho seguida de uma ação em verde.