Pular para o conteúdo principal

Laboratório de Troubleshooting: Configure public and private DNS zones

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Uma equipe reporta que VMs recém-criadas na VNet-Prod não estão sendo registradas automaticamente na zona DNS privada srv.interno.azure. O ambiente foi configurado há três semanas e funcionava corretamente até dois dias atrás, quando um novo grupo de VMs foi adicionado.

O administrador verifica o estado atual da zona e da vinculação:

# Saída do comando: az network private-dns link vnet list
# --zone-name srv.interno.azure --resource-group rg-dns

Name              VirtualNetwork    RegistrationEnabled    ProvisioningState
----------------  ----------------  ---------------------  ---------------
link-prod         VNet-Prod         False                  Succeeded
link-dev          VNet-Dev          True                   Succeeded

Informações adicionais coletadas pela equipe:

  • As VMs antigas da VNet-Prod aparecem normalmente na zona
  • O NSG da subnet das novas VMs bloqueia a porta 53 UDP outbound
  • As novas VMs recebem IP via DHCP sem problemas
  • A VNet-Dev tem auto-registro ativo e funciona corretamente

Qual é a causa raiz da falha no registro automático das novas VMs?

A. O NSG está bloqueando as consultas DNS na porta 53 UDP, impedindo que a plataforma registre os nomes

B. O limite de registros automáticos por zona privada foi atingido com a adição do novo grupo de VMs

C. O auto-registro está desabilitado na vinculação da VNet-Prod, portanto nenhuma VM nova dessa VNet será registrada automaticamente

D. A zona srv.interno.azure está em estado de provisionamento incompleto, impedindo novos registros

Cenário 2 — Decisão de Ação​

Um engenheiro de rede identificou que a resolução de nomes do domínio pagamentos.contoso.com está falhando para servidores on-premises. A causa já foi diagnosticada: o conditional forwarder no DNS on-premises aponta para 168.63.129.16, que não é acessível fora da rede do Azure. A zona DNS privada pagamentos.contoso.com existe no Azure e está corretamente vinculada à VNet de produção.

Contexto operacional:

  • O ambiente on-premises é conectado ao Azure via ExpressRoute com peering privado ativo
  • Um Azure DNS Private Resolver já está provisionado em uma subnet da VNet de produção, com um inbound endpoint no IP 10.10.5.4
  • A janela de manutenção programada começa em 40 minutos
  • Alterar registros no DNS on-premises requer aprovação de change request, que já foi emitida para esta janela

Qual é a ação correta a tomar agora?

A. Criar um registro NS na zona pública contoso.com delegando pagamentos.contoso.com para os nameservers do Azure DNS

B. Atualizar o conditional forwarder no DNS on-premises para apontar para 10.10.5.4 em vez de 168.63.129.16

C. Reconfigurar o inbound endpoint do DNS Private Resolver para usar o IP 168.63.129.16 diretamente

D. Criar um novo link de VNet na zona privada com auto-registro habilitado para cobrir o tráfego on-premises

Cenário 3 — Causa Raiz​

Uma aplicação multi-região usa duas VNets: VNet-EastUS e VNet-WestEU. Ambas estão vinculadas à zona DNS privada app.plataforma.azure. O auto-registro está habilitado nas duas vinculações. VMs na VNet-EastUS resolvem nomes de VMs na VNet-WestEU sem problemas.

A equipe reporta que uma VM específica, cache-01, criada na VNet-EastUS, não pode ser resolvida por nenhuma das duas VNets. O administrador consulta a zona:

# az network private-dns record-set list \
# --zone-name app.plataforma.azure \
# --resource-group rg-dns-global \
# --query "[].{Name:name, Type:type}" -o table

Name              Type
----------------  ------
vm-app-01         A
vm-app-02         A
vm-db-01          A
cache-01          A

O administrador também verifica:

# nslookup cache-01.app.plataforma.azure
# Executado de vm-app-01 (VNet-EastUS)

Server:  168.63.129.16
Address: 168.63.129.16

