Laboratório de Troubleshooting: Design name resolution inside a VNet
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento relata que VMs em vnet-app param de resolver nomes internos de forma intermitente durante horários de pico. O time de infraestrutura verifica o ambiente e coleta as seguintes informações:
- A VNet
vnet-appusa dois servidores DNS customizados:10.2.0.4e10.2.0.5 - Ambos os servidores são VMs com Windows Server DNS configuradas como forwarders para
168.63.129.16 - A zona DNS privada
app.internalestá vinculada à VNet com registro automático habilitado - As VMs afetadas têm aceleração de rede habilitada
- O NSG da subnet permite tráfego de saída irrestrito
10.2.0.5foi provisionada há duas semanas para aumentar a resiliência
Saída coletada de uma VM afetada durante uma falha:
C:\> nslookup svc-orders.app.internal
Server: 10.2.0.5
Address: 10.2.0.5
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to 10.2.0.5 timed-out
Em seguida, a VM tenta novamente e a resolução funciona usando 10.2.0.4.
Qual é a causa raiz do comportamento intermitente?
A) O NSG está bloqueando consultas UDP na porta 53 para 10.2.0.5 de forma seletiva durante pico de tráfego.
B) O servidor 10.2.0.5 não está configurado corretamente como forwarder para 168.63.129.16, causando falhas apenas nas consultas que chegam a ele.
C) O registro automático habilitado na zona privada está gerando conflitos de registro durante horários de pico, tornando os registros temporariamente inconsistentes.
D) A aceleração de rede nas VMs afetadas altera o comportamento de balanceamento do cliente DNS, fazendo com que 10.2.0.5 receba mais requisições do que consegue processar.
Cenário 2 — Sequência de Diagnóstico
Uma VM em vnet-hub não consegue resolver nomes de hosts on-premises. O ambiente usa:
- Um DNS forwarder em
10.0.0.10(VM Linux com Bind9) configurado na VNet - Peering entre
vnet-hubevnet-spoke - Uma zona DNS privada
azure.corpvinculada àvnet-hub - Servidores DNS on-premises em
192.168.1.10e192.168.1.11, acessíveis via ExpressRoute
O engenheiro responsável dispõe dos seguintes passos de investigação:
- Verificar se
10.0.0.10tem conectividade com192.168.1.10na porta 53 - Verificar se a VNet
vnet-hubestá configurada para usar10.0.0.10como DNS customizado - Executar
nslookup <host-on-premises> 10.0.0.10a partir da VM afetada - Verificar se o Bind9 em
10.0.0.10tem uma zona de encaminhamento configurada para o domínio on-premises - Verificar se a VM afetada consegue pingar
10.0.0.10
Qual é a sequência correta de investigação?
A) 5, 2, 3, 4, 1
B) 2, 5, 3, 4, 1
C) 3, 1, 4, 2, 5
D) 5, 3, 2, 4, 1
Cenário 3 — Causa Raiz
Uma arquiteta recebe um chamado: VMs em vnet-spoke não conseguem resolver registros da zona DNS privada corp.internal. Ela acessa o portal e documenta o estado atual:
| Recurso | Configuração |
|---|---|
| Zona DNS privada | corp.internal |
Vínculo com vnet-hub | Presente, registro automático habilitado |
Vínculo com vnet-spoke | Presente, registro automático desabilitado |
Peering vnet-hub / vnet-spoke | Ativo, bidirecional |
DNS customizado em vnet-spoke | Nenhum (usando padrão do Azure) |
DNS customizado em vnet-hub | Nenhum (usando padrão do Azure) |
A arquiteta testa a partir de uma VM em vnet-hub e a resolução funciona perfeitamente. O peering foi configurado há três dias sem alterações desde então.
# Teste a partir de VM em vnet-spoke
$ nslookup svc-auth.corp.internal
Server: 168.63.129.16
Address: 168.63.129.16#53
** server can't find svc-auth.corp.internal: NXDOMAIN
Qual é a causa raiz?
A) O peering bidirecional entre vnet-hub e vnet-spoke não propaga automaticamente o acesso a zonas DNS privadas vinculadas à VNet parceira.
B) O registro automático desabilitado no vínculo com vnet-spoke impede que qualquer registro da zona seja resolvido a partir dessa VNet.
C) O resolvedor 168.63.129.16 retorna NXDOMAIN para VNets que não possuem DNS customizado configurado, exigindo que um forwarder seja adicionado.
D) O vínculo com vnet-spoke foi criado depois do peering, e o Azure exige que vínculos de zona DNS privada sejam criados antes do peering para funcionarem corretamente.
Cenário 4 — Decisão de Ação
A causa foi identificada: a VNet vnet-prod está configurada com um servidor DNS customizado (10.1.0.20) que não possui uma regra de encaminhamento condicional para a zona privada payments.internal. Como resultado, todas as VMs em vnet-prod resolvem nomes externos corretamente, mas falham ao resolver qualquer registro em payments.internal.
O contexto atual é:
- O ambiente está em produção com dezenas de VMs ativas
- A alteração do DNS customizado da VNet força uma renovação de lease DHCP em todas as VMs
- A janela de manutenção programada ocorre em 6 horas
- O servidor
10.1.0.20é gerenciado pela equipe de segurança, que confirma ter acesso imediato para aplicar configurações - Um incidente aberto classifica o impacto como moderado, sem interrupção total de serviço
Qual é a ação correta a tomar neste momento?
A) Remover o DNS customizado da VNet imediatamente, revertendo para o resolvedor padrão do Azure, para restaurar a resolução da zona privada sem aguardar a janela de manutenção.
B) Solicitar à equipe de segurança que adicione o encaminhamento condicional para payments.internal apontando para 168.63.129.16 no servidor 10.1.0.20, sem alterar a configuração da VNet.
C) Criar um segundo vínculo da zona payments.internal com a vnet-prod com registro automático habilitado, corrigindo a resolução sem precisar alterar o servidor DNS.
D) Aguardar a janela de manutenção e, durante ela, substituir o servidor DNS customizado por uma nova VM com a configuração correta de encaminhamento.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva no enunciado é que 10.2.0.5 foi provisionada recentemente e que as falhas ocorrem especificamente quando as consultas chegam a esse servidor. O cliente DNS tenta 10.2.0.5, aguarda o timeout de 2 segundos, e na tentativa seguinte usa 10.2.0.4, onde a resolução funciona normalmente.
O comportamento intermitente não é aleatoriedade: é o resultado previsível de dois servidores DNS com configurações diferentes, onde apenas um deles foi configurado corretamente como forwarder para 168.63.129.16. Como o cliente alterna entre os dois servidores listados na configuração da VNet, as falhas aparecem em aproximadamente metade das consultas, mais visíveis em horário de pico devido ao volume.
A informação irrelevante é a aceleração de rede. Esse recurso afeta o desempenho de rede da VM em camadas de virtualização, mas não interfere na lógica de seleção de servidor DNS pelo cliente.
O distrator mais perigoso é a alternativa A: atribuir o problema ao NSG pode levar o engenheiro a criar regras permissivas desnecessárias, consumindo tempo sem resolver a causa real. Verificar a configuração de encaminhamento no servidor recém-adicionado é o primeiro passo correto.
Gabarito — Cenário 2
Resposta: B
A sequência correta é: 2, 5, 3, 4, 1.
O raciocínio diagnóstico parte do mais amplo para o mais específico, eliminando camadas progressivamente:
- Passo 2 primeiro: confirmar que a VNet está realmente usando
10.0.0.10como DNS customizado. Se a VNet ainda usar o resolvedor padrão do Azure, nenhum forwarder funcionará e os demais passos são irrelevantes. - Passo 5 em seguida: verificar conectividade básica com o forwarder. Se a VM não alcança
10.0.0.10, o problema é de roteamento, não de DNS. - Passo 3: testar a resolução diretamente contra o forwarder para isolar se o problema está na cadeia cliente/forwarder ou no forwarder/upstream.
- Passo 4: verificar se o Bind9 tem a zona de encaminhamento correta para o domínio on-premises. Essa é a causa mais provável dado o cenário.
- Passo 1 por último: confirmar que o forwarder consegue alcançar os servidores on-premises na porta 53. Esse passo só faz sentido após confirmar que a cadeia anterior está íntegra.
A alternativa A parece lógica por começar pela conectividade, mas testar o ping antes de confirmar que o DNS customizado está configurado na VNet inverte a prioridade diagnóstica.
Gabarito — Cenário 3
Resposta: A
O vínculo da zona DNS privada corp.internal com vnet-spoke existe e está ativo. O VNet Peering também está ativo e bidirecional. Ainda assim, a VM em vnet-spoke consulta 168.63.129.16 e recebe NXDOMAIN.
A causa é que o vínculo de zona DNS privada é o mecanismo pelo qual o resolvedor 168.63.129.16 sabe que deve responder consultas daquela zona para uma determinada VNet. O fato de vnet-hub e vnet-spoke estarem pareadas não altera essa lógica: cada VNet precisa ter seu próprio vínculo com a zona para que o resolvedor responda suas consultas.
A informação sobre o peering ter sido configurado há três dias é irrelevante e funciona como distrator temporal, sugerindo que o problema pode ter surgido com o tempo. Na prática, o comportamento não mudou porque a causa não tem relação com o tempo de existência do peering.
A alternativa B é o distrator mais comum: confundir a função do registro automático (que controla se VMs são registradas na zona) com a capacidade de resolução (que depende apenas do vínculo existir). O vínculo com vnet-spoke existe, então VMs nessa VNet poderiam resolver registros da zona, mas apenas se o vínculo fosse funcional, o que requer que o vínculo esteja presente na VNet correta.
Gabarito — Cenário 4
Resposta: B
A causa já foi identificada: o servidor DNS customizado 10.1.0.20 não tem encaminhamento condicional para payments.internal. A solução correta, dado o conjunto de restrições, é corrigir a configuração do servidor sem alterar a configuração da VNet.
Adicionar o encaminhamento condicional diretamente no servidor 10.1.0.20 resolve o problema sem impacto nas VMs em produção: nenhuma alteração no DHCP da VNet é necessária, nenhuma renovação de lease é forçada, e a equipe de segurança confirmou disponibilidade imediata para aplicar a mudança.
A alternativa A é tecnicamente válida em outro contexto, mas aqui é destrutiva: remover o DNS customizado não só causa renovação de DHCP em todas as VMs, como também desfaz qualquer outra configuração de resolução que o servidor 10.1.0.20 possa estar fornecendo corretamente para outros domínios.
A alternativa C representa um equívoco conceitual frequente: criar um segundo vínculo da zona com a VNet não resolve o problema, porque o problema não é o vínculo, é o encaminhamento no servidor DNS customizado. Com um DNS customizado configurado, as VMs não consultam 168.63.129.16 diretamente; elas consultam 10.1.0.20.
A alternativa D ignora que a equipe de segurança tem acesso imediato e que a correção pode ser feita sem janela de manutenção, postergando desnecessariamente a resolução de um incidente ativo.
Árvore de Troubleshooting: Design name resolution inside a VNet
Legenda:
- Azul escuro: sintoma inicial, ponto de entrada do diagnóstico
- Azul: pergunta diagnóstica, verificação de estado ou condição
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
- Laranja: validação ou verificação intermediária antes de concluir o diagnóstico
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma e siga as ramificações respondendo cada pergunta com base no que é observável no ambiente. Cada resposta elimina um conjunto de hipóteses e direciona para a próxima verificação mais específica. Não avance para uma ação verde sem ter percorrido o caminho diagnóstico completo: agir sobre a causa errada em um ambiente de DNS pode introduzir falhas em cadeia que obscurecem a causa original.