Laboratório de Troubleshooting: Link a private DNS zone to a VNet
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento reporta que VMs provisionadas na Spoke-VNet não conseguem resolver o nome api.corp.internal, mas VMs na Hub-VNet resolvem normalmente. O time de rede confirma que:
- O peering entre Hub-VNet e Spoke-VNet está ativo e bidirecional
- A zona DNS privada
corp.internalexiste e contém o registro A paraapi - As VMs da Spoke-VNet conseguem acessar recursos na Hub-VNet via IP diretamente
- O NSG da Spoke-VNet permite tráfego de saída irrestrito na porta 53
- A Spoke-VNet foi criada há três dias como parte de uma expansão de ambiente
A saída do comando executado na VM da Spoke-VNet é:
$ nslookup api.corp.internal
Server: 168.63.129.16
Address: 168.63.129.16
** server can't find api.corp.internal: NXDOMAIN
Qual é a causa raiz da falha de resolução?
A) O NSG está bloqueando as consultas DNS apesar da regra de saída, porque falta uma regra de entrada para respostas na porta 53.
B) A Spoke-VNet não possui um link de resolução configurado para a zona DNS privada corp.internal.
C) O peering entre as VNets não foi configurado para propagar rotas DNS, impedindo que as consultas cheguem à zona privada.
D) O registro A para api foi criado enquanto a Spoke-VNet ainda não existia, tornando-o invisível para VNets adicionadas posteriormente.
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que a zona DNS privada prod.internal está vinculada à VNet-Prod com o registro automático habilitado. A mesma VNet foi recentemente vinculada a uma segunda zona, monitoring.internal, também com registro automático habilitado. Desde então, novas VMs provisionadas na VNet-Prod não estão sendo registradas em nenhuma das duas zonas.
A causa já foi identificada pela equipe: a VNet-Prod viola o limite de uma única zona com registro automático por VNet, e o segundo link com registro automático está bloqueando o comportamento esperado.
O ambiente é de produção ativo com dezenas de VMs já registradas na zona prod.internal. O time tem uma janela de manutenção disponível somente em 48 horas. Não há permissão para remover ou recriar o link da zona prod.internal sem aprovação do comitê de mudanças.
Qual é a ação correta a tomar agora?
A) Remover imediatamente o link da zona prod.internal e recriá-lo para forçar a ressincronização dos registros automáticos.
B) Desabilitar o registro automático no link da zona monitoring.internal, restaurando o comportamento correto na zona prod.internal sem afetar os registros existentes.
C) Excluir a zona monitoring.internal e criar uma nova zona com nome diferente para contornar o conflito de registro.
D) Aguardar a janela de manutenção e, dentro dela, recriar ambos os links com registro automático habilitado simultaneamente para forçar a resolução do conflito.
Cenário 3 — Causa Raiz
Um engenheiro de rede relata que as VMs de uma VNet estão criando registros DNS duplicados. A zona privada dev.internal mostra múltiplos registros A para o mesmo hostname, com IPs diferentes, alguns já desativados. O engenheiro suspeita de um problema de TTL elevado.
O ambiente possui:
- 1 VNet com link para
dev.internalcom registro automático habilitado - VMs com IPs dinâmicos que são frequentemente realocadas
- TTL padrão dos registros na zona configurado em 10 segundos
- 3 snapshots de VMs restaurados na última semana a partir de imagens base
A saída do portal mostra:
dev-vm-01 A 10.0.1.4 TTL: 10s
dev-vm-01 A 10.0.1.17 TTL: 10s
dev-vm-01 A 10.0.1.29 TTL: 10s
Qual é a causa raiz dos registros duplicados?
A) O TTL de 10 segundos é muito baixo e faz com que o Azure recrie o registro antes que o anterior expire, acumulando entradas.
B) As VMs restauradas a partir de snapshots retiveram o hostname original e, ao serem provisionadas com novos IPs, o Azure registrou novas entradas sem remover as anteriores associadas às instâncias originais.
C) A zona dev.internal atingiu o limite máximo de registros e está aceitando novas entradas sem processar deleções pendentes.
D) O link de registro automático criou um conflito porque a VNet possui sub-redes em zonas de disponibilidade diferentes, gerando uma entrada por zona.
Cenário 4 — Sequência de Diagnóstico
Uma VM em produção para de resolver nomes na zona privada infra.internal após uma operação de rotina executada pelo time de identidade e acesso. O engenheiro de redes recebe o chamado e precisa diagnosticar a causa.
Os passos de investigação disponíveis são:
- Verificar se a zona
infra.internalexiste e contém os registros esperados - Confirmar se a VM consegue resolver nomes públicos como
microsoft.com - Verificar se o link entre a VNet da VM e a zona
infra.internalainda existe e está ativo - Checar se houve alteração recente em políticas de acesso ou bloqueios no plano de controle da VNet
- Testar a resolução de outro nome na mesma zona a partir de uma VM diferente na mesma VNet
Qual sequência de diagnóstico representa a abordagem progressiva correta?
A) 1, 3, 5, 2, 4
B) 2, 1, 3, 5, 4
C) 3, 1, 5, 2, 4
D) 4, 2, 1, 3, 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista determinante está na saída do nslookup: o servidor consultado é o 168.63.129.16, que é o resolvedor recursivo do Azure. Isso significa que a VM está configurada corretamente para usar o DNS do Azure, mas o resolvedor retorna NXDOMAIN. Esse comportamento indica que o resolvedor do Azure não associa a Spoke-VNet a nenhuma zona privada que contenha corp.internal, o que ocorre exatamente quando não há um link de resolução configurado entre essa VNet e a zona.
A informação sobre o NSG e a porta 53 é irrelevante neste cenário: o resolvedor 168.63.129.16 é acessado internamente pelo Azure sem depender de regras de NSG, e a consulta claramente chegou ao servidor, pois houve resposta NXDOMAIN. A alternativa A confunde o comportamento do DNS com tráfego de aplicação sujeito a NSG. A alternativa C representa um equívoco clássico: peering não tem nenhuma relação com propagação de vínculos DNS privados. A alternativa D é tecnicamente sem fundamento, pois os registros DNS são visíveis para qualquer VNet vinculada à zona, independentemente de quando foram criados.
O distrator mais perigoso é a alternativa C, pois o peering bidirecional ativo leva o diagnóstico para a camada de rede em vez de examinar o plano de resolução DNS.
Gabarito — Cenário 2
Resposta: B
A causa já está declarada: existe um segundo link com registro automático habilitado em conflito com o primeiro. A ação correta é eliminar o conflito com o menor impacto possível dentro das restrições do cenário. Desabilitar o registro automático no link da zona monitoring.internal resolve o conflito sem remover nenhum link, sem exigir aprovação do comitê de mudanças e sem afetar os registros já existentes na zona prod.internal.
A alternativa A viola diretamente a restrição do cenário: remover o link da prod.internal requer aprovação e pode impactar as dezenas de VMs já registradas. A alternativa C é uma ação destrutiva e desnecessária que não é justificada pelas restrições apresentadas. A alternativa D ignora que o problema já pode ser resolvido agora com impacto zero, e aguardar 48 horas mantém o ambiente em estado degradado sem necessidade.
O distrator mais perigoso é a alternativa D, pois parece prudente aguardar a janela de manutenção, mas confunde uma ação de baixo risco imediato com uma intervenção que exigiria janela formal.
Gabarito — Cenário 3
Resposta: B
Quando uma VM é restaurada a partir de um snapshot, ela assume o mesmo hostname da imagem base. Se essa VM recebe um novo IP por alocação dinâmica, o mecanismo de registro automático cria um novo registro A para o hostname com o novo IP. Porém, os registros anteriores associados a instâncias que foram substituídas ou encerradas de forma não convencional, como restaurações de snapshot, não são removidos automaticamente pelo Azure, pois o ciclo de vida normal de desalocação que dispara a remoção do registro não ocorreu.
A informação sobre o TTL de 10 segundos é irrelevante e propositalmente incluída para desviar o diagnóstico para o plano de expiração de cache, que não tem relação com acumulação de registros na zona. O TTL baixo afeta apenas o tempo que resolvedores externos mantêm o registro em cache, não a quantidade de registros na zona. A alternativa A representa exatamente esse erro de diagnóstico. As alternativas C e D não têm fundamento técnico para o sintoma descrito.
O distrator mais perigoso é a alternativa A, pois o TTL é um dado visível e numérico que atrai atenção e parece relacionado ao problema de registros que "não saem".
Gabarito — Cenário 4
Resposta: B
A sequência correta é 2, 1, 3, 5, 4.
O primeiro passo é verificar se a VM consegue resolver nomes públicos. Isso separa imediatamente um problema de DNS geral, como servidor DNS inacessível, de um problema específico à zona privada. Se nomes públicos resolvem, o DNS funciona e o problema é localizado. Em seguida, confirmar que a zona existe e contém os registros esperados elimina a hipótese de exclusão acidental. O terceiro passo verifica se o link entre a VNet e a zona está ativo, que é a causa mais comum para perda de resolução privada. O quarto passo testa outra VM na mesma VNet para determinar se o problema é da VM específica ou da VNet inteira. Por último, investigar alterações no plano de controle fecha o diagnóstico com contexto operacional, o que exige mais esforço e é mais eficiente após as hipóteses mais simples serem eliminadas.
A alternativa D começa pelo passo de maior complexidade investigativa antes de validar hipóteses mais simples, o que representa o erro diagnóstico de ir direto à causa suspeita sem validação progressiva.
Árvore de Troubleshooting: Link a private DNS zone to a VNet
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga cada ramificação respondendo às perguntas com o que você consegue verificar diretamente no ambiente. Cada resposta elimina um conjunto de hipóteses e direciona para a próxima verificação. Ao atingir um nó vermelho, a causa está identificada; o nó verde imediatamente abaixo indica a ação corretiva correspondente. Nunca pule perguntas intermediárias, pois a ordem reflete a progressão de complexidade investigativa do mais simples para o mais específico.