Azure DNS Private Resolver na prática: o desenho certo para ambientes híbridos com Private Endpoint

Private Endpoint sem DNS correto é implantação pela metade.

Em muitos projetos, o endpoint privado é criado, o acesso público é desabilitado e a conectividade com Azure já existe via VPN ou ExpressRoute. Mesmo assim, a aplicação falha. O motivo costuma estar no DNS: o nome continua resolvendo para o destino errado.

O Azure DNS Private Resolver resolve esse problema ao criar uma ponte gerenciada entre o DNS do Azure e o DNS corporativo, sem obrigar a empresa a manter servidores DNS em VM apenas para encaminhamento.

Resumo em uma frase: o Azure DNS Private Resolver ajuda Azure e on-premises a resolverem nomes entre si de forma mais simples, segura e governável.

O problema

Private Endpoint muda o caminho de acesso ao serviço, mas o cliente continua usando o nome conhecido, como um endereço de Storage, SQL ou Key Vault.

A diferença é que esse nome precisa resolver para o IP privado do Private Endpoint. Se o DNS não estiver correto, a rede pode estar perfeita e, ainda assim, a aplicação não funcionar.

Os sintomas mais comuns são:

aplicação tentando acessar o endpoint público;
on-premises sem conseguir resolver nomes privados do Azure;
spokes com configurações diferentes entre si;
excesso de forwarders em VM;
troubleshooting longo entre times de rede, cloud e aplicação.

Ponto-chave: em ambiente híbrido, Private Endpoint não é apenas rede. É rede + DNS + governança operacional.

Conceitos em 1 minuto

Inbound endpoint

É um IP privado no Azure usado para receber consultas DNS vindas de fora da VNet, como do ambiente on-premises.

Na prática, é para esse IP que o DNS corporativo encaminha perguntas quando precisa resolver nomes privados do Azure.

Exemplo: o DNS on-premises encaminha consultas de serviços Azure para o inbound endpoint no hub.

Outbound endpoint

É o componente usado pelo Azure DNS Private Resolver para enviar consultas DNS para outros servidores DNS, como DNS on-premises, AD DNS, Infoblox, BIND ou outro resolver corporativo.

Exemplo: uma VM no Azure precisa resolver sistema.corp.local; o outbound endpoint encaminha essa consulta para o DNS corporativo.

DNS forwarding ruleset

É o conjunto de regras que define: “quando a consulta for para este domínio, encaminhe para este servidor DNS”.

Exemplo: consultas para corp.local devem ser encaminhadas para os servidores DNS on-premises.

Ruleset link

É o vínculo que faz uma VNet usar um ruleset.

Em termos simples: o ruleset contém as regras, e o ruleset link permite que uma VNet consuma essas regras.

Desenho recomendado

Para ambientes enterprise em hub-and-spoke, o desenho mais comum e sustentável é:

Private DNS Zones centralizadas no hub;
Azure DNS Private Resolver no hub;
inbound endpoint com IP estático;
outbound endpoint com ruleset;
DNS corporativo com conditional forwarders para o Azure;
Spokes vinculadas ao ruleset quando precisarem consumir regras de encaminhamento DNS.

Esse modelo reduz exceções, evita servidores DNS dedicados apenas para forwarding e facilita a governança.

Fluxo simplificado:

on-premises pergunta ao Azure usando o inbound endpoint;

Azure pergunta ao on-premises usando outbound endpoint + ruleset;

spokes usam as regras do hub por meio do ruleset link.

Legenda: Padrão hub-and-spoke com DNS Private Resolver centralizado no hub.

E se a empresa já tem DNS corporativo?

Na maioria dos casos, não é necessário trocar tudo.

Esse ponto é importante porque muitos ambientes já possuem AD DNS, Infoblox, BIND ou outra solução corporativa consolidada. O Azure DNS Private Resolver não precisa substituir essa base. Ele normalmente entra como uma camada de integração.

Um desenho saudável fica assim:

o DNS corporativo continua sendo autoridade para os domínios internos da empresa;
o Azure DNS Private Resolver integra Azure, Private DNS Zones e on-premises;
o DNS on-premises cria conditional forwarders para encaminhar consultas ao inbound endpoint;
workloads no Azure usam outbound endpoint + ruleset para consultar nomes corporativos.

Boa prática: preserve o DNS corporativo que já funciona e use o Private Resolver para eliminar complexidade desnecessária na integração com Azure.

Quando usar

O Azure DNS Private Resolver faz bastante sentido quando existe pelo menos um destes cenários:

1. Private Endpoint acessado do on-premises

Aplicações no datacenter precisam acessar Azure SQL, Storage, Key Vault ou outros serviços PaaS por Private Endpoint.

2. Várias spokes consumindo serviços privados

Ambientes com muitas VNets precisam resolver nomes privados sem criar uma malha difícil de manter.

