Laboratório Técnico: Configure DNS settings for a VNet
Questões
Questão 1 — Múltipla Escolha
Uma equipe de infraestrutura configurou uma VNet no Azure com o servidor DNS padrão (Azure-provided DNS). Após implantar uma zona DNS privada chamada internal.contoso.com e vinculá-la à VNet, as VMs da rede continuam resolvendo nomes pela zona pública, ignorando a zona privada.
Qual é a causa mais provável desse comportamento?
A) A zona DNS privada precisa ser criada na mesma região da VNet para funcionar corretamente.
B) O link de rede virtual foi criado sem habilitar o registro automático, e os registros precisam ser adicionados manualmente.
C) O link de rede virtual foi criado, mas o autoregistro ou a resolução via zona privada só funciona quando o DNS da VNet aponta para um resolvedor customizado, não para o DNS padrão do Azure.
D) A zona DNS privada internal.contoso.com conflita com o sufixo DNS padrão da VNet e o Azure ignora zonas privadas com domínios customizados.
Questão 2 — Cenário Técnico
Um arquiteto precisa que VMs em duas VNets diferentes, em regiões distintas, resolvam nomes de uma mesma zona DNS privada (shared.internal). Ele aplica a seguinte configuração:
Zona DNS privada: shared.internal
Link VNet-A: habilitado, autoregistro: desativado
Link VNet-B: habilitado, autoregistro: desativado
VMs na VNet-A resolvem nomes da zona corretamente. VMs na VNet-B não conseguem resolver.
Qual é a causa mais provável?
A) Zonas DNS privadas não suportam links com mais de uma VNet simultaneamente.
B) O autoregistro precisa estar habilitado em todos os links para que a resolução funcione em VNets secundárias.
C) O link da VNet-B foi criado, mas o DNS da VNet-B ainda aponta para o DNS padrão do Azure, que não encaminha consultas para zonas privadas vinculadas a outras VNets.
D) O DNS da VNet-B não está configurado para usar os servidores de resolução recursiva do Azure (168.63.129.16), necessários para consultar zonas DNS privadas.
Questão 3 — Verdadeiro ou Falso
Uma zona DNS privada do Azure pode ser vinculada a até 1.000 VNets para resolução de nomes, mas o autoregistro só pode ser habilitado em no máximo 1 VNet por zona.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma empresa utiliza servidores DNS on-premises para resolver nomes internos (corp.local) e precisa que VMs no Azure também resolvam esses nomes. A equipe configura os servidores DNS customizados da VNet com os IPs dos servidores on-premises:
VNet DNS Servers:
- 10.0.0.4 (DNS on-premises primário)
- 10.0.0.5 (DNS on-premises secundário)
Após a configuração, as VMs no Azure resolvem corp.local corretamente, mas passam a falhar na resolução de nomes de serviços do Azure como storageaccount.blob.core.windows.net.
Qual é a correção mais adequada?
A) Adicionar 168.63.129.16 como servidor DNS terciário na configuração da VNet, pois o Azure o consulta automaticamente como fallback.
B) Configurar os servidores DNS on-premises para encaminhar consultas de *.core.windows.net para 168.63.129.16, e manter os servidores customizados na VNet.
C) Remover os servidores DNS customizados da VNet e usar somente o DNS padrão do Azure, criando uma zona DNS privada para corp.local.
D) Adicionar entradas A estáticas para cada endpoint de serviço Azure na zona DNS on-premises.
Questão 5 — Múltipla Escolha
Um administrador precisa que VMs em uma VNet resolvam automaticamente seus próprios hostnames via uma zona DNS privada, sem criar registros manualmente. Ele cria a zona vms.internal, vincula à VNet e habilita o autoregistro.
Qual afirmação descreve corretamente o comportamento resultante?
A) O Azure cria registros A para todas as VMs da VNet imediatamente após o link ser criado, incluindo VMs já existentes sem IP dinâmico.
B) O Azure cria e remove automaticamente registros A na zona conforme VMs são provisionadas e desprovisionadas, usando o hostname configurado na NIC.
C) O autoregistro cria registros A e PTR para todas as VMs, mas registros PTR exigem uma zona de pesquisa reversa separada vinculada à mesma VNet.
D) O autoregistro só funciona para VMs criadas após o link ser habilitado; VMs preexistentes precisam ser reiniciadas para ter seus registros criados.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O vínculo de rede virtual com uma zona DNS privada não implica, por si só, que os registros das VMs serão adicionados automaticamente. O autoregistro é uma funcionalidade separada que, quando habilitada no link, faz com que o Azure registre dinamicamente os hostnames das VMs na zona privada. Sem ele, a zona pode até resolver nomes adicionados manualmente, mas as VMs não terão entradas criadas automaticamente.
A alternativa C representa um equívoco comum: o DNS padrão do Azure (resolvido via 168.63.129.16) é totalmente capaz de consultar zonas privadas vinculadas à VNet, sem necessidade de resolvedor customizado. A alternativa D é tecnicamente falsa: zonas privadas com domínios customizados como internal.contoso.com funcionam normalmente e não conflitam com sufixos internos do Azure.
Gabarito — Questão 2
Resposta: D
Para que VMs em uma VNet consultem zonas DNS privadas, o servidor DNS efetivo da VNet precisa ser o resolvedor recursivo do Azure, acessível via 168.63.129.16. Esse resolvedor conhece todos os links de zona privada associados à VNet. Se a VNet-B tiver um servidor DNS customizado que não encaminha para 168.63.129.16, as consultas nunca chegam ao plano de resolução do Azure, e a zona privada vinculada é ignorada.
A alternativa A é falsa: uma zona privada suporta vínculos com centenas de VNets. A alternativa B é falsa: o autoregistro controla apenas a criação automática de registros, não a capacidade de resolução. A alternativa C descreve um cenário válido de problema, mas tecnicamente incompleto: o DNS padrão do Azure já usa 168.63.129.16 internamente, tornando D a causa raiz mais precisa e direta.
Gabarito — Questão 3
Resposta: Verdadeiro
O Azure suporta até 1.000 links de VNet por zona DNS privada para fins de resolução de nomes. No entanto, o autoregistro é uma funcionalidade restrita: apenas 1 VNet por zona pode ter o autoregistro habilitado. Isso ocorre porque o autoregistro implica que a zona é a fonte autoritativa para os hostnames daquela VNet, e permitir múltiplas VNets com autoregistro na mesma zona geraria conflitos de registro.
Esse limite é frequentemente subestimado por arquitetos que tentam centralizar o registro de múltiplas VNets em uma única zona privada e descobrem que apenas uma delas pode usar autoregistro.
Gabarito — Questão 4
Resposta: B
Quando a VNet usa servidores DNS customizados (on-premises, neste caso), todo o tráfego de resolução DNS das VMs é direcionado exclusivamente a eles. Os servidores on-premises, por padrão, não sabem resolver nomes públicos de serviços do Azure como *.blob.core.windows.net, pois não têm visibilidade do resolvedor do Azure (168.63.129.16).
A solução correta é configurar os servidores DNS on-premises para encaminhar (forward) consultas de domínios Azure para 168.63.129.16. Isso preserva a resolução de corp.local nos servidores internos e delega a resolução de serviços Azure ao resolvedor nativo do Azure.
A alternativa A é incorreta: adicionar 168.63.129.16 como terciário na VNet não funciona como fallback automático quando servidores primários estão acessíveis mas retornam NXDOMAIN. A alternativa C elimina a resolução de corp.local que é um requisito do negócio. A alternativa D é operacionalmente inviável e não escala.
Gabarito — Questão 5
Resposta: B
O autoregistro em zonas DNS privadas do Azure funciona como um ciclo de vida vinculado ao provisionamento de VMs: registros A são criados quando a VM é iniciada ou tem sua NIC configurada, e removidos quando a VM é excluída ou a NIC é desassociada. O hostname usado é o nome configurado na interface de rede (NIC) da VM.
A alternativa A é falsa em dois pontos: o autoregistro não cria registros para VMs com IPs estáticos sem reinicialização, e não age "imediatamente" de forma retroativa para todas as VMs existentes sem qualquer evento de ciclo de vida. A alternativa C é falsa: o Azure não cria registros PTR automaticamente via autoregistro em zonas privadas, isso exige configuração explícita em zonas de pesquisa reversa. A alternativa D é uma meia-verdade usada como distrator: VMs preexistentes podem ter seus registros criados sem necessariamente reiniciar, bastando que ocorra um evento de atualização de IP na NIC.