Laboratório Técnico: Configure Azure DNS
Questões
Questão 1 — Múltipla Escolha
Uma equipe de plataforma precisa hospedar a zona DNS pública contoso.com no Azure DNS. Após criar a zona e configurar os registros necessários, os usuários externos relatam que nomes dentro do domínio não estão sendo resolvidos. A equipe verifica que os registros existem na zona do Azure DNS e que o domínio está registrado no registrador externo.
Qual é a causa mais provável do problema?
A) A zona DNS pública do Azure requer que a assinatura tenha o recurso "DNS Resolver" habilitado antes de aceitar consultas externas.
B) Os servidores de nomes (NS) da zona criada no Azure DNS não foram configurados no registrador externo do domínio.
C) O TTL dos registros A está alto demais, impedindo que o cache dos resolvers externos seja atualizado.
D) O Azure DNS público não aceita consultas de resolvers fora da rede do Azure sem uma regra de DNS Forwarding.
Questão 2 — Cenário Técnico
Um administrador precisa que recursos dentro de uma VNet resolvam automaticamente o nome vm-backend.internal.contoso.com para o IP privado de uma VM, sem precisar gerenciar manualmente registros DNS. Ele cria uma zona DNS privada chamada internal.contoso.com e vincula a VNet a ela.
Após a configuração, a VM que origina as consultas não consegue resolver o nome. O administrador verifica que o registro A já existe na zona privada. Considere a configuração abaixo:
Zona privada: internal.contoso.com
VNet link: vnet-prod
- Auto-registration: Disabled
- Resolution: Enabled
Qual é o problema?
A) O link de VNet está com auto-registration desabilitado, o que impede qualquer resolução de nomes da zona privada nessa VNet.
B) O link de VNet com resolution habilitado é suficiente para resolver nomes na zona privada, portanto o problema está em outro lugar.
C) A zona DNS privada precisa estar na mesma região da VNet para que o link funcione corretamente.
D) O registro A foi criado manualmente, mas como auto-registration está desabilitado, registros manuais são ignorados pela zona privada.
Questão 3 — Verdadeiro ou Falso
Uma zona DNS privada do Azure pode ser vinculada a VNets em assinaturas diferentes, desde que o administrador que realiza o link tenha permissões adequadas nas duas assinaturas.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma empresa possui a seguinte estrutura de registros DNS em uma zona pública hospedada no Azure DNS:
blog CNAME contoso.wordpress.com
@ A 20.10.50.100
www CNAME contoso.azurewebsites.net
O time de infraestrutura tenta criar o seguinte registro adicional:
@ CNAME contoso.trafficmanager.net
A operação falha. Qual é a explicação técnica correta?
A) O Azure DNS não suporta registros CNAME em zonas públicas; esse tipo de registro é exclusivo de zonas privadas.
B) Não é possível criar um registro CNAME para o apex da zona (@) porque o apex já contém registros NS e SOA, e um CNAME não pode coexistir com outros registros no mesmo nome.
C) O problema é que já existe um registro A para @; basta remover o registro A para que o CNAME seja aceito.
D) O Traffic Manager não pode ser alvo de um CNAME em zonas hospedadas no Azure DNS; é necessário usar um registro A apontando para o IP do perfil.
Questão 5 — Múltipla Escolha
Um administrador precisa delegar a subzona dev.contoso.com para uma equipe que gerenciará seus próprios registros DNS em uma zona separada do Azure DNS. Qual conjunto de ações representa corretamente o processo de delegação?
A) Criar uma zona chamada dev.contoso.com e adicionar um registro A na zona pai contoso.com apontando para o IP do servidor DNS da zona filha.
B) Criar uma zona chamada dev.contoso.com, copiar os servidores de nomes atribuídos a ela e criar registros NS na zona pai contoso.com apontando para esses servidores.
C) Criar uma zona chamada dev.contoso.com e adicionar um registro CNAME na zona pai contoso.com com o nome dev apontando para o FQDN da zona filha.
D) Criar uma zona chamada dev.contoso.com e habilitar a opção de delegação automática nas configurações da zona pai no portal do Azure.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Quando uma zona DNS pública é criada no Azure DNS, a plataforma atribui automaticamente um conjunto de servidores de nomes (NS) exclusivos para aquela zona. Para que resolvers externos consigam encontrar e consultar essa zona, o registrador do domínio precisa ser atualizado para apontar para esses servidores de nomes do Azure. Sem essa atualização no registrador, a cadeia de resolução hierárquica nunca chega à zona do Azure, independentemente de os registros internos estarem corretos.
O principal equívoco representado pelos distratores é deslocar a causa para aspectos de conectividade ou configuração interna do Azure, quando o problema é externo: a delegação no registrador. O TTL alto (C) causaria lentidão na propagação de mudanças, não falha total na resolução de um domínio recém-configurado. As opções A e D descrevem restrições que não existem no Azure DNS público.
Gabarito — Questão 2
Resposta: B
O link de VNet com resolution habilitado é, de fato, suficiente para que VMs nessa VNet resolvam nomes de uma zona DNS privada, incluindo registros criados manualmente. O auto-registration controla apenas o registro automático de VMs da VNet na zona privada, não a capacidade de resolução.
O erro conceitual central da questão é confundir as duas funções do link de VNet: resolução e registro automático são independentes. A alternativa A representa esse equívoco diretamente, sugerindo que desabilitar o auto-registration bloqueia a resolução, o que é incorreto. A alternativa D inverte completamente a lógica do auto-registration. Como a configuração mostrada está correta para resolução, o problema está em outro lugar (por exemplo, o registro A pode ter o nome ou o IP incorreto, ou pode haver um problema de conectividade com o servidor de aplicação).
Gabarito — Questão 3
Resposta: Verdadeiro
O Azure DNS permite que uma zona DNS privada seja vinculada a VNets em assinaturas diferentes dentro do mesmo tenant do Microsoft Entra ID. O requisito é que o administrador que realiza a operação de link tenha as permissões necessárias tanto na assinatura que contém a zona quanto na assinatura que contém a VNet. Esse comportamento é relevante em arquiteturas hub-and-spoke onde a zona privada fica centralizada em uma assinatura de conectividade e as VNets estão em assinaturas de workload separadas.
O ponto não óbvio aqui é que o escopo de uma zona DNS privada não é limitado pela assinatura onde ela reside; o controle de acesso é resolvido por permissões RBAC, não por fronteiras de assinatura.
Gabarito — Questão 4
Resposta: B
O apex da zona (representado por @) é o próprio nome da zona, como contoso.com. Por definição do protocolo DNS (RFC 1034/1035), um registro CNAME não pode coexistir com nenhum outro tipo de registro no mesmo nome. O apex sempre contém ao menos os registros NS e SOA, o que torna impossível criar um CNAME para ele em qualquer implementação DNS padrão.
O Azure DNS oferece o recurso de alias record (registro de alias) como solução para esse cenário: ele permite apontar o apex da zona para um recurso do Azure como Traffic Manager, Azure CDN ou endereço IP público, contornando a limitação do CNAME sem violar o padrão DNS.
A alternativa C é o distrator mais perigoso: mesmo que o registro A fosse removido, os registros NS e SOA permaneceriam no apex, mantendo a incompatibilidade com CNAME. A alternativa D é factualmente incorreta; o Traffic Manager pode sim ser alvo de um CNAME em nomes não-apex.
Gabarito — Questão 5
Resposta: B
A delegação de subdomínio em DNS funciona por meio de registros NS na zona pai que apontam para os servidores de nomes autoritativos da zona filha. No Azure DNS, ao criar a zona dev.contoso.com, a plataforma atribui um conjunto de servidores de nomes a ela. Esses servidores precisam ser registrados como registros NS sob o nome dev na zona pai contoso.com. Quando um resolver consulta alguma-coisa.dev.contoso.com, ele encontra os registros NS em contoso.com e é redirecionado para os servidores da zona filha.
A alternativa A confunde delegação com apontamento direto via registro A, o que não realiza delegação e não é como o DNS hierárquico funciona. A alternativa C é inválida porque um CNAME para um nome de zona não tem semântica de delegação no DNS. A alternativa D descreve uma funcionalidade que não existe no Azure DNS; não há delegação automática entre zonas pelo portal.