Laboratório de Troubleshooting: Design and Implement Azure DNS Private Resolver
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de rede de uma empresa reporta que VMs hospedadas em uma VNet Spoke não conseguem resolver nomes de domínio pertencentes à zona DNS privada prod.azure.internal, vinculada à VNet Hub. As VMs na própria VNet Hub resolvem os mesmos nomes sem qualquer problema.
O ambiente foi configurado da seguinte forma:
VNet Hub (10.1.0.0/16)
└── Zona privada "prod.azure.internal" vinculada (auto-registro: desabilitado)
└── DNS Private Resolver
├── Inbound Endpoint: 10.1.1.4 (subnet: snet-dns-inbound)
└── Outbound Endpoint (subnet: snet-dns-outbound)
└── Ruleset: encaminha "corp.local" para 192.168.0.53
VNet Spoke (10.2.0.0/16)
└── Peering com Hub: habilitado (bidirecional)
└── DNS Server: 10.1.1.4
Durante a investigação, a equipe executa o seguinte teste a partir de uma VM na VNet Spoke:
$ nslookup app01.prod.azure.internal 10.1.1.4
Server: 10.1.1.4
Address: 10.1.1.4#53
** server can't find app01.prod.azure.internal: NXDOMAIN
A equipe confirma que o peering está ativo, que o servidor DNS da VNet Spoke aponta corretamente para o inbound endpoint e que a VM consegue pingar 10.1.1.4. O ruleset de encaminhamento para corp.local foi validado e funciona normalmente a partir da VNet Spoke.
Qual é a causa raiz da falha na resolução de prod.azure.internal?
A) O inbound endpoint não tem capacidade de resolver zonas DNS privadas quando a consulta é originada de uma VNet diferente da que hospeda o resolver
B) A zona privada prod.azure.internal não está vinculada à VNet Spoke, portanto o resolver não a enxerga ao responder consultas dessa rede
C) O auto-registro está desabilitado na zona privada, impedindo que registros de VMs da VNet Spoke sejam criados e resolvidos
D) O peering entre Hub e Spoke não propaga a configuração de DNS, exigindo que o servidor DNS seja configurado diretamente na VNet Hub
Cenário 2 — Decisão de Ação
A equipe de operações identificou que consultas DNS para o domínio finance.corp.local estão falhando a partir de todas as VNets spoke de uma topologia hub-and-spoke. A causa foi confirmada: o DNS Forwarding Ruleset associado ao outbound endpoint do Hub contém uma regra para finance.corp.local apontando para um servidor DNS on-premises que foi descomissionado. O endereço correto do novo servidor é 10.0.200.20.
O ambiente está em produção. O ruleset ruleset-corp é compartilhado por quatro VNets spoke e contém outras 11 regras ativas que estão funcionando normalmente. Uma janela de manutenção está agendada para daqui a 6 horas.
Qual é a ação correta a tomar neste momento?
A) Excluir o ruleset ruleset-corp inteiro e recriar todas as 12 regras com o endereço correto durante a janela de manutenção
B) Remover a associação do ruleset de todas as VNets spoke imediatamente para interromper o encaminhamento incorreto enquanto a correção é planejada
C) Editar apenas a regra finance.corp.local no ruleset existente, atualizando o endereço de destino para 10.0.200.20, sem aguardar a janela de manutenção
D) Criar um novo ruleset com a regra correta e associá-lo às VNets spoke, mantendo o ruleset antigo ativo para preservar as demais regras
Cenário 3 — Causa Raiz
Um engenheiro de rede recebe um chamado relatando que servidores on-premises não conseguem resolver nomes de VMs registradas na zona privada vm.internal do Azure. A conectividade híbrida está estabelecida via VPN Site-to-Site, e o túnel está ativo com latência normal.
O engenheiro coleta as seguintes informações:
Servidor DNS on-premises: 192.168.1.10 (Windows Server)
Forwarder condicional configurado em 192.168.1.10:
Domínio: vm.internal
Encaminha para: 10.0.2.5
DNS Private Resolver (VNet Hub):
Inbound Endpoint: 10.0.1.4 (subnet: snet-inbound /28)
Outbound Endpoint: 10.0.2.5 (subnet: snet-outbound /28)
Zona "vm.internal" vinculada à VNet Hub
Teste executado no servidor on-premises:
C:\> nslookup web01.vm.internal 10.0.2.5
DNS request timed out.
timeout was 2 seconds.
*** Request to 10.0.2.5 timed out
O engenheiro verifica que o túnel VPN está ativo, que 10.0.1.4 responde corretamente quando consultado diretamente do servidor on-premises, e que VMs dentro da VNet Hub resolvem web01.vm.internal sem problemas. O Network Security Group (NSG) da subnet snet-inbound permite tráfego UDP/53 de qualquer origem.
Qual é a causa raiz da falha?
A) O NSG da subnet snet-inbound está bloqueando as consultas do servidor on-premises, pois a regra de permissão não é suficientemente específica
B) O forwarder condicional no servidor on-premises está apontando para o outbound endpoint (10.0.2.5) em vez do inbound endpoint (10.0.1.4), que é o componente correto para receber consultas externas
C) A zona vm.internal precisa ser vinculada também à subnet do outbound endpoint para que o resolver consiga respondê-la
D) O servidor DNS on-premises precisa usar o protocolo TCP em vez de UDP para encaminhar consultas através do túnel VPN
Cenário 4 — Sequência de Diagnóstico
Uma VM em uma VNet Spoke não consegue resolver nomes do domínio legacy.corp encaminhados para um servidor DNS on-premises. Abaixo estão cinco passos de investigação possíveis, apresentados fora de ordem:
[P1] Verificar se o DNS Forwarding Ruleset está associado à VNet Spoke
[P2] Consultar diretamente o servidor DNS on-premises de destino para confirmar
que ele responde ao domínio "legacy.corp"
[P3] Executar nslookup de "legacy.corp" a partir da VM afetada e capturar
o erro retornado
[P4] Confirmar que o outbound endpoint está provisionado e associado ao ruleset
correto
[P5] Verificar se a regra para "legacy.corp" existe no ruleset e se o IP de
destino está correto
Qual é a sequência correta de investigação?
A) P3 → P1 → P4 → P5 → P2
B) P1 → P3 → P5 → P4 → P2
C) P3 → P4 → P1 → P5 → P2
D) P2 → P3 → P1 → P5 → P4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no comportamento assimétrico: a VNet Hub resolve a zona normalmente, mas a VNet Spoke não. O inbound endpoint do resolver responde consultas no contexto das zonas vinculadas à VNet onde o resolver está provisionado. Para que uma VNet Spoke também enxergue uma zona privada ao consultar esse resolver, a zona precisa estar vinculada à VNet Spoke de forma independente.
A informação sobre o funcionamento correto do encaminhamento para corp.local é propositalmente irrelevante: confirma que o resolver está operacional e que o ruleset funciona, mas não tem relação com a visibilidade de zonas privadas.
A alternativa A é falsa: o inbound endpoint resolve zonas privadas para qualquer origem, desde que a zona esteja vinculada corretamente. A alternativa C confunde o auto-registro (mecanismo de criação automática de registros A para VMs) com a capacidade de resolução da zona: desabilitar o auto-registro não impede consultas a registros criados manualmente. A alternativa D descreve um comportamento inexistente: o peering não interfere na propagação de servidores DNS configurados por VNet.
O distrator mais perigoso é C, pois o auto-registro desabilitado parece suspeito e pode desviar o diagnóstico para a zona em vez de para o vínculo de rede.
Gabarito — Cenário 2
Resposta: C
A causa é conhecida, o impacto é cirúrgico (uma única regra de domínio), e as outras 11 regras do ruleset estão funcionando normalmente. Editar apenas a regra com problema é a ação precisa, proporcional e sem risco para o restante do ambiente. A alteração de uma regra em um ruleset existente não exige interrupção de serviço nem janela de manutenção, pois não afeta as demais regras nem as associações do ruleset com as VNets spoke.
A alternativa A é destrutiva e desnecessária: excluir o ruleset inteiro interromperia as 11 regras funcionais e exigiria recriar tudo, gerando impacto muito maior que o problema original. A alternativa B remove a proteção de todas as VNets spoke para todos os domínios enquanto a correção não é feita, trocando um problema pontual por uma interrupção ampla. A alternativa D criaria conflito de rulesets associados às mesmas VNets e não resolve o problema de forma limpa: dois rulesets ativos para o mesmo conjunto de VNets geram ambiguidade.
Gabarito — Cenário 3
Resposta: B
A pista está nos próprios dados coletados: o inbound endpoint 10.0.1.4 responde corretamente quando consultado diretamente, mas o forwarder condicional no servidor on-premises aponta para 10.0.2.5, que é o outbound endpoint. O outbound endpoint não aceita consultas DNS externas: ele é exclusivamente uma interface de saída para encaminhar consultas do Azure para destinos externos. Enviar consultas para ele a partir de fora da rede virtual resulta em timeout, exatamente como observado.
O status do túnel VPN e a latência normal são informações irrelevantes: confirmam conectividade de rede, mas não eliminam um erro de configuração no destino do forwarder. O NSG da subnet snet-inbound também é uma pista falsa: a subnet relevante para esse fluxo seria snet-outbound, e de qualquer forma a configuração do forwarder aponta para o endereço errado antes mesmo de qualquer filtragem.
A alternativa D é o distrator mais perigoso: a questão do protocolo TCP vs UDP em túneis VPN é uma preocupação legítima em outros contextos, mas não explica o timeout observado quando o inbound endpoint responde normalmente pelo mesmo caminho de rede.
Gabarito — Cenário 4
Resposta: A
A sequência correta é P3 → P1 → P4 → P5 → P2.
O raciocínio diagnóstico progressivo parte sempre do sintoma observado antes de qualquer suposição sobre a causa. P3 estabelece o ponto de partida: qual erro a VM retorna. Em seguida, P1 verifica a condição mais comum de falha nesse cenário (ruleset não associado à VNet Spoke), pois sem essa associação nenhuma regra de encaminhamento é aplicada. P4 confirma que o outbound endpoint existe e está vinculado ao ruleset correto, validando a cadeia de encaminhamento. P5 desce ao nível da regra específica para verificar se o domínio e o IP de destino estão corretos. Por fim, P2 valida o servidor de destino de forma isolada, confirmando se o problema está no Azure ou no servidor on-premises.
A alternativa D comete o erro clássico de validar o servidor externo antes de confirmar que a cadeia interna do resolver está íntegra, desperdiçando esforço diagnóstico em um componente que pode estar funcionando normalmente.
Árvore de Troubleshooting: Design and Implement Azure DNS Private Resolver
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Diante de uma falha real envolvendo o Azure DNS Private Resolver, comece sempre pelo nó raiz e responda cada pergunta com base no que é diretamente observável: testes de conectividade, saídas de nslookup, configurações visíveis no portal ou via CLI. Siga o caminho que corresponde ao comportamento observado, sem pular etapas. Os nós laranja indicam pontos onde uma validação intermediária é necessária antes de continuar o diagnóstico. Ao chegar a um nó vermelho, a causa está identificada e o nó verde correspondente indica a ação precisa a executar.