O que é um registro SOA no DNS?

Se você já explorou os registros DNS de um domínio com dig ou uma ferramenta online, provavelmente encontrou um registro SOA sem saber exatamente para que servia. É um dos registros mais importantes de qualquer zona DNS: define quem tem autoridade sobre aquela zona, como os servidores DNS secundários devem se sincronizar e por quanto tempo os dados permanecem válidos caso o primário fique fora do ar.

O que um registro SOA contém

SOA significa Start of Authority. Toda zona DNS deve conter obrigatoriamente exatamente um registro SOA. Ele sempre fica no topo da zona e possui sete campos distintos. Veja como é um registro SOA típico:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Vamos detalhar cada campo:

MNAME (ns1.example.com.): o servidor DNS primário autoritativo da zona. É o servidor que os secundários contatam para obter atualizações
RNAME (admin.example.com.): o endereço de email do administrador da zona, mas com um ponto no lugar do @. Aqui corresponde a [email protected]. Se a parte local contém um ponto, ele deve ser escapado com barra invertida (nome\.sobrenome.example.com.)
Serial (2025052901): um número de versão da zona. Cada modificação deve incrementar esse número, caso contrário os secundários não detectarão a mudança. O formato comum é YYYYMMDDNN (data mais contador diário)
Refresh (7200): o intervalo em segundos entre verificações dos servidores secundários. Aqui, a cada 2 horas
Retry (3600): o tempo antes de uma nova tentativa se a verificação Refresh falhar. Aqui, 1 hora
Expire (1209600): o tempo após o qual um secundário para de responder pela zona se não conseguir mais contatar o primário. Aqui, 14 dias. Passado esse prazo, o secundário considera seus dados expirados e para de servir a zona
Minimum TTL (86400): desde a RFC 2308, este campo define por quanto tempo respostas negativas (NXDOMAIN) ficam em cache. Aqui, 24 horas. Se alguém consultar um subdomínio que não existe, o resolver guardará essa resposta "não existe" em cache por 24 horas

Por que o número de série importa tanto

O serial é provavelmente o campo que mais causa problemas na prática. Quando um servidor secundário contata o primário durante um ciclo de Refresh, ele compara o serial de sua cópia com o do primário. Se o do primário é maior, o secundário inicia uma transferência de zona (AXFR ou IXFR) para se atualizar. Se não mudou, não faz nada.

O erro clássico: alterar um registro DNS no primário sem incrementar o serial. Resultado, o primário tem a versão certa mas os secundários continuam servindo a antiga por horas ou dias. Os usuários recebem respostas diferentes dependendo do servidor consultado, e o problema é difícil de diagnosticar se ninguém pensa em checar o SOA.

O formato YYYYMMDDNN é uma convenção, não uma obrigação. O serial é um inteiro de 32 bits, então qualquer valor de 0 a 4.294.967.295 funciona. Mas o formato de data é recomendado porque torna os erros visíveis: um serial 2025052901 é claramente a primeira alteração de 29 de maio de 2025.

Como Refresh, Retry e Expire interagem

Esses três valores formam um sistema de resiliência para zonas DNS. O Refresh define o ritmo normal de sincronização. O Retry entra em ação quando o Refresh falha. O Expire é a rede de segurança final: após esse período sem contato com o primário, o secundário prefere parar de responder completamente a servir dados potencialmente desatualizados.

Para um domínio padrão, a RFC 1912 recomenda:

Refresh: 3.600 a 86.400 segundos (1 hora a 24 horas)
Retry: 600 a 3.600 segundos (10 minutos a 1 hora)
Expire: 1.209.600 a 2.419.200 segundos (2 a 4 semanas)
Minimum TTL: 3.600 a 86.400 segundos (1 hora a 24 horas)

Se sua zona muda com frequência (por exemplo um CDN ou infraestrutura com balanceamento dinâmico), reduza o Refresh para 300 ou 600 segundos. Se for estável, 86.400 funciona muito bem e reduz a carga no servidor primário.

Como consultar o registro SOA de um domínio

No Linux e macOS, o comando dig é o mais prático:

dig SOA example.com

No Windows, use o nslookup:

nslookup -type=SOA example.com

A resposta mostra os sete campos do SOA. Preste atenção especial ao serial: se parece antigo ou congelado, costuma ser o motivo pelo qual as alterações DNS não estão propagando corretamente.

Erros frequentes no SOA

Alguns problemas que aparecem com regularidade na prática:

O RNAME usa @ em vez de ponto, quebrando a sintaxe. [email protected] deve ser escrito como admin.example.com. no SOA
O serial é decrementado acidentalmente após restaurar um backup. Os secundários se recusarão a sincronizar até que o serial do primário volte a ficar acima do valor local deles
O Expire é curto demais (poucas horas). Se o primário cair num fim de semana, os secundários param de responder antes que alguém possa intervir
O Minimum TTL está em 0, o que significa que os resolvers não fazem cache de respostas negativas. Cada consulta a um subdomínio inexistente gera uma ida e volta completa, o que pode sobrecarregar seus servidores DNS durante um scan ou ataque

O registro SOA raramente é o primeiro que se edita ao configurar um domínio, mas costuma ser o que explica por que "o DNS não está propagando". Antes de buscar causas complexas, verifique se o serial foi devidamente incrementado e se os valores de Refresh e Expire estão adequados ao seu uso.