Laboratório de Troubleshooting: Configure DNS settings for a VNet
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que VMs em uma VNet específica não conseguem resolver nomes de recursos internos da zona DNS privada apps.internal, mas resolvem normalmente nomes públicos como microsoft.com e endpoints do Azure como *.blob.core.windows.net.
O ambiente está configurado da seguinte forma:
VNet: vnet-prod-eastus
DNS Servers: 10.1.0.4 (servidor DNS customizado, Windows Server 2022)
Zona DNS privada: apps.internal
Link: vnet-prod-eastus | Autoregistro: habilitado | Status: Provisionado
Servidor DNS customizado (10.1.0.4):
Forwarders configurados: 8.8.8.8, 8.8.4.4
Zona local: (nenhuma)
A equipe informa que o servidor DNS customizado foi implantado há três semanas e está saudável. A zona privada apps.internal foi criada há dois dias. O link entre a zona e a VNet aparece com status Provisionado no portal. Um teste de conectividade com ping 10.1.0.4 a partir das VMs retorna resposta normalmente.
# Executado a partir de vm-prod-01
nslookup api.apps.internal
Server: 10.1.0.4
Address: 10.1.0.4
*** 10.1.0.4 can't find api.apps.internal: Non-existent domain
Qual é a causa raiz da falha na resolução de apps.internal?
A) O link de rede virtual foi criado com autoregistro habilitado, o que impede a resolução de registros criados manualmente na zona privada.
B) O servidor DNS customizado não está encaminhando consultas para 168.63.129.16, de modo que as consultas de apps.internal nunca chegam ao resolvedor do Azure.
C) A zona DNS privada apps.internal ainda não concluiu a replicação global após sua criação há dois dias.
D) O autoregistro está habilitado no link, mas as VMs não foram reiniciadas após a vinculação, então nenhum registro A foi criado na zona.
Cenário 2 — Decisão de Ação
A equipe de rede identificou que VMs em vnet-hub-westus falham ao resolver nomes de uma zona DNS privada recém-vinculada. A causa foi confirmada: o servidor DNS customizado da VNet encaminha todas as consultas para servidores públicos externos, sem nenhuma regra de encaminhamento condicional para 168.63.129.16.
O contexto operacional é o seguinte:
- O servidor DNS customizado é compartilhado por quatro VNets de produção
- Há uma janela de manutenção disponível em 48 horas
- O time de segurança bloqueou alterações de configuração em servidores de produção fora da janela de manutenção
- As VMs afetadas são de desenvolvimento e não estão em produção
- O servidor DNS customizado está fora do escopo de rollback imediato
Qual é a ação correta a tomar neste momento?
A) Alterar imediatamente os forwarders do servidor DNS customizado para incluir 168.63.129.16 como destino para apps.internal, pois é uma mudança de baixo risco.
B) Remover o servidor DNS customizado da configuração da VNet de desenvolvimento e substituir pelo DNS padrão do Azure até a janela de manutenção.
C) Criar registros A manuais na zona DNS privada para os endpoints necessários, como solução temporária, enquanto aguarda a janela de manutenção para corrigir o forwarder.
D) Desvincular a zona DNS privada da VNet afetada e recriar o link após a janela de manutenção, quando o forwarder for corrigido.
Cenário 3 — Causa Raiz
Uma empresa opera um ambiente híbrido com resolução DNS centralizada on-premises. Após uma migração parcial para o Azure, as VMs na VNet vnet-spoke-01 passaram a falhar intermitentemente ao resolver hostnames de outros recursos do Azure, incluindo nomes como vm-backend.internal.cloudapp.net.
A configuração atual é:
VNet: vnet-spoke-01
DNS Servers:
- 10.0.0.10 (DNS on-premises primário, via ExpressRoute)
- 10.0.0.11 (DNS on-premises secundário, via ExpressRoute)
Servidor DNS on-premises:
Forwarders: 168.63.129.16
Zonas locais: corp.local, internal.corp.com
ExpressRoute Circuit: Status = Provisioned, BGP = Connected
As falhas são intermitentes e ocorrem principalmente no período entre 18h e 22h. O time de rede confirma que o circuito ExpressRoute apresenta latência elevada nesse intervalo, chegando a 380ms em picos. Fora desse horário, a resolução DNS funciona normalmente. Não há zonas DNS privadas configuradas para internal.cloudapp.net.
# Log coletado durante falha (20h14)
Event: DNS query timeout
Query: vm-backend.internal.cloudapp.net
Resolver: 10.0.0.10
Elapsed: 5001ms
Result: SERVFAIL
Qual é a causa raiz das falhas intermitentes de resolução?
A) O servidor DNS on-premises não tem autoridade sobre internal.cloudapp.net e retorna SERVFAIL porque não encontra a zona localmente.
B) O forwarder 168.63.129.16 configurado on-premises está indisponível nos horários de pico, causando timeout nas consultas encaminhadas.
C) A latência elevada no circuito ExpressRoute durante o período de pico causa timeout nas consultas DNS que percorrem o caminho on-premises antes de chegar ao resolvedor do Azure.
D) O Azure não permite resolução de internal.cloudapp.net por meio de servidores DNS externos, exigindo que a consulta parta diretamente do resolvedor da VNet.
Cenário 4 — Sequência de Diagnóstico
Uma VM recém-provisionada em vnet-dev-brazilsouth não consegue resolver nenhum nome, nem público nem privado. A equipe precisa diagnosticar o problema e executa os seguintes passos de investigação, apresentados fora de ordem:
[P] Verificar se a NIC da VM recebeu um endereço IP válido via DHCP
[Q] Executar nslookup microsoft.com a partir da VM e observar o servidor DNS retornado
[R] Verificar a configuração de DNS Servers na VNet no portal do Azure
[S] Testar conectividade com ping 168.63.129.16 a partir da VM
[T] Confirmar se o servidor DNS customizado listado na VNet está acessível e respondendo
Qual sequência de investigação segue a lógica correta de diagnóstico progressivo?
A) R, Q, S, T, P
B) P, R, Q, S, T
C) Q, R, P, T, S
D) S, P, R, Q, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O sintoma central é a falha na resolução de apps.internal mesmo com o link da zona privada ativo e o servidor DNS customizado acessível. A pista decisiva está na configuração dos forwarders do servidor DNS: eles apontam para 8.8.8.8 e 8.8.4.4, servidores DNS públicos do Google que não têm nenhum conhecimento sobre zonas DNS privadas do Azure.
Quando uma VM envia uma consulta para api.apps.internal, ela chega ao servidor customizado 10.1.0.4. Como esse servidor não tem a zona localmente e seus forwarders são públicos, a consulta vai para o Google, que retorna NXDOMAIN. O resolvedor do Azure em 168.63.129.16 nunca é consultado, e portanto o vínculo com a zona privada é completamente irrelevante neste fluxo.
A informação sobre o ping funcionar para 10.1.0.4 é deliberadamente irrelevante: confirma apenas que o servidor está acessível na camada de rede, não que ele encaminha DNS corretamente. O status Provisionado do link também é irrelevante para este diagnóstico.
A alternativa D representa o erro de raciocínio mais comum: confundir autoregistro (criação de registros) com resolução de nomes. Mesmo sem registros criados via autoregistro, registros adicionados manualmente na zona deveriam ser resolvíveis, o que não acontece aqui. O distrator mais perigoso é o A: agir com base nele levaria a desabilitar o autoregistro sem corrigir nada, mantendo a falha intacta.
Gabarito — Cenário 2
Resposta: B
A causa já está identificada: o servidor DNS customizado não encaminha para 168.63.129.16. A restrição crítica é que alterações no servidor de produção compartilhado estão bloqueadas fora da janela de manutenção. As VMs afetadas são de desenvolvimento, não de produção.
A ação correta é substituir temporariamente o DNS customizado pelo DNS padrão do Azure na VNet de desenvolvimento. Essa mudança é feita na configuração da VNet (não no servidor DNS), está dentro do escopo da equipe de rede, não afeta as outras quatro VNets de produção e resolve o problema imediatamente para o ambiente de desenvolvimento sem violar nenhuma restrição.
A alternativa A ignora explicitamente o bloqueio de segurança para alterações em servidores de produção fora da janela. A alternativa C é tecnicamente válida como paliativo, mas não corrige a causa e exige manutenção manual contínua. A alternativa D é destrutiva sem necessidade: desvincular e recriar o link não resolve o problema de forwarder e gera retrabalho desnecessário.
Gabarito — Cenário 3
Resposta: C
O sintoma é intermitência correlacionada a um horário específico (18h22h), e o log mostra timeout de 5001ms. O dado operacional decisivo é a latência do ExpressRoute chegando a 380ms nos picos. O caminho de uma consulta DNS neste ambiente é: VM na VNet encaminha para 10.0.0.10 via ExpressRoute, o servidor on-premises encaminha para 168.63.129.16, a resposta retorna pelo mesmo caminho. Com 380ms de latência de ida e volta no circuito, mais o tempo de processamento do servidor on-premises e do resolvedor Azure, o timeout padrão de DNS (geralmente 5 segundos) é facilmente ultrapassado sob carga.
A alternativa A é tecnicamente correta como observação (o servidor on-premises de fato não é autoritativo para internal.cloudapp.net), mas não explica a intermitência: se fosse essa a causa, a falha seria constante e previsível, não correlacionada ao horário. Essa alternativa representa o erro clássico de confundir um fato verdadeiro com a causa raiz.
A alternativa B seria válida se o 168.63.129.16 fosse um IP externo sujeito a indisponibilidade, mas ele é o resolvedor mágico do Azure, disponível em todo datacenter Azure independentemente de carga. O distrator mais perigoso é o A: agir com base nele levaria a criar uma zona DNS privada desnecessária para internal.cloudapp.net, sem resolver o gargalo real de latência.
Gabarito — Cenário 4
Resposta: B
A sequência correta é P, R, Q, S, T, que segue a lógica de diagnóstico progressivo da camada mais fundamental para a mais específica.
P (verificar IP via DHCP) é o ponto de partida: sem endereço IP válido, todos os demais testes são inúteis. R (verificar DNS Servers na VNet) identifica qual servidor a VM deveria estar usando, dado pelo DHCP da VNet. Q (executar nslookup e observar o servidor retornado) valida se a VM efetivamente recebeu e está usando o servidor correto. S (testar conectividade com 168.63.129.16) confirma se o plano de resolução do Azure está acessível da VM. T (verificar se o servidor customizado está acessível e respondendo) é o último passo porque só faz sentido testá-lo após confirmar que a VM sabe qual servidor usar e tem conectividade de rede.
A sequência A começa pelo portal (R) antes de validar se a VM sequer tem IP, o que pode gerar diagnóstico correto no portal com problema invisível na VM. A sequência D começa testando 168.63.129.16 diretamente, o que pula etapas fundamentais e pode levar a conclusões falsas sobre a causa.
Árvore de Troubleshooting: Configure DNS settings for a VNet
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 | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta de diagnóstico com base no que você observa no ambiente, não no que você supõe. Siga o caminho indicado pela sua resposta (sim ou não) até alcançar um nó vermelho de causa identificada. A partir da causa, o nó verde adjacente indica a ação corretiva. Se após aplicar a ação o sintoma persistir, retorne ao nó de verificação imediatamente anterior e reavalie se a premissa da resposta estava correta.