Laboratório Técnico: Design Public DNS Zones
Questões
Questão 1 — Múltipla Escolha
Uma equipe de infraestrutura precisa que o domínio api.contoso.com resolva para dois endereços IP diferentes com balanceamento por round-robin simples no DNS público do Azure. A zona pública contoso.com já está criada no Azure DNS.
Qual combinação de configuração atende a esse requisito?
A) Criar um registro A com o nome api e TTL alto, apontando para um Azure Traffic Manager profile com método de roteamento Performance.
B) Criar dois registros A com o mesmo nome api e TTLs distintos, cada um apontando para um IP diferente.
C) Criar dois registros A com o mesmo nome api, o mesmo TTL e IPs diferentes, formando um record set com múltiplos valores.
D) Criar um registro CNAME com o nome api apontando para um registro A externo que contenha os dois IPs.
Questão 2 — Cenário Técnico
Uma empresa adquiriu o domínio fabrikam.net em um registrador externo e criou uma zona DNS pública no Azure DNS para esse domínio. Após delegar a zona corretamente para os name servers do Azure, os registros internos estão funcionando, mas um registro TXT criado para validação de domínio no Microsoft 365 não está sendo resolvido externamente.
O time verifica o registro no portal e ele existe. Qual é a causa mais provável?
A) O registro TXT não é suportado em zonas públicas do Azure DNS; ele deveria ser criado como registro SPF nativo.
B) O TTL do registro TXT está definido como 3600 segundos, causando cache excessivo nos resolvedores externos.
C) A delegação foi feita apontando apenas um dos quatro name servers fornecidos pelo Azure DNS, e os outros três não estão sendo usados.
D) O nome do registro TXT foi criado com um ponto final explícito, tornando-o absoluto e não relativo à zona.
Questão 3 — Verdadeiro ou Falso
No Azure DNS, uma zona DNS pública pode conter um registro CNAME no apex da zona (ou seja, com o nome @), desde que não coexista com outros registros do tipo A ou AAAA no mesmo nível.
Questão 4 — Cenário Técnico
Um arquiteto precisa hospedar as zonas DNS públicas de três clientes distintos, cada um com seu próprio domínio, dentro de uma única assinatura do Azure. Ele pretende usar um único Resource Group para centralizar a gestão.
Durante o planejamento, ele observa o seguinte comportamento ao tentar criar as zonas:
Zona 1: cliente-a.com -> criada com sucesso
Zona 2: cliente-b.com -> criada com sucesso
Zona 3: cliente-a.com -> ERRO ao criar no mesmo Resource Group
Qual afirmação explica corretamente o comportamento observado?
A) O Azure DNS não permite hospedar zonas de clientes diferentes na mesma assinatura por questões de isolamento de namespace.
B) Não é possível criar duas zonas com o mesmo nome dentro do mesmo Resource Group, mas é possível criar em Resource Groups distintos dentro da mesma assinatura.
C) O erro ocorre porque a zona cliente-a.com já existe globalmente no Azure DNS, e nomes de zona são únicos em nível global.
D) O Azure DNS exige que cada zona de cliente seja criada em uma assinatura separada para evitar conflito de name servers.
Questão 5 — Múltipla Escolha
Uma organização usa o Azure DNS para hospedar a zona pública contoso.com. O time de segurança exige que o tráfego de e-mail seja entregue com preferência para o servidor mail1.contoso.com e, apenas em caso de falha, para mail2.contoso.com.
Qual configuração de registros MX implementa esse requisito corretamente?
A) Criar dois registros MX: mail1.contoso.com com prioridade 10 e mail2.contoso.com com prioridade 20.
B) Criar dois registros MX: mail1.contoso.com com prioridade 20 e mail2.contoso.com com prioridade 10.
C) Criar um registro MX apontando para mail1.contoso.com com prioridade 1 e um registro A para mail2.contoso.com como fallback.
D) Criar dois registros MX com a mesma prioridade e depender do TTL para definir a preferência de entrega.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: C
No Azure DNS, um record set é a unidade de gerenciamento para registros do mesmo nome e tipo. Para implementar round-robin DNS, cria-se um único record set do tipo A com o nome api, mesmo TTL e múltiplos valores de IP. O resolver retorna todos os IPs e os clientes alternam entre eles.
A alternativa B é um distrator comum: registros com TTLs distintos sob o mesmo nome não são permitidos no Azure DNS; o TTL é uma propriedade do record set, não do registro individual. A alternativa A introduz Traffic Manager, que resolve um problema diferente (roteamento inteligente, não round-robin simples). A alternativa D é inválida porque um CNAME não pode apontar para um registro A com múltiplos IPs de forma equivalente, e CNAMEs têm restrições no apex.
Gabarito — Questão 2
Resposta: C
O Azure DNS fornece exatamente quatro name servers para cada zona pública. A delegação correta exige que todos os quatro sejam configurados no registrador externo. Quando apenas um é delegado, a resolução pode funcionar intermitentemente (quando o resolver acerta aquele server) ou falhar quando tenta os outros três, que não estão autorizados para a zona segundo o registrador. Isso explica o comportamento inconsistente: registros funcionam em alguns contextos e falham em outros.
A alternativa A é falsa: o tipo TXT é plenamente suportado em zonas públicas do Azure DNS. A alternativa B (TTL de 3600) descreve comportamento normal e esperado, não uma falha. A alternativa D descreve um equívoco real sobre nomes absolutos versus relativos, mas o portal do Azure lida com isso automaticamente ao criar registros.
Gabarito — Questão 3
Resposta: Falso
O Azure DNS não suporta registros CNAME no apex da zona (o nome @), independentemente de coexistência com outros tipos. Essa é uma restrição do protocolo DNS (RFC 1034), não uma limitação específica do Azure: um CNAME no apex conflitaria com os registros SOA e NS obrigatórios. A afirmação induz ao erro ao sugerir que a restrição seria sobre coexistência com A/AAAA; na realidade, a proibição é absoluta para o apex. Para cobrir o apex com um nome canônico, o Azure DNS suporta registros alias (ALIAS records) apontando para recursos como Traffic Manager ou Front Door, que resolvem esse cenário sem violar o RFC.
Gabarito — Questão 4
Resposta: B
No Azure DNS, o nome da zona é único dentro de um Resource Group, mas não dentro da assinatura como um todo. É perfeitamente válido criar a mesma zona em Resource Groups diferentes dentro da mesma assinatura. Isso é um padrão usado para multi-tenant ou ambientes de teste e produção segregados. Cada instância da zona receberá um conjunto distinto de name servers do Azure, o que exige atenção na delegação.
A alternativa C representa um equívoco frequente: nomes de zona DNS pública não são globalmente únicos no Azure; a unicidade é escopada ao Resource Group. As alternativas A e D descrevem restrições que não existem na plataforma.
Gabarito — Questão 5
Resposta: A
Em registros MX, a prioridade mais baixa indica preferência maior. Portanto, mail1.contoso.com com prioridade 10 será tentado primeiro, e mail2.contoso.com com prioridade 20 atuará como fallback. A alternativa B inverte essa lógica, entregando a preferência ao servidor errado. A alternativa C é inválida tecnicamente: um registro A não funciona como fallback MX; apenas registros MX são consultados para entrega de e-mail. A alternativa D descreve round-robin, não priorização: prioridades iguais fazem os servidores de e-mail alternarem entre os destinos sem preferência definida.