Laboratório de Troubleshooting: Design Public DNS Zones
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe migrou a hospedagem do domínio contoso.com de um provedor DNS legado para o Azure DNS. A zona foi criada, todos os registros foram recriados manualmente no portal e a delegação foi atualizada no registrador com os quatro name servers fornecidos pelo Azure.
Três dias após a migração, o time de monitoramento abre um chamado relatando que usuários em determinadas regiões da Europa conseguem resolver www.contoso.com normalmente, enquanto usuários no Brasil e nos Estados Unidos recebem o endereço IP antigo do provedor anterior.
O engenheiro responsável verifica no portal do Azure e confirma que o registro A para www está correto e aponta para o novo IP. O TTL do registro no Azure está configurado como 300 segundos. A zona no provedor legado ainda existe, mas o time garante que as credenciais de acesso ao painel antigo foram revogadas há dois dias.
Qual é a causa raiz do comportamento observado?
A) O TTL de 300 segundos está muito baixo, causando resoluções inconsistentes entre servidores recursivos que ignoram valores abaixo de 600 segundos.
B) O registro A no Azure está correto, mas o provedor legado ainda é autoritativo para parte dos resolvedores porque o TTL do registro SOA anterior ainda não expirou nos caches dos resolvedores recursivos das regiões afetadas.
C) A zona no provedor legado ainda existe e, como o registrador mantém múltiplas entradas NS ativas simultaneamente, alguns resolvedores ainda consultam os name servers antigos que retornam o IP original.
D) O Microsoft Entra ID não completou a propagação das permissões de DNS após a revogação das credenciais do provedor legado, bloqueando a resolução nas regiões afetadas.
Cenário 2 — Decisão de Ação
O time de operações identificou que a causa de falhas intermitentes na entrega de e-mail para fabrikam.com é um registro MX incorreto na zona pública hospedada no Azure DNS. O registro atual aponta para mail.fabrikam.com com prioridade 10, mas deveria apontar para mailrelay.fabrikam.net com prioridade 10.
O ambiente tem as seguintes restrições:
- O domínio
fabrikam.comestá em produção com tráfego ativo de e-mail - O TTL atual do registro MX é de 3600 segundos
- A janela de manutenção aprovada começa em 4 horas
- O time tem permissão para editar registros DNS a qualquer momento, sem necessidade de aprovação adicional
- Existe um servidor de e-mail de contingência configurado e funcional em
mailbackup.fabrikam.net
Qual é a ação correta a tomar agora, antes da janela de manutenção?
A) Corrigir imediatamente o registro MX apontando para mailrelay.fabrikam.net e aguardar a propagação natural do TTL de 3600 segundos.
B) Reduzir o TTL do registro MX atual para 60 segundos agora, de forma que quando a correção for aplicada na janela de manutenção, a propagação seja rápida.
C) Adicionar imediatamente um segundo registro MX apontando para mailbackup.fabrikam.net com prioridade 20 para reduzir a perda de e-mails até a janela de manutenção, e corrigir o registro principal durante a janela.
D) Aguardar a janela de manutenção para reduzir o TTL e só então corrigir o registro MX, evitando qualquer alteração em produção fora do horário aprovado.
Cenário 3 — Causa Raiz
Uma empresa configurou a zona pública dev.contoso.com no Azure DNS como uma zona separada de contoso.com. O objetivo era delegar o subdomínio dev para uma equipe de desenvolvimento gerenciar seus próprios registros.
Após a configuração, os registros dentro de dev.contoso.com como api.dev.contoso.com funcionam corretamente quando testados diretamente contra os name servers da zona filha. No entanto, quando qualquer usuário externo tenta resolver api.dev.contoso.com a partir de resolvedores públicos, a resposta é NXDOMAIN.
O engenheiro verifica as seguintes informações:
; Consulta direta ao name server da zona filha
$ nslookup api.dev.contoso.com ns1-05.azure-dns.com
Server: ns1-05.azure-dns.com
Address: 150.171.11.5
Name: api.dev.contoso.com
Address: 10.0.1.50
; Consulta via resolver publico
$ nslookup api.dev.contoso.com 8.8.8.8
Server: dns.google
Address: 8.8.8.8
** server can't find api.dev.contoso.com: NXDOMAIN
O time confirma que a zona contoso.com está hospedada no Azure DNS e está funcionando corretamente para outros registros. O time de rede informa que nenhuma regra de firewall bloqueia consultas DNS externas para os name servers do Azure.
Qual é a causa raiz do comportamento observado?
A) O endereço IP retornado pelo name server da zona filha (10.0.1.50) é privado, e resolvedores públicos filtram respostas com endereços RFC 1918 por padrão.
B) A zona dev.contoso.com foi criada no Azure DNS, mas nenhum registro NS de delegação foi adicionado na zona pai contoso.com apontando para os name servers da zona filha.
C) O Azure DNS não suporta delegação de subdomínios dentro da mesma assinatura; a zona filha deve estar em uma assinatura diferente para que a delegação funcione corretamente.
D) A zona filha dev.contoso.com está usando name servers diferentes dos da zona pai contoso.com, e resolvedores públicos exigem que os name servers sejam idênticos para aceitar a delegação.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "O site shop.tailwindtraders.com parou de resolver externamente logo após uma mudança no DNS."
Ele tem acesso ao portal do Azure, ao registrador do domínio e a ferramentas de linha de comando. Os seguintes passos de investigação estão disponíveis, mas foram listados fora de ordem:
- Passo P: Consultar os name servers autoritativos da zona diretamente com
nslookup shop.tailwindtraders.com <nameserver>para verificar se o registro existe e está correto na fonte. - Passo Q: Verificar no portal do Azure se a zona
tailwindtraders.comexiste e se o registro A parashopestá presente com o valor correto. - Passo R: Verificar no registrador se os quatro name servers do Azure estão corretamente configurados como servidores autoritativos para o domínio.
- Passo S: Usar uma ferramenta externa como
dig +trace shop.tailwindtraders.compara observar o caminho completo de resolução e identificar em qual nível a falha ocorre. - Passo T: Consultar um resolver público como
8.8.8.8e comparar o resultado com a consulta direta ao name server autoritativo.
Qual sequência de investigação segue a lógica correta de diagnóstico progressivo, do mais básico ao mais específico?
A) Q, R, P, T, S
B) S, T, R, Q, P
C) R, Q, P, S, T
D) Q, P, R, S, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva no enunciado é que a zona no provedor legado ainda existe. Quando o registrador é atualizado com os novos name servers do Azure, mas a zona antiga permanece ativa no provedor anterior, o comportamento esperado é que resolvedores que ainda têm o registro NS antigo em cache consultem os name servers do provedor legado e recebam o IP antigo. Isso explica a inconsistência regional: resolvedores que renovaram seu cache após a delegação resolvem corretamente; os demais ainda apontam para o provedor anterior.
A informação sobre revogação de credenciais é deliberadamente irrelevante: o DNS não é controlado por autenticação de usuário; a zona continua respondendo independentemente de quem pode acessar o painel administrativo. A alternativa B descreve um fenômeno real relacionado ao TTL do SOA, mas o SOA não controla a delegação NS; o que importa é o TTL dos registros NS no nível do registrador e do TLD. A alternativa A inverte a lógica: TTL baixo favorece propagação mais rápida, não inconsistência. A alternativa D é tecnicamente sem sentido para esse contexto: o Microsoft Entra ID não participa da resolução DNS pública.
O distrator mais perigoso é a alternativa B, porque o raciocínio sobre TTL de SOA parece técnico e plausível, levando o engenheiro a aguardar passivamente em vez de agir removendo a zona legada.
Gabarito — Cenário 2
Resposta: B
A lógica correta aqui é preparar a correção antes de executá-la. Com um TTL de 3600 segundos, qualquer alteração feita agora levará até uma hora para propagar nos resolvedores que já cachearam o registro. Reduzir o TTL imediatamente para 60 segundos garante que, quando a correção for aplicada durante a janela de manutenção (em 4 horas), a propagação será concluída em minutos, minimizando o impacto.
A alternativa A é a ação tecnicamente válida, mas aplicada no momento errado: corrigir o registro agora, com TTL de 3600, significa que a propagação levará até uma hora, durante a qual a entrega continuará falhando ou sendo inconsistente, sem controle do time. A alternativa C parece razoável, mas adiciona complexidade desnecessária e não resolve a falha principal; o servidor de contingência só receberia e-mails que o servidor primário incorreto não consegue entregar, o que depende do comportamento de retentativa do servidor remetente. A alternativa D ignora uma janela de ação prévia útil e deixa o problema sem mitigação por mais 4 horas.
Gabarito — Cenário 3
Resposta: B
As evidências no enunciado apontam diretamente para a causa: a consulta direta ao name server da zona filha funciona perfeitamente, mas resolvedores públicos retornam NXDOMAIN. Isso significa que o registro existe e está correto na zona filha, mas o caminho de delegação está quebrado. A causa clássica desse sintoma é a ausência dos registros NS na zona pai que apontem para os name servers da zona filha. Sem esses registros NS em contoso.com, resolvedores que percorrem a hierarquia chegam à zona pai, não encontram delegação para dev.contoso.com e retornam NXDOMAIN.
A informação sobre o endereço IP privado (10.0.1.50) é deliberadamente irrelevante para o diagnóstico: resolvedores públicos não filtram respostas com IPs RFC 1918 na camada de DNS; eles retornam o que o servidor autoritativo responde. O NXDOMAIN indica ausência de resposta autoritativa, não filtragem de conteúdo. A alternativa C é falsa: o Azure DNS suporta delegação de subdomínios dentro da mesma assinatura sem restrição. A alternativa D descreve um comportamento que não existe no protocolo DNS; name servers de zonas pai e filha são intencionalmente diferentes na delegação.
Gabarito — Cenário 4
Resposta: A
A sequência correta é Q, R, P, T, S, que segue o raciocínio de eliminação progressiva do mais simples ao mais complexo:
- Q — Verificar primeiro se o registro existe no Azure DNS. Se não existe, a causa está identificada imediatamente.
- R — Confirmar se a delegação no registrador está correta. De nada adianta o registro existir se os name servers não estão delegados corretamente.
- P — Consultar diretamente o name server autoritativo para confirmar que ele responde corretamente para o registro.
- T — Comparar o resultado do name server autoritativo com o de um resolver público para isolar se o problema é na fonte ou na propagação.
- S — Usar
dig +tracecomo passo final para mapear exatamente em qual nível da hierarquia a resolução falha, confirmando o diagnóstico.
A alternativa B começa pela ferramenta mais complexa (dig +trace), o que é ineficiente: se o registro simplesmente não existe no Azure, todo o trace é desnecessário. A alternativa C pula a verificação do registro no portal antes de consultar o name server diretamente, perdendo o passo mais básico de confirmação. A alternativa D omite a verificação de delegação no registrador, que é uma das causas mais comuns de falha de resolução externa.
Árvore de Troubleshooting: Design Public DNS Zones
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga as ramificações respondendo cada pergunta com base no que você consegue verificar diretamente no ambiente. Perguntas azuis exigem uma verificação ativa antes de avançar; não pule etapas. Quando chegar a um nó vermelho, a causa está identificada; o nó verde imediatamente conectado indica a ação corretiva. Nós laranjas indicam validações intermediárias que confirmam ou descartam hipóteses antes de seguir para o próximo ramo.