Laboratório de Troubleshooting: Integrate Private Link and Private Endpoint with DNS
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que aplicações em uma VM no Spoke VNet passaram a falhar ao tentar se conectar a um Azure SQL Database via Private Endpoint após uma migração de DNS realizada na semana anterior. A migração consistiu em mover o gerenciamento de zonas DNS privadas de zonas individuais por equipe para uma zona centralizada no Hub VNet, gerenciada pelo time de plataforma.
O time de redes confirma que:
- O peering entre Hub e Spoke está ativo e funcionando
- A zona
privatelink.database.windows.netexiste no Hub e contém o registro A correto com o IP privado do endpoint - O Private Endpoint está provisionado e com status
Succeeded - A VM consegue fazer ping para outros recursos dentro da Spoke VNet sem problemas
- O Azure Policy de governança de DNS foi aplicado há três dias
A equipe executa o seguinte comando a partir da VM:
nslookup myserver.database.windows.net
Saída observada:
Server: 168.63.129.16
Address: 168.63.129.16
Non-authoritative answer:
Name: myserver.privatelink.database.windows.net
Address: 52.179.xxx.xxx
Qual é a causa raiz da falha na resolução privada?
A) O registro A na zona privatelink.database.windows.net está apontando para o IP público do servidor SQL.
B) A zona DNS privada privatelink.database.windows.net não está vinculada à Spoke VNet onde a VM está localizada.
C) O Azure Policy aplicado há três dias está bloqueando a criação de registros A em zonas DNS privadas.
D) O peering entre Hub e Spoke não foi configurado com a opção "Use remote gateways", impedindo a propagação DNS.
Cenário 2 — Decisão de Ação
A causa de um incidente em produção foi identificada com precisão: um Azure DNS Private Resolver foi implantado em uma VNet de hub para permitir que servidores DNS on-premises encaminhem consultas de zonas privatelink.* ao Azure. No entanto, o inbound endpoint do resolver foi criado em uma subnet que não possui a delegação obrigatória Microsoft.Network/dnsResolvers.
O ambiente possui as seguintes restrições no momento:
- A subnet em questão contém outras cargas de trabalho (VMs de monitoramento) que não podem ser movidas imediatamente
- O inbound endpoint está com status
Failede não está respondendo a consultas - Um segundo horário de manutenção está disponível daqui a quatro horas
- A equipe de plataforma possui permissão para criar novas subnets e modificar o DNS Resolver
- Não é possível deletar e recriar o inbound endpoint na mesma subnet sem corrigir a delegação
Qual é a ação correta a tomar agora?
A) Adicionar a delegação Microsoft.Network/dnsResolvers à subnet existente e aguardar a recuperação automática do inbound endpoint.
B) Criar uma nova subnet com a delegação correta, recriar o inbound endpoint nessa subnet e atualizar os conditional forwarders on-premises para o novo IP.
C) Aguardar o próximo horário de manutenção para mover as VMs de monitoramento e somente então corrigir a delegação na subnet original.
D) Remover o inbound endpoint com status Failed, corrigir a delegação na subnet e recriar o endpoint no mesmo endereço IP.
Cenário 3 — Causa Raiz
Um engenheiro está investigando por que uma VM em uma VNet isolada, sem peering e sem integração com hub, não consegue resolver o FQDN de um Private Endpoint para uma conta de armazenamento. O ambiente foi configurado manualmente pelo próprio engenheiro há dois dias.
O engenheiro compartilha o seguinte inventário de configuração:
| Componente | Status |
|---|---|
| Private Endpoint | Provisionado, IP: 10.0.1.5 |
Zona DNS privada privatelink.blob.core.windows.net | Existe |
Registro A mystorageaccount na zona | Presente, aponta para 10.0.1.5 |
| Vínculo da zona à VNet isolada | Presente |
| NSG na subnet do Private Endpoint | Permite tráfego de saída porta 443 |
O engenheiro executa o diagnóstico a partir da VM:
nslookup mystorageaccount.blob.core.windows.net 168.63.129.16
Saída:
Server: 168.63.129.16
Address: 168.63.129.16
Non-authoritative answer:
Name: mystorageaccount.privatelink.blob.core.windows.net
Address: 52.239.xxx.xxx
O engenheiro nota que o NSG da subnet do endpoint foi recentemente modificado para bloquear tráfego na porta 53. A conta de armazenamento tem acesso público desabilitado.
Qual é a causa raiz do comportamento observado?
A) O NSG está bloqueando tráfego DNS na porta 53, impedindo que o Azure DNS alcance a zona privada.
B) O nome do registro A na zona DNS privada não corresponde ao subdomínio esperado pelo processo de resolução do Azure.
C) O vínculo da zona à VNet não tem a opção de auto-registration habilitada, o que impede a resolução de registros manuais.
D) A zona DNS privada existe mas não está vinculada corretamente à VNet onde a VM realiza a consulta.
Cenário 4 — Sequência de Diagnóstico
Uma equipe recebe o seguinte relato de um sistema de monitoramento:
Aplicação em produção retorna erro de conexão ao tentar acessar um Azure Key Vault via FQDN. O erro ocorre somente para clientes on-premises. Clientes dentro da VNet Azure acessam normalmente o mesmo Key Vault pelo mesmo FQDN.
A equipe dispõe dos seguintes passos de investigação:
- Verificar se o inbound endpoint do Azure DNS Private Resolver possui um IP acessível pela rede on-premises
- Confirmar que a zona
privatelink.vaultcore.azure.netexiste e contém o registro A correto - Verificar se os servidores DNS on-premises possuem um conditional forwarder para
privatelink.vaultcore.azure.net - Confirmar que o conditional forwarder on-premises aponta para o IP do inbound endpoint, e não para
168.63.129.16 - Testar a resolução do FQDN a partir de um servidor on-premises usando o servidor DNS configurado
Qual é a sequência correta de diagnóstico para esse cenário?
A) 2 -> 1 -> 3 -> 4 -> 5
B) 3 -> 2 -> 1 -> 4 -> 5
C) 1 -> 2 -> 4 -> 3 -> 5
D) 2 -> 3 -> 1 -> 4 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na saída do nslookup: o Azure DNS (168.63.129.16) está respondendo, mas está retornando o IP público. Isso indica que o resolver está funcionando, mas não encontra a zona privada vinculada à VNet da VM. Se o registro A estivesse incorreto (alternativa A), o IP retornado seria privado, mas errado. O problema está na ausência do vínculo entre a zona DNS privada centralizada no Hub e a Spoke VNet onde a VM reside.
A informação sobre o Azure Policy é propositalmente irrelevante: o Policy pode ter sido aplicado, mas a evidência técnica no nslookup aponta diretamente para um problema de vínculo de zona, não de registro. Focar no Policy seria o erro clássico de confundir correlação temporal com causalidade.
A alternativa D é o distrator mais perigoso: a opção "Use remote gateways" no peering controla tráfego de dados via gateway, não propagação de vínculos DNS. O DNS privado do Azure é governado exclusivamente por vínculos de zona, independentemente de configurações de gateway no peering.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é que a subnet em questão contém VMs de monitoramento que não podem ser movidas imediatamente. Isso elimina a alternativa C (aguardar manutenção para mover as VMs) como ação imediata e também inviabiliza a alternativa A, pois adicionar a delegação a uma subnet com cargas de trabalho existentes pode ser bloqueado pelo Azure quando há recursos alocados que conflitam com a delegação.
A alternativa D ignora um fato operacional importante: ao deletar o inbound endpoint, o IP privado associado é liberado e provavelmente não será o mesmo na recriação, o que exigiria atualização dos conditional forwarders de qualquer forma, porém sem garantia de consistência.
A ação correta é criar uma nova subnet com delegação adequada, recriar o inbound endpoint e atualizar os forwarders on-premises. Essa abordagem resolve o problema dentro da janela disponível sem impactar as VMs de monitoramento e sem depender de uma janela futura.
Gabarito — Cenário 3
Resposta: B
O inventário mostra que o vínculo da zona à VNet existe e o registro A também existe. Com base nisso, as alternativas C e D são eliminadas diretamente pela evidência: vínculo presente e registro A presente.
A pista sobre o NSG bloqueando a porta 53 é propositalmente irrelevante. O Azure DNS (168.63.129.16) é um resolver virtual da plataforma Azure que opera internamente na infraestrutura da VNet: ele não passa por NSGs. Bloquear a porta 53 em um NSG de subnet do Private Endpoint não afeta a resolução DNS de VMs em outras subnets.
A causa real está no nome do registro A. O processo de resolução do Azure para Private Endpoints funciona da seguinte forma: o FQDN mystorageaccount.blob.core.windows.net é redirecionado via CNAME para mystorageaccount.privatelink.blob.core.windows.net. O registro A na zona privada deve ter o nome exato mystorageaccount, sem o sufixo .blob.core.windows.net. Se o registro foi criado com um nome diferente (por exemplo, o FQDN completo como nome), a correspondência falha e o Azure DNS cai na resolução pública.
O distrator mais perigoso é a alternativa A, porque o detalhe do NSG na porta 53 foi inserido deliberadamente para atrair diagnósticos precipitados.
Gabarito — Cenário 4
Resposta: A
A sequência correta de diagnóstico segue a lógica de validar primeiro a infraestrutura de dados (a zona DNS e o registro) antes de investigar o caminho de encaminhamento, e somente então confirmar se o caminho on-premises está apontando para o lugar certo.
A sequência A (2 -> 1 -> 3 -> 4 -> 5) está correta porque:
- O passo 2 confirma que a zona e o registro existem corretamente no Azure, estabelecendo que o problema é de caminho, não de dados
- O passo 1 verifica se o inbound endpoint tem IP acessível de on-premises, que é a infraestrutura de roteamento necessária antes de qualquer configuração de forwarder
- O passo 3 verifica se o conditional forwarder existe no DNS on-premises
- O passo 4 valida se o forwarder aponta para o destino correto (inbound endpoint) e não para
168.63.129.16, que é inacessível de on-premises - O passo 5 é o teste final que valida toda a cadeia
A sequência B é um erro comum: verificar o forwarder antes de confirmar que o destino existe e é alcançável leva a diagnósticos circulares. A sequência C inverte a ordem lógica ao verificar o IP do endpoint antes de confirmar que os dados DNS estão corretos. Validar o caminho sem ter dados corretos no destino é ineficiente.
Árvore de Troubleshooting: Integrate Private Link and Private Endpoint with DNS
Legenda de cores:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial ou ponto de entrada |
| Azul | Pergunta de diagnóstico (decisão verificável) |
| Vermelho | Causa identificada ou falha de configuração |
| Verde | Ação corretiva ou resolução confirmada |
Diante de um problema real, comece pelo nó raiz (sintoma observado) e responda cada pergunta de diagnóstico com base no que é verificável no ambiente: existência de recurso, status de configuração, resultado de comando. Cada ramificação elimina uma classe de hipótese. Siga o caminho que corresponde ao estado real observado até alcançar um nó vermelho, que identifica a causa, ou verde, que confirma que a cadeia está íntegra. Nunca pule uma pergunta intermediária: o nó de verificação precedente frequentemente elimina o distrator mais plausível do nível seguinte.