DNS privado do Azure sobre VPN: endpoint do resolvedor ou forwarder

Um servidor local alcança uma VM do Azure por endereço privado e ainda assim não consegue resolver o nome de host privado, o que leva as pessoas a procurar um túnel quebrado. O túnel está bem. O que falta é uma fronteira de DNS: nada do lado local sabe que uma determinada zona privada do Azure deve ser respondida por um resolvedor dentro da VNet. Dois desenhos fecham essa lacuna, e diferem no que você acaba operando, não em se as consultas funcionam.

O túnel transporta consultas, não conhecimento de zonas

Uma conexão site a site dá aos pacotes uma rota entre as duas redes. Ela não diz ao servidor DNS local qual espaço de nomes pertence ao Azure nem qual endereço deve responder, então a consulta ou vai para a internet e volta vazia, ou nunca deixa o resolvedor local.

A correção tem duas metades fáceis de separar. Uma metade é um resolvedor dentro da VNet que aceita consultas que chegam pelo túnel. A outra é um forwarder condicional no lado local que envia exatamente um espaço de nomes para esse resolvedor. Nenhuma metade funciona sozinha.

Suponha que a zona seja cloud.corp.example pelo resto desta explicação, e trate cada endereço como ilustrativo.

Opção A: o endpoint de entrada gerenciado

O Azure DNS Private Resolver fornece um endpoint de entrada que aceita consultas DNS de fora da VNet. Você o implanta em uma sub-rede delegada dedicada, vincula a zona privada a essa VNet e anota o endereço de entrada que o serviço atribui.

No servidor DNS local, você então cria um forwarder condicional para o espaço de nomes exato em direção a esse endereço:

Namespace: cloud.corp.example
Forward to: 10.20.2.4

O procedimento de DNS híbrido da Microsoft documenta tanto o vínculo da zona quanto a etapa do forwarder. O caminho gerenciado não deixa nenhum software DNS para corrigir, e o endereço do endpoint permanece estável durante toda a vida do recurso.

O preço é que agora você possui um recurso de resolvedor, sua delegação de sub-rede e seu custo, que é real mesmo quando o volume de consultas é mínimo.

Opção B: uma VM forwarder dentro da VNet

O desenho mais antigo executa software DNS em uma VM comum dentro da VNet: Windows DNS, BIND ou dnsmasq, com a zona privada hospedada localmente ou encaminhada ao resolvedor do Azure em 168.63.129.16. O forwarder condicional local aponta para o endereço privado dessa VM.

Esta opção é familiar para equipes que já operam servidores DNS, e pode carregar lógica extra como registro ou respostas split-horizon. Ela também herda todos os deveres operacionais de um servidor DNS: correções, uma segunda instância para disponibilidade, monitoramento e um caminho de reconstrução quando a VM é substituída e seu endereço muda.

Um host comum de VNet não é um proxy DNS até que o serviço esteja instalado e autorizado a responder a esses clientes, e é esse passo que as pessoas pulam ao clonar uma VM.

Qual se encaixa na sua operação

A comparação não é sobre qual desenho é mais rápido. É sobre se você quer operar software DNS, e se o volume de consultas justifica um recurso gerenciado que cobra por endpoint e por consulta.

Qualquer que seja a linha que decida, a regra do forwarder local é a mesma. Essa é a parte que deve existir nos dois desenhos, e é a que mais frequentemente falta quando alguém relata que a resolução funciona de dentro do Azure, mas não do escritório.

Verifique o caminho em ordem

Confirme que a zona está vinculada à VNet que contém o resolvedor, e que o forwarder local nomeia o espaço de nomes e não um domínio pai. Um forwarder para corp.example não corresponderá a cloud.corp.example a menos que o próprio resolvedor delegue, e a divergência produz uma resposta negativa limpa que parece um registro ausente.

Depois verifique se a consulta chega ao endpoint: a origem local precisa de uma rota para o endereço do resolvedor e um caminho de volta, e a porta 53 tanto UDP quanto TCP deveria ser permitida onde a política permitir. Um NSG não pode fornecer um registro de zona ausente, e uma zona correta não pode responder a uma consulta que nunca chega.

Mantenha o FQDN solicitado ao lado do resolvedor escolhido ao diagnosticar, e separe um tempo limite de uma resposta negativa. Um tempo limite é um problema de rota ou de política. Uma resposta negativa significa que a consulta chegou e o espaço de nomes não coincidia. Ordem de trabalho: vincule a zona, adicione o forwarder condicional, abra a porta 53 nos dois sentidos, teste um nome a partir do local e só então olhe a autorização própria da aplicação.