Laboratório Técnico: Design and Implement Azure DNS Private Resolver
Questões
Questão 1 — Múltipla Escolha
Uma equipe de rede precisa resolver nomes de zonas DNS privadas do Azure a partir de servidores on-premises conectados via ExpressRoute. A solução deve evitar a exposição de endereços IP públicos e não exigir máquinas virtuais dedicadas para atuar como forwarders.
Qual componente do Azure DNS Private Resolver atende diretamente a esse requisito?
A) Um endpoint de saída (outbound endpoint) configurado com regras de encaminhamento para as zonas privadas do Azure
B) Um endpoint de entrada (inbound endpoint) que recebe consultas DNS originadas fora da rede virtual e as resolve no contexto do Azure
C) Uma zona DNS privada vinculada à rede virtual do ExpressRoute Gateway com registro automático habilitado
D) Um servidor DNS personalizado definido nas configurações da rede virtual, apontando para o endereço 168.63.129.16
Questão 2 — Cenário Técnico
Um arquiteto configurou o Azure DNS Private Resolver com a seguinte topologia:
- VNet Hub com um inbound endpoint (IP:
10.0.0.4) e um outbound endpoint - VNet Spoke vinculada à mesma zona DNS privada
- Ruleset de encaminhamento associado ao outbound endpoint com uma regra para
contoso.internalapontando para192.168.1.10(servidor DNS on-premises)
Ao testar a resolução do nome app.contoso.internal a partir de uma VM na VNet Spoke, a consulta falha. A VM na VNet Hub resolve o mesmo nome sem problemas.
Qual é a causa mais provável da falha?
A) O outbound endpoint não pode encaminhar consultas de VNets diferentes da VNet onde está provisionado
B) O ruleset de encaminhamento não foi associado à VNet Spoke, portanto as VMs nessa rede não são afetadas pelas regras de encaminhamento
C) A zona DNS privada contoso.internal precisa estar vinculada à VNet Spoke para que o encaminhamento funcione corretamente
D) O endereço IP do servidor DNS on-premises (192.168.1.10) deve ser configurado diretamente nas propriedades de DNS da VNet Spoke
Questão 3 — Verdadeiro ou Falso
Um outbound endpoint do Azure DNS Private Resolver pode encaminhar consultas DNS para destinos externos mesmo que não exista nenhum DNS Forwarding Ruleset associado a ele.
Questão 4 — Cenário Técnico
Uma organização opera múltiplas VNets em regiões diferentes, todas conectadas a uma VNet Hub via peering. A equipe deseja centralizar a resolução DNS usando um único Azure DNS Private Resolver provisionado na VNet Hub, de modo que VMs em todas as VNets spoke resolvam zonas DNS privadas do Azure e encaminhem consultas para DNS on-premises.
A configuração atual está descrita abaixo:
VNet Hub
└── DNS Private Resolver
├── Inbound Endpoint: 10.1.0.4
└── Outbound Endpoint → Ruleset "corp-rules"
└── Regra: corp.local → 10.0.100.5
VNet Spoke A (peering com Hub)
└── DNS Server: 10.1.0.4 (inbound endpoint do Hub)
VNet Spoke B (peering com Hub)
└── DNS Server: padrão do Azure
VMs na VNet Spoke A resolvem corp.local corretamente. VMs na VNet Spoke B não resolvem nem zonas privadas do Azure nem corp.local.
O que deve ser corrigido para que a VNet Spoke B funcione como esperado?
A) Associar o ruleset corp-rules à VNet Spoke B e configurar seu servidor DNS para apontar para 10.1.0.4
B) Provisionar um segundo DNS Private Resolver exclusivo na VNet Spoke B com os mesmos rulesets
C) Vincular as zonas DNS privadas do Azure à VNet Spoke B e configurar seu servidor DNS para 168.63.129.16
D) Criar um inbound endpoint adicional dentro da VNet Spoke B e associar o ruleset corp-rules a esse endpoint
Questão 5 — Múltipla Escolha
Ao provisionar um inbound endpoint do Azure DNS Private Resolver, qual é o comportamento esperado em relação ao endereço IP atribuído a ele?
A) O endereço IP é dinâmico e pode mudar a cada reinicialização do resolver, exigindo atualização periódica nos forwarders on-premises
B) O endereço IP é estático durante o ciclo de vida do endpoint e é alocado a partir do espaço de endereçamento da subnet dedicada ao inbound endpoint
C) O endereço IP é sempre atribuído a partir do intervalo de link-local (169.254.0.0/16) e não é roteável externamente
D) O endereço IP do inbound endpoint é compartilhado com o outbound endpoint quando ambos estão na mesma VNet, para reduzir o consumo de endereços
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O inbound endpoint é o componente projetado exatamente para receber consultas DNS originadas fora da rede virtual do Azure, como servidores on-premises conectados via ExpressRoute ou VPN. Ele expõe um endereço IP privado roteável pela rede híbrida e resolve as consultas no contexto do Azure, incluindo zonas DNS privadas vinculadas à VNet.
A alternativa A inverte o papel dos componentes: o outbound endpoint serve para encaminhar consultas do Azure para destinos externos, não para receber consultas de fora. A alternativa C não resolve o problema porque o endereço 168.63.129.16 não é acessível a partir de redes on-premises. A alternativa D aborda peering de zonas, mas não cria um ponto de entrada acessível externamente sem VMs intermediárias.
Gabarito — Questão 2
Resposta: B
O DNS Forwarding Ruleset deve ser explicitamente associado a cada VNet que precisa aplicar as regras de encaminhamento. A associação do ruleset ao outbound endpoint não é suficiente: VNets spoke que não tenham o ruleset associado a elas continuarão usando a resolução DNS padrão do Azure, sem aplicar nenhuma das regras definidas.
A alternativa A é incorreta porque o outbound endpoint pode servir VNets spoke, desde que o ruleset esteja associado a elas. A alternativa C confunde encaminhamento com resolução de zonas privadas: vincular a zona à VNet Spoke resolveria nomes dessa zona, mas não o encaminhamento para DNS on-premises. A alternativa D contorna a arquitetura do Private Resolver e introduz um ponto de falha sem relação com a causa real.
Gabarito — Questão 3
Resposta: Falso
O outbound endpoint, por si só, não encaminha nenhuma consulta. Ele é apenas a interface de saída da rede virtual. O encaminhamento efetivo depende de um DNS Forwarding Ruleset que contenha regras explícitas mapeando domínios para servidores DNS de destino. Sem um ruleset associado ao outbound endpoint, ele permanece inativo do ponto de vista funcional.
Esse é um equívoco comum: acreditar que o outbound endpoint tem comportamento de "forwarder genérico" por padrão. Na prática, ele só age quando um ruleset com regras válidas está vinculado a ele.
Gabarito — Questão 4
Resposta: A
O problema da VNet Spoke B tem duas dimensões independentes que precisam ser corrigidas juntas. Primeiro, o servidor DNS da VNet Spoke B deve apontar para o inbound endpoint (10.1.0.4) para que as consultas passem pelo DNS Private Resolver centralizado. Segundo, o ruleset corp-rules deve ser associado à VNet Spoke B para que as regras de encaminhamento para corp.local sejam aplicadas às VMs dessa VNet.
A alternativa B é ineficiente e desnecessária: o design hub-and-spoke permite centralizar o resolver. A alternativa C resolve parcialmente o problema de zonas privadas do Azure, mas não endereça o encaminhamento para corp.local. A alternativa D confunde inbound com outbound: inbound endpoints adicionais não distribuem rulesets.
Gabarito — Questão 5
Resposta: B
O endereço IP de um inbound endpoint é alocado de forma estática a partir do espaço de endereçamento da subnet dedicada configurada para ele no momento do provisionamento. Esse comportamento é fundamental para a arquitetura: servidores DNS on-premises precisam de um destino fixo e confiável para encaminhar consultas, e qualquer mudança de IP exigiria reconfiguração nos forwarders externos.
A alternativa A é falsa e representaria um risco operacional grave caso fosse verdadeira. A alternativa C descreve endereços link-local, que não se aplicam a esse contexto. A alternativa D é tecnicamente incoerente: inbound e outbound endpoints requerem subnets distintas e têm IPs independentes, justamente para separar o tráfego de entrada e saída.