3. DNS corporativo já existe

A empresa não quer substituir o DNS atual, mas precisa integrar Azure e on-premises de forma padronizada.

4. Redução de forwarders em VM

O ambiente possui VMs apenas para encaminhamento DNS. O Private Resolver pode reduzir patching, hardening e operação manual.

5. Ambientes multi-region

Quando há múltiplas regiões, DNS precisa fazer parte do desenho de continuidade, e não ser tratado como detalhe no final.

Legenda: O Private Resolver complementa o DNS corporativo existente, sem exigir substituição completa.

Quando talvez não usar

O Azure DNS Private Resolver pode ser desnecessário quando:

o ambiente é somente Azure e não possui necessidade de resolução híbrida;
as VNets já resolvem corretamente usando Private DNS Zones vinculadas diretamente;
não existe integração com on-premises, DNS corporativo ou múltiplas redes;
o custo e a complexidade do serviço não se justificam para um cenário pequeno.

Boa regra: se o problema é apenas resolver nomes privados dentro de uma única VNet, provavelmente Private DNS Zone já resolve. O Private Resolver começa a fazer mais sentido quando existe integração entre Azure, on-premises e múltiplas redes.

Modelo distribuído ou centralizado?

Existem dois padrões comuns.

Modelo distribuído

As VNets continuam usando Azure-provided DNS. O resolver fica no hub, e as spokes consomem regras por ruleset link.

Esse modelo tende a ser mais simples quando você quer manter o comportamento padrão do Azure e evitar mudanças amplas nas configurações de DNS das VNets.

Modelo centralizado

As VNets usam custom DNS apontando para uma camada central no hub.

Esse modelo faz mais sentido quando a empresa já tem operação de DNS centralizada, proxy DNS, Azure Firewall DNS Proxy ou appliances controlando toda a resolução.

Minha recomendação prática: comece pelo modelo distribuído quando não houver exigência clara de DNS centralizado. Use o modelo centralizado quando ele já fizer parte do padrão operacional da empresa.

Erros comuns

Tratar Private Endpoint como tema só de rede

Criar o endpoint privado não basta. O nome precisa resolver para o IP privado correto.

Encaminhar para a zona errada

Um erro comum é configurar o conditional forwarder diretamente para a zona privatelink.*.

Em cenários com Private Endpoint e DNS customizado, o encaminhamento condicional deve considerar o domínio público recomendado do serviço, como database.windows.net, e não diretamente privatelink.database.windows.net.

Esse detalhe parece pequeno, mas costuma causar falhas de resolução e troubleshooting desnecessário.

Usar IP dinâmico no inbound endpoint

Se o DNS on-premises aponta para esse IP, prefira IP estático. Isso reduz risco operacional em caso de reprovisionamento.

Criar exceções por spoke

Sem padrão, cada spoke vira uma exceção. Isso aumenta custo de operação e torna troubleshooting mais difícil.

Ignorar regionalidade

Rulesets podem ser vinculados a VNets na mesma região. Em arquiteturas multi-region, isso precisa ser considerado no desenho.

Criar loop de DNS com ruleset link

Se uma regra do ruleset encaminha consultas para o inbound endpoint do próprio hub, cuidado ao vincular esse ruleset à mesma VNet onde o inbound endpoint está provisionado.

Esse desenho pode causar loop de DNS. O ruleset link deve ser usado para VNets que precisam consumir as regras, como spokes, e não aplicado automaticamente em todo lugar sem análise.

Legenda: A maior parte dos problemas aparece quando DNS é tratado como detalhe final da arquitetura.

Checklist de implantação

Antes de colocar em produção, valide:

Private DNS Zones corretas para cada serviço;
hub vinculado às zonas necessárias;
Azure DNS Private Resolver implantado no hub;
inbound endpoint com IP estático;
outbound endpoint criado;
DNS forwarding ruleset configurado;
VNets consumidoras vinculadas ao ruleset quando necessário;
conditional forwarders configurados no DNS corporativo;
desenho regional documentado;
monitoramento e teste de resolução a partir do Azure e do on-premises.

Conclusão

O Azure DNS Private Resolver não deve ser visto apenas como mais um recurso de DNS. Em ambientes híbridos com Private Endpoint, ele pode ser a peça que torna a arquitetura realmente operável.

O desenho mais saudável é aquele que reduz exceções, respeita o DNS corporativo existente e centraliza o que precisa ser governado. Para a maioria dos ambientes enterprise, isso significa usar o resolver no hub, integrar com Private DNS Zones e permitir que Azure e on-premises resolvam nomes de forma previsível.

Mensagem final: Private Endpoint sem DNS bem desenhado é risco operacional. Azure DNS Private Resolver ajuda a transformar esse desenho em um padrão sustentável para ambientes híbridos.