** server can't find cache-01.app.plataforma.azure: NXDOMAIN

Informações adicionais:

  • cache-01 tem IP privado 10.1.4.22 e está em execução
  • A VM cache-01 foi criada a partir de uma imagem customizada com DNS estático configurado na NIC, apontando para 10.1.0.5 (servidor DNS interno legado)
  • O servidor 10.1.0.5 não encaminha consultas para 168.63.129.16
  • Peering entre VNet-EastUS e VNet-WestEU está ativo

Qual é a causa raiz do problema?

A. O peering entre as VNets não propaga registros DNS de zonas privadas; é necessário um link separado por VNet

B. O registro A de cache-01 existe na zona, mas a VM não responde a consultas porque o servidor DNS estático configurado na NIC impede que a plataforma do Azure registre o IP correto, gerando um registro com IP inconsistente ou vazio

C. A NIC de cache-01 tem DNS estático apontando para um servidor que não encaminha para 168.63.129.16, fazendo com que a própria VM não consiga resolver nomes, mas o registro dela na zona existe e está correto

D. O auto-registro criou o registro de cache-01 na zona, mas como a VM usa DNS estático na NIC, o Azure não conseguiu registrar o IP correto, resultando em um registro A com valor inválido ou ausente

Cenário 4 — Sequência de Diagnóstico​

Um administrador recebe o seguinte relato: "VMs na VNet-Shared pararam de resolver nomes do domínio interno.corp após uma reorganização de recursos feita ontem."

O administrador tem acesso ao portal do Azure e às VMs. Os passos de investigação disponíveis são:

  1. Verificar se a zona DNS privada interno.corp ainda existe no resource group correto
  2. Executar nslookup interno.corp a partir de uma VM afetada e registrar a resposta do servidor DNS
  3. Confirmar se a VNet-Shared ainda aparece na lista de VNet links da zona interno.corp
  4. Verificar se as configurações de DNS da VNet-Shared foram alteradas para um servidor customizado durante a reorganização
  5. Testar resolução de um nome externo como microsoft.com a partir da VM afetada

Qual é a sequência correta de diagnóstico?

A. 1 → 3 → 4 → 2 → 5

B. 2 → 5 → 1 → 3 → 4

C. 4 → 1 → 3 → 2 → 5

D. 5 → 2 → 1 → 3 → 4

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: C

A saída do comando é a pista decisiva: RegistrationEnabled: False na vinculação link-prod. O auto-registro desabilitado significa que a plataforma do Azure não criará automaticamente registros A/AAAA para VMs dessa VNet, independentemente de quantas VMs sejam adicionadas. As VMs antigas aparecem na zona porque foram registradas quando a vinculação ainda tinha auto-registro ativo, ou foram inseridas manualmente.

O NSG bloqueando a porta 53 é a informação irrelevante incluída propositalmente. O registro automático de VMs em zonas DNS privadas é feito pela plataforma do Azure internamente, sem depender de tráfego DNS originado da VM. Bloquear a porta 53 impede que a VM resolva nomes, mas não impede que o Azure registre o nome dela.

A alternativa B é um distrator plausível: existe um limite de 100 VNets com auto-registro por zona, mas o limite relevante aqui é de registros por zona (250.000), não de VNets. Além disso, a saída do comando mostra claramente a causa. O distrator mais perigoso seria A: agir removendo o NSG resolveria um problema diferente (resolução pela VM), deixando o problema real intocado.

Gabarito — Cenário 2​

Resposta: B

A causa já está diagnosticada e a solução técnica correta é bem conhecida: o conditional forwarder on-premises deve apontar para o inbound endpoint do DNS Private Resolver, que é o único componente acessível via ExpressRoute a partir da rede on-premises. O IP 10.10.5.4 já está disponível e provisionado, a mudança já possui aprovação de change request e a janela de manutenção está ativa. Todas as restrições operacionais estão satisfeitas para essa ação.

