O exame AZ-700 pergunta qual serviço DNS se aplica a cada cenário. Ao contrário de roteamento ou firewalls, o DNS é invisível quando funciona — mas quando falha, Private Endpoints resolvem para IPs públicos e VMs dentro de uma VNet não conseguem localizar nomes internos. O Azure resolve isso com três pilares: Public Zone, Private DNS Zone e Private Resolver.
Azure DNS Public Zone: A lista telefônica pública
Pense em uma lista telefônica da cidade, disponível para qualquer pessoa que a abra. Azure DNS Public Zone é exatamente isso — um diretório acessível publicamente para domínios de internet como contoso.com, gerenciado completamente dentro do Azure.
Quando você cria uma Public Zone, o Azure atribui automaticamente quatro servidores de nomes (no formato ns1-xx.azure-dns.com). Em seguida, você precisa atualizar os registros NS no seu registrador de domínio para apontar para esses quatro endereços. A ordem importa: primeiro crie a Zone para conhecer os endereços NS e depois atualize o registrador.
Os tipos de registro compatíveis incluem A, AAAA, CNAME, MX e TXT. O Azure DNS opera com Anycast, sem ponto único de falha.
Private DNS Zone: O diretório interno da empresa
Toda grande empresa tem uma lista de contatos internos que nunca sai do edifício — o ramal interno. Azure Private DNS Zone gerencia nomes que são válidos apenas dentro da sua VNet.
Criar uma Private Zone sozinha não é suficiente. Você deve anexar um VNet Link à Zone antes que as VMs dessa VNet possam usá-la para resolução de nomes. Existem dois modos de link.
Registro automático (Auto-registration): quando uma VM é criada na VNet vinculada, um registro A é automaticamente registrado na Private Zone. Somente resolução (Resolution only): os registros são gerenciados manualmente pelo administrador; a VNet usa a Zone apenas para consultas.
Uma única Private Zone pode ser vinculada a múltiplas VNets, e vice-versa. O registro automático, porém, só pode ser ativado em uma Private Zone por VNet.
!Azure DNS Zona Pública vs Zona Privada
Private Endpoints e o domínio privatelink
Imagine um armazém com uma entrada exclusiva para funcionários nos fundos. Os caminhões de entrega usam o portão principal, mas os funcionários entram diretamente pela porta privada. Azure Private Endpoint é essa porta privada para serviços PaaS.
Quando você associa um Private Endpoint a um serviço PaaS, ele fica acessível por um IP privado. Porém, sem atualizar o DNS, os clientes continuarão enviando solicitações para o IP público.
A solução é uma Private DNS Zone chamada . Para uma conta de armazenamento, crie a Zone , vincule-a à VNet e adicione um registro A apontando para o IP privado do Private Endpoint. O cliente dentro da VNet receberá o IP privado ao consultar esse nome. A opção de integração de DNS privado no portal automatiza esse processo.
Azure DNS Private Resolver: A telefonista central da empresa
Imagine a telefonista da central que conecta chamadas recebidas ao ramal correto e também realiza chamadas externas pela linha adequada. Azure DNS Private Resolver cumpre exatamente esse papel entre redes locais e o Azure.
Private Resolver tem dois tipos de endpoints.
Inbound Endpoint: fornece um endereço IP dentro de uma VNet para o qual clientes externos (incluindo resolvedores locais) podem enviar consultas DNS. Quando o servidor DNS local está configurado com um encaminhador condicional apontando para esse IP, clientes no ambiente local conseguem resolver nomes privados do Azure. Outbound Endpoint: encaminha consultas DNS originadas dentro do Azure para resolvedores externos, como servidores DNS locais. Um DNS Forwarding Ruleset define quais sufixos de domínio vão para qual resolvedor de destino.
Antes do Private Resolver existir, era necessário implantar VMs de DNS personalizadas dentro da VNet. O Private Resolver substitui isso por um serviço completamente gerenciado.
DNS de horizonte dividido (Split-Horizon)
Imagine um edifício com duas entradas: uma para o público e outra para os funcionários, ambas com o mesmo endereço, mas levando a recepções diferentes. O DNS de horizonte dividido funciona da mesma forma — o mesmo nome de domínio retorna endereços IP diferentes dependendo da origem da consulta.
Por exemplo, resolve para um IP público para clientes de internet (via Public Zone) e para um IP privado para VMs dentro de uma VNet (via Private Zone com o mesmo nome). Para configurar isso, você cria tanto uma Public Zone quanto uma Private Zone para e vincula a Private Zone à VNet relevante. O Azure prioriza a Private Zone para consultas que se originam dentro da VNet.
Esse padrão aparece frequentemente quando um serviço precisa ser acessível tanto da internet quanto de redes internas, ou quando Private Endpoints e endpoints públicos coexistem para o mesmo serviço.
Comparação: Qual abordagem DNS escolher?
| Cenário | Solução | |:--|:--| | Gerenciar domínio público de internet | Azure DNS Public Zone | | Resolução de nomes internos dentro de uma VNet | Private DNS Zone + VNet Link | | Resolução de nomes de Private Endpoint PaaS | Private Zone privatelink.{service} | | Ambiente local → nomes privados do Azure | Private Resolver Inbound Endpoint | | Azure → encaminhamento DNS para servidores locais | Private Resolver Outbound Endpoint + Ruleset | | Mesmo nome, IPs diferentes dentro e fora | Split-horizon (Public Zone + Private Zone coexistem) | | Resolução de nomes padrão da VNet | DNS fornecido pelo Azure (168.63.129.16) |
O DNS fornecido pelo Azure no endereço 168.63.129.16 é o resolvedor padrão de cada VNet. Se você configurar um servidor DNS personalizado no nível da VNet, esse servidor deve encaminhar para 168.63.129.16 como encaminhador condicional para que os nomes internos do Azure continuem sendo resolvidos corretamente.
Armadilha comum: quando Private Endpoint ainda resolve para IP público
Um engenheiro novo cria um Private Endpoint e abre imediatamente um chamado: 'conexão recusada.' A causa raiz é quase sempre o DNS. Criar o Private Endpoint é apenas metade do trabalho — se o DNS ainda aponta para o IP público, os clientes ignoram o caminho de rede privado.
Siga esta lista de verificação.
A Private Zone existe? Essa Zone está vinculada à VNet do cliente? A Zone contém um registro A apontando para o IP privado do Private Endpoint? A VNet do cliente está usando o DNS fornecido pelo Azure (168.63.129.16), ou seu servidor DNS personalizado encaminha os nomes do Azure para 168.63.129.16?
Para clientes em ambiente local, o servidor DNS local precisa ter um encaminhador condicional para o sufixo de domínio, apontando para o IP do Inbound Endpoint do Private Resolver.
Resumo do Exame
Domínio público de internet, delegação de NS para o Azure -- Azure DNS Public Zone Nomes internos de VNet, registro automático de VMs -- Private DNS Zone + VNet Link (Auto-registration) Resolução de nomes de Private Endpoint PaaS -- Private Zone privatelink.{service} + registro A Ambiente local → nomes internos do Azure -- Private Resolver Inbound Endpoint Azure → encaminhamento DNS para servidores locais -- Private Resolver Outbound Endpoint + Forwarding Ruleset Mesmo nome, IPs diferentes dentro e fora -- Split-horizon (Public Zone + Private Zone coexistem) Endereço DNS padrão da VNet -- 168.63.129.16 (DNS fornecido pelo Azure) Limite do Auto-registration -- apenas uma Private Zone por VNet pode tê-lo ativado DNS personalizado + Private Zone juntos -- DNS personalizado deve encaminhar para 168.63.129.16 Principal motivo de falha do Private Endpoint -- configuração DNS ausente (sem Private Zone ou sem VNet Link)
Azure DNS = lista telefônica pública, Private DNS Zone = diretório interno, Private Resolver = telefonista central