Laboratório de Troubleshooting: Design private DNS zones
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que VMs recém-criadas na rede virtual vnet-app-eastus não conseguem resolver o nome db01.data.internal, que aponta para um endpoint privado de um Azure SQL Database. O ambiente foi configurado há três semanas e funcionava normalmente até ontem.
O engenheiro responsável verifica o seguinte:
# Executado dentro de uma VM em vnet-app-eastus
nslookup db01.data.internal
Server: 168.63.129.16
Address: 168.63.129.16
*** db01.data.internal: Non-existent domain
A equipe informa que, na véspera, um novo administrador criou um segundo virtual network link entre vnet-app-eastus e a zona data.internal, porque o link original havia sido criado sem registro automático e ele queria "recriá-lo com as configurações corretas". O link original foi removido e o novo foi adicionado. A zona data.internal contém 47 registros do tipo A criados manualmente. O cofre de chaves da aplicação foi rotacionado no mesmo dia, o que gerou alertas que distraíram a equipe durante a investigação.
O servidor DNS configurado nas definições da vnet-app-eastus aponta para 168.63.129.16.
Qual é a causa raiz da falha na resolução?
A) A rotação do cofre de chaves corrompeu as credenciais usadas pelo DNS resolver interno do Azure.
B) A remoção e recriação do virtual network link não restaurou automaticamente os registros A existentes na zona, que precisam ser recriados manualmente.
C) O novo virtual network link ainda está em estado de propagação e ainda não foi ativado pelo Azure DNS.
D) O registro db01.data.internal não existe na zona data.internal porque ele nunca foi criado; o link anterior com registro automático desabilitado jamais gerou esse registro.
Cenário 2 — Decisão de Ação
A equipe de plataforma identificou que VMs em vnet-spoke-02 não conseguem resolver nomes da zona DNS privada services.hub.internal, vinculada apenas a vnet-hub. A causa foi confirmada: não existe virtual network link entre vnet-spoke-02 e a zona services.hub.internal. O ambiente usa topologia hub-spoke com peering bidirecional configurado e funcionando. A aplicação em vnet-spoke-02 está em produção e processa transações financeiras. O time de segurança exige que qualquer alteração em zonas DNS privadas seja aprovada por um change advisory board (CAB), cujo próximo ciclo ocorre em 48 horas. A janela de manutenção acordada para essa VNet é às 2h do dia seguinte.
Qual é a ação correta a tomar neste momento?
A) Criar imediatamente o virtual network link entre vnet-spoke-02 e a zona services.hub.internal, pois a causa já está confirmada e a criação de um link não causa interrupção de tráfego existente.
B) Configurar um servidor DNS customizado em vnet-spoke-02 com forwarder condicional para services.hub.internal apontando para 168.63.129.16, como solução temporária, sem necessidade de aprovação do CAB.
C) Documentar a causa, abrir o processo de aprovação no CAB e aguardar o ciclo de aprovação antes de qualquer alteração na zona ou nos links.
D) Criar o virtual network link durante a janela de manutenção das 2h do dia seguinte, sem submeter ao CAB, por se tratar de uma ação não destrutiva.
Cenário 3 — Causa Raiz
Uma empresa migrou recentemente seus workloads para o Azure e configurou endpoints privados para o Azure Blob Storage. A zona DNS privada privatelink.blob.core.windows.net foi criada e vinculada à rede virtual vnet-migration. O registro A para contosostorage.privatelink.blob.core.windows.net aponta para 10.1.4.5, que é o IP do endpoint privado.
Uma VM em vnet-migration executa o seguinte teste:
nslookup contosostorage.blob.core.windows.net
Server: 10.0.0.4
Address: 10.0.0.4
Non-authoritative answer:
Name: contosostorage.blob.core.windows.net
Address: 20.38.98.100
O IP 20.38.98.100 é o IP público do serviço. O administrador confirma que o virtual network link está ativo, o registro A existe na zona e o endpoint privado está provisionado com sucesso. A VM tem acesso à internet habilitado via NAT Gateway, configurado há dois meses sem problemas. O Network Security Group da subnet não bloqueia tráfego interno.
Qual é a causa raiz do comportamento observado?
A) O NAT Gateway está interceptando as consultas DNS e redirecionando-as para resolvedores externos antes que o Azure DNS privado possa respondê-las.
B) O servidor DNS configurado na VNet aponta para 10.0.0.4, que é um servidor customizado que não encaminha consultas para 168.63.129.16, impedindo a resolução pela zona privada.
C) O registro A na zona privada está com o nome incorreto; deveria ser contosostorage.blob.core.windows.net e não contosostorage.privatelink.blob.core.windows.net.
D) O virtual network link foi criado sem registro automático, o que impede a resolução de registros do tipo A criados manualmente na zona.
Cenário 4 — Impacto Colateral
Uma equipe resolve um problema de resolução DNS em vnet-analytics habilitando o registro automático no virtual network link existente entre essa rede e a zona privada analytics.internal. Antes da mudança, a zona continha 9.800 registros A criados manualmente ao longo de seis meses, referentes a endpoints privados, VMs legadas e aliases internos. A ativação do registro automático é bem-sucedida e as VMs com problema passam a ser resolvidas corretamente.
Qual é a consequência secundária mais relevante dessa ação?
A) Os 9.800 registros existentes são removidos automaticamente pelo Azure DNS, pois o registro automático assume controle exclusivo da zona e apaga entradas manuais conflitantes.
B) O limite de 10.000 registros gerados por registro automático será atingido rapidamente, pois cada VM na rede passa a contribuir com registros adicionais, podendo impedir o registro de novas VMs.
C) O registro automático altera o TTL de todos os registros existentes na zona para 10 segundos, aumentando a carga no resolvedor DNS do Azure.
D) Zonas com registro automático habilitado deixam de aceitar a criação manual de novos registros A, bloqueando atualizações futuras de endpoints privados.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: D
A pista central está na descrição do link original: ele foi criado sem registro automático habilitado. O registro db01.data.internal é um endpoint privado, ou seja, um registro criado manualmente, não gerado automaticamente. Isso significa que o link original nunca foi responsável por esse registro, ele existia na zona independentemente do link.
O que importa então é verificar se o registro ainda está na zona. O enunciado diz que a zona contém "47 registros do tipo A criados manualmente" e que o nslookup retorna Non-existent domain, o que indica que o registro db01.data.internal simplesmente não está entre esses 47. A hipótese mais defensável é que ele nunca foi criado, ou foi removido em algum momento, e o link anterior nunca o gerou por ter o registro automático desabilitado.
A informação sobre a rotação do cofre de chaves é o ruído proposital do cenário: ela gerou distrações operacionais, mas não tem relação causal com resolução DNS. O NAT ou as credenciais da aplicação não afetam a existência de registros em zonas DNS privadas.
A alternativa C é o distrator mais perigoso: atribui a falha a um estado transitório de propagação, levando o engenheiro a esperar em vez de investigar. Na prática, links ficam ativos em segundos e o problema já existia desde a recriação.
Gabarito — Cenário 2
Resposta: C
O cenário apresenta uma causa confirmada e uma restrição crítica explícita: o processo de governança exige aprovação do CAB para alterações em zonas DNS privadas. Essa restrição não é técnica, é organizacional, mas é igualmente vinculante.
A alternativa A é tecnicamente correta em ambiente sem restrições de governança: criar um virtual network link realmente não interrompe tráfego existente. Porém, ela ignora completamente o processo de aprovação obrigatório, o que a torna incorreta no contexto dado.
A alternativa B tenta contornar o processo via solução alternativa, mas um servidor DNS customizado com forwarder também é uma alteração de infraestrutura sujeita à mesma governança; além disso, introduz complexidade desnecessária quando a solução correta é simples.
A alternativa D é a mais perigosa: usa a janela de manutenção como justificativa para ignorar o CAB, o que viola o processo de governança mesmo que a ação seja tecnicamente inofensiva.
A disciplina correta aqui é: causa identificada não significa autorização para agir. Em ambientes regulados, a sequência é documentar, aprovar, executar.
Gabarito — Cenário 3
Resposta: B
A evidência definitiva está na saída do nslookup: o servidor consultado é 10.0.0.4, não 168.63.129.16. Isso significa que a VNet está configurada com um servidor DNS customizado que, ao receber a consulta por contosostorage.blob.core.windows.net, resolve diretamente via internet em vez de encaminhar para o resolvedor do Azure.
A cadeia correta de resolução para endpoints privados depende que o resolvedor chegue ao 168.63.129.16, que então consulta a zona privada e retorna o IP do endpoint. Um servidor customizado que não tem forwarder condicional para os sufixos privatelink quebra essa cadeia e devolve o IP público.
O NAT Gateway é o ruído irrelevante do cenário: ele opera em camada 3 e não intercepta nem altera consultas DNS. O fato de estar configurado há dois meses sem problemas reforça que não é a causa.
A alternativa C confunde o nome do registro na zona com o nome consultado: o CNAME público redireciona para contosostorage.privatelink.blob.core.windows.net, que é exatamente o nome que deve existir como registro A na zona privada. Isso está correto no enunciado.
A alternativa D representa um equívoco clássico: o registro automático é irrelevante para registros A criados manualmente, que existem na zona independentemente dessa configuração.
Gabarito — Cenário 4
Resposta: B
Habilitar o registro automático em uma rede com muitas VMs faz com que o Azure DNS passe a criar registros A para cada VM automaticamente. O limite de registros gerados por registro automático em uma única zona privada é de 10.000. A zona já possui 9.800 registros criados manualmente. Com o registro automático ativo, cada VM adicionada à rede contribui com novos registros, e a soma pode ultrapassar o limite rapidamente, fazendo com que novas VMs não consigam ter seus registros criados na zona.
A alternativa A é a mais sedutora, mas é falsa: o Azure DNS não remove registros manuais ao habilitar o registro automático. Registros criados manualmente e registros gerados automaticamente coexistem na zona; o Azure apenas adiciona os automáticos sem tocar nos existentes.
A alternativa D também é falsa: zonas com registro automático continuam aceitando registros A manuais normalmente. As duas modalidades não são mutuamente exclusivas.
A alternativa C inventa um comportamento que não existe: o TTL dos registros existentes não é alterado pela ativação do registro automático.
O impacto real é silencioso: não há erro imediato, mas à medida que novas VMs são criadas, seus registros simplesmente não aparecem na zona, reproduzindo exatamente o sintoma do Cenário 2 do laboratório técnico anterior.
Árvore de Troubleshooting: Design private DNS zones
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou verificável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, parta sempre pelo nó raiz, o sintoma de falha na resolução DNS, e siga as ramificações respondendo cada pergunta com base no que é observável no ambiente: configuração de DNS da VNet, existência e estado do virtual network link, presença do registro na zona e nome da zona. Cada resposta elimina uma classe de causas e estreita o caminho até a causa real. Os nós laranjas indicam pontos onde a investigação exige uma verificação adicional antes de concluir o diagnóstico, evitando ações precipitadas sobre hipóteses ainda não confirmadas.