A alternativa A é tecnicamente incorreta para este cenário: criar um registro NS em zona pública não resolve nomes de uma zona DNS privada para clientes on-premises. A alternativa C é impossível: 168.63.129.16 é um IP virtual da plataforma, não configurável em um recurso. A alternativa D confunde o propósito do VNet link (resolução dentro do Azure) com a necessidade de forwarder para origem on-premises, e ainda assim não resolveria o problema porque o link não expõe um endpoint acessível externamente.

Gabarito — Cenário 3​

Resposta: D

O registro cache-01 aparece na zona, mas o nslookup retorna NXDOMAIN. Isso indica que o registro existe no plano de controle da zona, mas o conteúdo do registro A está vazio ou contém um valor que o resolvedor não consegue retornar como válido. A causa é que o auto-registro tenta capturar o IP da NIC via plataforma, mas quando a NIC tem DNS estático configurado para um servidor externo (10.1.0.5), o processo de registro pode não conseguir associar o IP correto à entrada, resultando em um registro malformado ou sem valor de IP associado.

A alternativa C é o distrator mais sofisticado e representa o erro de raciocínio mais comum: confundir o impacto do DNS estático na resolução feita pela própria VM com o impacto no registro dela na zona. São dois mecanismos independentes. O fato de o servidor 10.1.0.5 não encaminhar para 168.63.129.16 explica por que a cache-01 não consegue resolver outros nomes, mas não explica por que outras VMs não conseguem resolver cache-01.

A informação sobre o peering ativo entre VNets é irrelevante para o diagnóstico: o peering é necessário para tráfego de dados, não para resolução DNS via zona privada compartilhada. Agir com base na alternativa A e criar links adicionais não resolveria o problema e adicionaria complexidade desnecessária.

Gabarito — Cenário 4​

Resposta: B

A sequência correta é: 2 → 5 → 1 → 3 → 4.

O raciocínio diagnóstico correto parte do sintoma observável e vai eliminando hipóteses progressivamente:

Passo 2 confirma o que exatamente está falhando e qual servidor DNS a VM está consultando. Isso diferencia entre "a zona não existe mais" e "a VNet não está mais vinculada" e "o DNS da VNet foi alterado".

Passo 5 testa se o problema é específico da zona privada ou se o DNS como um todo está quebrado na VM. Se microsoft.com resolve, o DNS básico funciona e o problema é na zona privada. Se não resolve, o DNS da VNet foi redirecionado para um servidor não funcional.

Passo 1 verifica a existência da zona, confirmando se o recurso sobreviveu à reorganização.

Passo 3 verifica se o link da VNet com a zona ainda existe, o que seria destruído se a zona foi movida entre resource groups ou se o link foi deletado durante a reorganização.

Passo 4 confirma se a configuração de DNS da VNet foi alterada, o que seria a causa caso todos os passos anteriores mostrassem estado saudável.

A sequência A começa pela existência da zona antes de saber o que exatamente está falhando, o que é ineficiente. A sequência C começa pelo passo mais operacionalmente custoso antes de qualquer triagem. A sequência D começa por um teste de DNS externo sem primeiro capturar o sintoma específico com nslookup.

Árvore de Troubleshooting: Configure public and private DNS zones​

100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Legenda:

  • Azul escuro: sintoma inicial ou ponto de entrada
  • Azul: pergunta de diagnóstico, respondida por observação direta
  • Vermelho: causa raiz identificada
  • Verde: ação recomendada ou resolução
  • Laranja: verificação intermediária antes de aprofundar o diagnóstico

Ao enfrentar um problema real, inicie pelo nó raiz e responda cada pergunta com base no que é diretamente observável: saídas de comandos, estado de recursos no portal, testes de nslookup. Siga o caminho que corresponde ao que você observou, sem pular etapas. Cada nó laranja indica um momento de validação antes de continuar: se o estado intermediário estiver saudável, o problema está em uma camada mais profunda. Os nós vermelhos nomeiam a causa com precisão suficiente para orientar a ação corretiva correspondente no nó verde imediatamente abaixo.