Laboratório Técnico: Configure public and private DNS zones
Questões
Questão 1 — Múltipla Escolha
Uma equipe de plataforma precisa que máquinas virtuais em uma VNet resolvam nomes do domínio interno.contoso.corp sem expor qualquer registro publicamente. A VNet já está vinculada a uma zona DNS privada com esse nome, mas as VMs continuam falhando na resolução.
Qual é a causa mais provável do problema?
A. A zona DNS privada não suporta domínios com sufixo .corp e exige .local
B. A vinculação da VNet à zona privada foi criada sem habilitar o registro automático, que é obrigatório para resolução
C. A vinculação foi criada, mas o auto-registro não está relacionado à resolução; falta habilitar a opção Enable DNS resolution na configuração da VNet link
D. As VMs precisam apontar manualmente para o endereço IP 168.63.129.16 em suas configurações de DNS da NIC para que a zona privada seja consultada
Questão 2 — Cenário Técnico
Um arquiteto está configurando resolução DNS para um ambiente híbrido. Máquinas on-premises precisam resolver registros em uma zona DNS privada do Azure (db.interno.azure). O DNS on-premises é um Windows Server 2019.
A equipe propõe a seguinte solução:
On-premises DNS Server
└── Conditional Forwarder: db.interno.azure
└── Encaminha para: 168.63.129.16
Após a configuração, os servidores on-premises continuam sem resolver os nomes.
Qual é o erro na abordagem?
A. O sufixo .azure não é suportado em zonas DNS privadas do Azure
B. O endereço 168.63.129.16 só pode ser consultado por recursos dentro de uma VNet do Azure; consultas originadas on-premises não chegam a esse resolvedor
C. Conditional Forwarders não são suportados para zonas DNS privadas; é necessário usar delegação NS
D. A zona privada precisa ter um registro NS explícito apontando para 168.63.129.16 antes de aceitar consultas externas
Questão 3 — Verdadeiro ou Falso
Uma zona DNS privada do Azure pode ser vinculada a VNets em regiões diferentes da região onde a zona foi criada, e a resolução de nomes funcionará normalmente nessas VNets remotas.
Questão 4 — Cenário Técnico
Uma empresa usa Azure DNS público para o domínio contoso.com. A equipe precisa delegar o subdomínio api.contoso.com para uma zona DNS separada gerenciada por outro time, que já criou a zona api.contoso.com no Azure DNS.
O time raiz executa os seguintes passos:
1. Obtém os nameservers da zona api.contoso.com:
ns1-05.azure-dns.com
ns2-05.azure-dns.net
ns3-05.azure-dns.org
ns4-05.azure-dns.info
2. Cria, na zona contoso.com, um registro do tipo A apontando
api.contoso.com para os IPs desses nameservers
A delegação não funciona. Qual é o erro cometido?
A. A delegação de subdomínio no Azure DNS exige que ambas as zonas estejam na mesma assinatura
B. O registro criado deveria ser do tipo NS, não A, apontando para os hostnames dos nameservers da zona filha
C. Os nameservers do Azure DNS não podem ser usados em delegações internas entre zonas do mesmo provedor
D. A zona api.contoso.com deveria ser uma zona privada, não pública, para aceitar delegação de subdomínio
Questão 5 — Múltipla Escolha
Uma organização tem duas VNets: VNet-A (East US) e VNet-B (West Europe). Ambas estão vinculadas à mesma zona DNS privada app.interno. O auto-registro está habilitado nas duas vinculações.
Uma VM chamada vm-web-01 é criada na VNet-A. Qual comportamento é esperado?
A. Um registro A para vm-web-01.app.interno é criado automaticamente, e VMs na VNet-B conseguem resolver esse nome
B. Um registro A para vm-web-01.app.interno é criado automaticamente, mas apenas VMs na VNet-A conseguem resolvê-lo, pois resolução entre VNets vinculadas não é suportada
C. Nenhum registro é criado automaticamente porque o auto-registro só funciona quando há exatamente uma VNet vinculada à zona
D. O registro A é criado, mas com TTL fixo de 10 segundos, tornando-o inutilizável para cenários de produção
Gabarito e Explicações
Gabarito — Questão 1
Resposta: C
A opção de auto-registro em uma VNet link controla se as VMs daquela VNet têm seus registros A/AAAA criados automaticamente na zona privada. Ela não tem relação com a capacidade de resolução. O que permite que uma VNet resolva nomes de uma zona privada é a existência da vinculação (VNet link) em si, independentemente do auto-registro estar ativo.
O ponto crítico aqui é que a vinculação pode ser criada corretamente e ainda assim a resolução falhar se o DNS das VMs não estiver usando o resolvedor do Azure. Por padrão, VMs em uma VNet consultam 168.63.129.16 automaticamente via DHCP, sem necessidade de configuração manual na NIC. Portanto, a alternativa D representa um equívoco comum: configurar manualmente o DNS da NIC para esse endereço seria redundante e não resolve o problema descrito.
O erro mais provável é que a VNet link não estava com a opção de resolução ativa ou a VNet foi configurada com DNS customizado apontando para outro servidor, que não encaminha para 168.63.129.16. A alternativa C descreve corretamente a distinção entre os dois controles da vinculação.
Gabarito — Questão 2
Resposta: B
O endereço 168.63.129.16 é um IP virtual mantido pela plataforma do Azure e acessível apenas a partir de recursos que trafegam pela rede do Azure, ou seja, dentro de uma VNet. Consultas DNS originadas de servidores on-premises chegam pela internet ou por conexões ExpressRoute/VPN, mas ainda assim não alcançam esse resolvedor diretamente como um endpoint externo.
A solução correta para resolução híbrida de zonas privadas é implantar um DNS Resolver privado do Azure (Azure DNS Private Resolver) com um endpoint de entrada (inbound endpoint) em uma sub-rede da VNet. Esse endpoint recebe um IP privado acessível via VPN ou ExpressRoute, e o conditional forwarder on-premises aponta para esse IP, não para 168.63.129.16.
As alternativas A e D são distratores que introduzem restrições inexistentes. A alternativa C confunde o mecanismo de delegação com o de forwarding.
Gabarito — Questão 3
Resposta: Verdadeiro
Zonas DNS privadas do Azure são recursos globais, não regionais. A região selecionada durante a criação é apenas para fins de metadados de billing e não afeta o escopo funcional da zona. Uma zona privada pode ser vinculada a VNets em qualquer região do Azure, e a resolução de nomes funciona normalmente para recursos nessas VNets, desde que a vinculação esteja configurada.
Esse comportamento é frequentemente subestimado: a resolução DNS não depende de proximidade geográfica entre a zona e a VNet vinculada. Isso simplifica arquiteturas multi-região que precisam de um namespace DNS interno unificado.
Gabarito — Questão 4
Resposta: B
A delegação de subdomínio no DNS funciona por meio de registros NS (Name Server), que indicam quais servidores são autoritativos para aquela zona filha. Criar um registro A apontando para IPs de nameservers é tecnicamente incorreto: além de misturar o propósito dos tipos de registro, os nameservers do Azure DNS não têm IPs fixos e estáveis para uso em registros A.
O processo correto é: obter os quatro hostnames NS da zona api.contoso.com e criar um registro NS com o nome api na zona contoso.com, listando esses hostnames como valores. Isso instrui os resolvedores recursivos a consultar os nameservers da zona filha quando receberem perguntas sobre *.api.contoso.com.
As alternativas A e C são falsas: não há restrição de assinatura para delegação, e nameservers do Azure DNS são perfeitamente válidos nesse contexto.
Gabarito — Questão 5
Resposta: A
Quando o auto-registro está habilitado em uma VNet link, as VMs dessa VNet têm seus registros criados automaticamente na zona privada. Como a zona app.interno está vinculada tanto à VNet-A quanto à VNet-B, ambas as VNets compartilham o mesmo espaço de nomes DNS privado.
Isso significa que vm-web-01.app.interno será visível e resolvível por qualquer VM de qualquer VNet vinculada à mesma zona, independentemente da região. Esse é exatamente o propósito de vincular múltiplas VNets a uma única zona privada: criar um namespace compartilhado.
A alternativa B representa um equívoco comum de confundir o escopo de peering de VNet (necessário para tráfego de dados) com o escopo de resolução DNS via zona privada compartilhada, que independe de peering. A alternativa C é falsa: o limite real é de até 100 VNets com auto-registro por zona, não uma VNet exclusiva.