Pesquisa de registo SOA

Host

Tipo

Resolvedor

Rastreamento iterativo

No modo de rastreamento iterativo, o resolvedor é ignorado.

Teste de propagação

Consulta vários resolvedores públicos para comparar as respostas.

Como utilizar corretamente as diferentes opções do motor de pesquisa DNS?

O que é a traçado iterativa?

A traçado executa a resolução passo a passo. O resolvedor consulta primeiro os servidores raiz, depois os do TLD (.com, .br, .pt) e, por fim, os servidores autoritativos da zona pretendida. Em cada etapa, a página mostra o servidor consultado, a resposta, o RCODE e a latência.

1. Raiz
Descoberta dos servidores do TLD para o nome solicitado.
2. TLD
Referência aos NS da zona (delegação).
3. Autoritativos
Resposta final (ou erro) com TTL e latência.

Para que serve?

Comparar respostas entre resolvedores e regiões
Detetar um cache quente, um TTL demasiado longo ou uma delegação incompleta
Explicar diferenças de latência ou um RCODE inesperado

Dica: deixe a traçado desativada para verificações rápidas; ative-a durante investigações ou para preparar um ticket/post-mortem.

O que é a traçado clássica?

A traçado clássica consulta apenas o resolvedor selecionado (UDP ou DoH) e mostra a resposta tal como é percecionada a partir desse ponto da rede. Obtém o RCODE, as secções da resposta e a latência do percurso cliente → resolvedor.

1. Resolvedor escolhido
Use o preset ou a configuração personalizada para lançar a consulta exatamente como o seu serviço faria.
2. Protocolo preservado
Respeita o transporte selecionado (UDP, TCP ou DoH) para reproduzir o comportamento real.
3. Resposta detalhada
Mostra as secções question, answer e authority/additional quando existirem, com TTL e metadados úteis.

Porque utilizá-la?

Verificar a visão de um resolvedor específico antes de suspeitar de delegação
Confirmar valores em cache e o impacto de um TTL ou de um flush
Documentar uma resolução tal como a vê um cliente ou microserviço

Dica: mantenha a traçado iterativa desativada quando auditar um resolvedor específico; ative-a depois para comparar com o percurso raiz → TLD → autoritativo.

Como funciona o teste de propagação?

O teste consulta em paralelo um conjunto de resolvedores públicos (Google, Cloudflare, Quad9, OpenDNS, ISP…) e agrupa as respostas por conteúdo e RCODE. Vê imediatamente quem já aplicou a atualização.

1. Resolvedores multiponto
Ative os presets de propagação para consultar vários atores distribuídos pelo mundo.
2. Comparação automática
Agrupa respostas idênticas e assinala divergências ou erros específicos de cada resolvedor.
3. Resumo acionável
Apresenta um resumo claro, a lista de resolvedores, latências e estado de cada grupo.

Quando usar?

Acompanhar a difusão de uma alteração DNS à escala global
Identificar caches ainda antigos e decidir um flush direcionado
Partilhar um estado de propagação num ticket ou post-mortem

Dica: durante o teste de propagação, a seleção de resolvedor fica bloqueada. Desative o modo para voltar ao diagnóstico unitário.

Informação adicional sobre registos DNS tipo SOA

Um registo SOA descreve a autoridade de uma zona DNS. Indica o servidor primário, o contacto responsável e fornece o número de série e temporizações que regem a sincronização com servidores secundários.
Inclui nome, tipo, servidor primário (MNAME), contacto (RNAME), serial e cinco durações. O TTL controla o tempo em cache no resolvedor local.

Exemplo de registo SOA

Nome	Tipo	Servidor primário	Contacto	Serial	Refresh	Retry	Expire	Minimum TTL	TTL (s)
@	SOA	ns1.exemplo.net.	hostmaster.exemplo.com.	2025090301	7200	900	1209600	3600	3600

O contacto é escrito como email com ponto no lugar da arroba: hostmaster.exemplo.com. corresponde a hostmaster@exemplo.com. O serial deve aumentar a cada alteração. Refresh, retry, expire e minimum TTL são expressos em segundos.

Função dos campos

MNAME: host de referência da zona.
RNAME: contacto para notificações sobre a zona.
Serial: usado pelos secundários para detetar atualizações.
Refresh: intervalo entre verificações do primário pelos secundários.
Retry: tempo antes de tentar novamente após falha.
Expire: prazo após o qual um secundário desiste se não conseguir atualizar.
Minimum TTL: tempo de cache negativo (não é o TTL padrão dos demais registos).

Nota
Existe apenas um SOA por zona, publicado no ápice com os NS. O campo minimum TTL rege apenas caches negativas.

TTL explicado

O TTL do SOA controla o cache desta resposta. Valor demasiado alto pode atrasar a observação de novo serial; valor equilibrado garante reatividade sem sobrecarga.

Onde usar SOA

Sempre no ápice da zona. Subdomínios delegados têm SOA próprio na zona filha. O ápice não pode ser CNAME, pois precisa conter SOA e NS.

Evite
Esquecer de incrementar o serial após alterações.
Definir primário que não resolve em A/AAAA.
Trocar refresh por retry.
Usar expire demasiado curto, levando secundários a abandonar a zona.

Verificar online

Lookup DNS mostra MNAME, RNAME, serial e temporizações. Em seguida teste localmente.

Windows

nslookup
set q=soa
exemplo.com

nslookup
set q=soa
server 1.1.1.1
exemplo.com

Linux/macOS

dig soa exemplo.com

dig soa exemplo.com @1.1.1.1

Leitura rápida

Serial antigo num secundário indica atraso na transferência. Refresh alto atrasa propagação. Expire curto pode fazer secundário abandonar a zona. Contacto mal formatado impede comunicações.

Procedimento simples

Preparar alterações da zona.
Incrementar o serial.
Recarregar a zona no primário.
Permitir que secundários sincronizem (ou forçar transferência).
Verificar novo serial a partir de várias redes.

Dica prática
Utilize formato de serial predictível, como AAAAMMDDXX. Ex.: 2025090301 para a primeira alteração do dia.

Casos frequentes

Troca de fornecedor DNS

Configurar zona no novo serviço, validar SOA/NS e, então, atualizar delegação no registo.

Adicionar secundário

Autorize transferência no primário e confirme que o secundário obtém a zona com o serial correcto.

Atualizar contacto

Modificar RNAME e confirmar receção de emails de teste.

Resolução rápida

Se SOA divergir entre autoritativos, aguarde ciclo de refresh e verifique novamente.
Se secundário ficar preso em serial antigo, verifique conectividade e permissões de transferência.
Se a zona “cair” num secundário, aumente expire e valide o estado do primário.
Se o valor antigo persistir no resolutor, aguarde o TTL e limpe caches controladas.

Em resumo, o SOA define autoridade e temporizações de uma zona. Serial consistente e valores ajustados garantem sincronização fiável. Verifique com ferramentas online e com nslookup/dig para manter a operação previsível e sem stress.