Laboratório Técnico: Design name resolution inside a VNet
Questões
Questão 1 — Múltipla Escolha
Uma equipe de plataforma criou uma VNet chamada vnet-prod na região East US. Nenhuma configuração de DNS foi alterada após a criação. Uma VM nessa VNet precisa resolver o nome de outra VM na mesma VNet usando o FQDN no formato vm-backend.internal.cloudapp.net.
Qual afirmação descreve corretamente o comportamento do Azure nesse cenário?
A) A resolução falha porque FQDNs só funcionam com zonas DNS privadas configuradas explicitamente.
B) A resolução funciona automaticamente porque o Azure DNS interno resolve nomes no formato <vm-name>.internal.cloudapp.net para VMs na mesma VNet.
C) A resolução funciona, mas exige que a VM esteja registrada manualmente no serviço de DNS do Azure.
D) A resolução falha porque o Azure DNS interno só resolve nomes curtos (hostnames), não FQDNs.
Questão 2 — Cenário Técnico
Uma arquiteta está projetando a resolução de nomes para um ambiente híbrido. As VMs em vnet-hub precisam resolver nomes de hosts locais (on-premises), enquanto os hosts locais precisam resolver nomes de VMs no Azure. Ela planeja usar uma zona DNS privada do Azure vinculada à vnet-hub.
O ambiente on-premises usa servidores DNS próprios. Após a implementação, as VMs no Azure conseguem resolver nomes locais, mas os hosts on-premises não conseguem resolver os nomes das VMs no Azure.
Qual é a causa mais provável desse comportamento assimétrico?
A) A zona DNS privada do Azure não permite registros do tipo A criados automaticamente para VMs.
B) Os servidores DNS on-premises não conseguem consultar diretamente o endereço 168.63.129.16, que é o resolvedor do Azure e só é acessível de dentro da VNet.
C) A zona DNS privada não foi vinculada com a opção de registro automático habilitada, impedindo a resolução bidirecional.
D) O Azure bloqueia consultas DNS originadas fora da VNet por padrão via NSG, exigindo uma regra de entrada explícita na porta 53.
Questão 3 — Verdadeiro ou Falso
Uma zona DNS privada do Azure vinculada a uma VNet com registro automático habilitado registra automaticamente os FQDNs de todas as VMs da VNet, incluindo aquelas criadas antes do vínculo ser estabelecido.
Questão 4 — Cenário Técnico
Um engenheiro configura o seguinte cenário:
- VNet:
vnet-app(10.1.0.0/16) - Zona DNS privada:
app.internal - Vínculo criado entre a zona e a
vnet-appcom registro automático desabilitado - DNS customizado da VNet apontado para
10.1.0.4(uma VM com Bind9)
Após a configuração, as VMs em vnet-app não conseguem resolver registros criados manualmente na zona app.internal.
nslookup svc-api.app.internal
Server: 10.1.0.4
Address: 10.1.0.4#53
** server can't find svc-api.app.internal: NXDOMAIN
Qual é a causa mais provável da falha?
A) O registro automático desabilitado impede a criação de qualquer registro na zona privada.
B) O servidor DNS customizado (10.1.0.4) não está configurado para encaminhar consultas da zona app.internal ao resolvedor do Azure (168.63.129.16).
C) A zona app.internal não pode ser resolvida dentro da VNet porque o sufixo .internal é reservado pelo Azure.
D) O vínculo entre a zona e a VNet precisa ser recriado com registro automático habilitado para que qualquer resolução funcione.
Questão 5 — Múltipla Escolha
Duas VNets estão em regiões diferentes: vnet-eastus e vnet-westus. Elas estão conectadas via VNet Peering global. Uma zona DNS privada chamada corp.internal está vinculada apenas à vnet-eastus com registro automático habilitado.
O que acontece quando uma VM em vnet-westus tenta resolver um nome registrado em corp.internal?
A) A resolução funciona automaticamente porque o VNet Peering propaga os vínculos de DNS privado entre VNets pareadas.
B) A resolução falha porque a zona corp.internal não está vinculada à vnet-westus, e o VNet Peering não estende vínculos de zona DNS privada.
C) A resolução funciona apenas para registros do tipo A, mas falha para registros CNAME na zona privada.
D) A resolução falha porque zonas DNS privadas não suportam VNets em regiões diferentes.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Azure fornece resolução de nomes interna automaticamente para VMs dentro da mesma VNet, sem qualquer configuração adicional. Os nomes no formato <vm-name>.internal.cloudapp.net são resolvidos pelo DNS interno do Azure usando o endereço especial 168.63.129.16.
O principal equívoco representado pelos distratores é confundir o DNS interno automático do Azure com zonas DNS privadas, que são um recurso separado e configurável. O DNS interno já funciona por padrão para resolução entre VMs na mesma VNet. A alternativa D inverte a realidade: o DNS interno resolve tanto hostnames curtos quanto FQDNs no formato internal.cloudapp.net.
Gabarito — Questão 2
Resposta: B
O endereço 168.63.129.16 é o resolvedor DNS do Azure e é acessível apenas a partir de dentro de uma VNet do Azure. Servidores DNS on-premises não conseguem alcançar esse endereço diretamente pela internet ou por conexões híbridas, o que torna a resolução unidirecional.
Para habilitar a resolução bidirecional, a arquitetura correta exige um DNS forwarder (geralmente uma VM no Azure ou o recurso Azure DNS Private Resolver) que atue como intermediário: os servidores on-premises enviam as consultas da zona privada para esse forwarder, que por sua vez consulta o 168.63.129.16 e retorna a resposta.
A alternativa C é um equívoco comum: o registro automático afeta apenas se as VMs são registradas automaticamente na zona, não a capacidade de resolução em si. A alternativa D confunde NSG com controle de acesso ao plano de DNS, que opera em uma camada diferente.
Gabarito — Questão 3
Resposta: Verdadeiro
Quando um vínculo com registro automático é criado entre uma zona DNS privada e uma VNet, o Azure registra automaticamente os registros DNS de todas as VMs da VNet, incluindo aquelas que já existiam antes do vínculo ser estabelecido. O Azure percorre as interfaces de rede existentes na VNet e cria os registros correspondentes na zona privada.
Esse comportamento é relevante em cenários de migração: habilitar o registro automático em uma VNet com VMs existentes não exige que as VMs sejam recriadas ou reiniciadas para que seus nomes apareçam na zona.
Gabarito — Questão 4
Resposta: B
Quando a VNet é configurada com um DNS customizado, as VMs usam esse servidor para todas as consultas. O servidor Bind9 em 10.1.0.4 recebe a consulta de svc-api.app.internal, mas como não está configurado com um conditional forwarder para a zona app.internal apontando para 168.63.129.16, ele tenta resolver por conta própria e retorna NXDOMAIN.
O registro automático desabilitado (alternativa A) afeta apenas a criação automática de registros de VMs, mas registros criados manualmente continuam existindo e sendo resolvidos normalmente via 168.63.129.16. A alternativa D é incorreta porque o vínculo entre zona e VNet é o que permite a resolução via resolvedor do Azure, independentemente do registro automático.
Gabarito — Questão 5
Resposta: B
O VNet Peering, mesmo o global entre regiões, não propaga vínculos de zona DNS privada. Cada VNet precisa ser vinculada individualmente à zona DNS privada para que suas VMs possam usar o resolvedor do Azure (168.63.129.16) e consultar os registros dessa zona.
A alternativa A representa o equívoco mais comum: assumir que o peering cria uma extensão completa da configuração de rede, incluindo DNS. Na prática, DNS e peering são recursos independentes. A alternativa D é incorreta porque zonas DNS privadas suportam vínculos com VNets em qualquer região, inclusive regiões distintas; o problema nesse cenário é a ausência do vínculo, não uma limitação geográfica.