Debugging de DNS em camada de rede: quando o daemon carrega a zona, mas a internet não responde

Recentemente, passei por um cenário curioso em um servidor Linux com cPanel e BIND: alterei os apontamentos de uma zona DNS, o daemon named validou a sintaxe e carregou o serial novo sem erros, mas os resolvers públicos da internet (como o Google DNS em 8.8.8.8) continuavam entregando os registros antigos.

Abaixo, compartilho o passo a passo da depuração, a análise de chamadas com strace no rndc e a causa raiz identificada nos registros de delegação do TLD.

1. O sintoma: divergência entre consulta local e pública#

Após editar a zona de um domínio (example.com) e incrementar o serial no SOA, validei a integridade do arquivo:

named-checkzone example.com /var/named/example.com.db
# zone example.com/IN: loaded serial 2026040608
# OK

Consultando o daemon localmente (127.0.0.1), a resposta foi imediata e correta:

dig @127.0.0.1 example.com SOA +short
# ns1.example.com. hostmaster.guardian.hostingprovider.net. 2026040608 3600 1800 1209600 86400

dig @127.0.0.1 example.com A +short
# 198.51.100.246

Porém, ao consultar resolvers públicos como o 8.8.8.8:

dig @8.8.8.8 example.com SOA +short
# ns1.example.com. root.vps.example.com. 2026031501 3600 1800 1209600 86400

dig @8.8.8.8 example.com A +short
# 203.0.113.143

Havia um descompasso claro:

• Local (127.0.0.1): Serial 2026040608, apontando para o IP novo 198.51.100.246.
• Público (8.8.8.8): Serial antigo 2026031501, apontando para o servidor legado 203.0.113.143.

2. A falha no plano de controle do BIND (rndc out of range)#

Ao tentar forçar a limpeza de cache e recarregar o BIND via CLI:

rndc reload example.com
# rndc: recv failed: out of range

Para entender o que o utilitário estava fazendo no nível de chamadas de sistema, rodei o rndc sob o strace:

strace -v -s 1024 rndc reload example.com

Análise do trace#

O trace mostrou a leitura da chave em /etc/rndc.key (hmac-sha256), abertura de sockets de controle e a chamada de terminação:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 16
close(16) = 0
write(11, "\1\0\0\0\0\0\0\0", 8) = 8
rt_sigtimedwait([HUP INT TERM], rndc: recv failed: out of range
 <unfinished ...>) = ?
+++ exited with 1 +++

No BIND 9.16+, essa mensagem aponta para inconsistência no handshake TCP do canal de controle (porta 953) ou frame malformado recebido pelo cliente rndc durante a troca de mensagens, diferindo dos erros convencionais de conexão recusada. Para contornar o canal de controle local e forçar o recarregamento, reiniciei o serviço diretamente pelo systemd:

systemctl restart named

3. Rastreando a árvore de delegação com dig +trace#

Mesmo com o named respondendo diretamente no IP do servidor novo, a internet continuava buscando a zona antiga.

Rastreei a cadeia de resolução a partir dos Root Servers:

dig +trace example.com

Saída:

com.                    86400   IN      DS      19718 13 2 ...
;; Received 1178 bytes from 198.97.190.53#53(h.root-servers.net) in 0 ms

example.com.            172800  IN      NS      ns1.example.com.
example.com.            172800  IN      NS      ns2.example.com.
;; Received 472 bytes from 192.43.172.30#53(i.gtld-servers.net) in 205 ms

example.com.            14400   IN      A       203.0.113.143
;; Received 159 bytes from 203.0.113.38#53(ns2.example.com) in 123 ms

Diagnóstico do fluxo:#

1. O Root Server delegou a consulta para os servidores do TLD .com (gtld-servers.net).
2. O TLD informou que os servidores autoritativos eram ns1.example.com e ns2.example.com.
3. O resolver foi consultar ns2.example.com no IP 203.0.113.38 (o IP do servidor antigo).
4. O servidor antigo atendeu à requisição e entregou o registro A antigo: 203.0.113.143.

O novo servidor estava configurado corretamente, mas nenhum resolver da internet chegava até ele porque a delegação pública apontava para os IPs legados.

4. A causa raiz: glue records desatualizados no TLD#

Para confirmar, fiz uma consulta não recursiva diretamente no servidor de autoridade do TLD .com:

dig ns example.com @i.gtld-servers.net

O retorno na ADDITIONAL SECTION confirmou a causa raiz:

;; AUTHORITY SECTION:
example.com.     172800  IN      NS      ns1.example.com.
example.com.     172800  IN      NS      ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com. 172800  IN      A       203.0.113.143
ns2.example.com. 172800  IN      A       203.0.113.38

Como os nameservers (ns1/ns2) fazem parte da mesma zona que resolvem (example.com), o protocolo DNS exige a presença de Glue Records na zona pai para evitar dependência circular.

A operadora do TLD .com ainda mantinha os IPs do servidor antigo associados aos nomes ns1 e ns2.

5. Como resolver#

O ajuste não depende do named.conf nem de configurações no servidor local. A correção é feita diretamente no Registrador de Domínio:

1. Acesse o painel onde o domínio foi registrado (GoDaddy, Namecheap, Registro.br, etc.).
2. Localize a seção de Glue Records (chamada de Child Nameservers, Hostnames ou Registered Hosts).
3. Atualize os IPs correspondentes:

• ns1.example.com -> 198.51.100.246
• ns2.example.com -> 198.51.100.247

1. Aguarde a expiração do TTL da delegação do TLD e valide com dig ns example.com @i.gtld-servers.net até que os novos IPs apareçam na Additional Section.

Conclusão: lições práticas sobre delegação de DNS#

1. Consulta em 127.0.0.1 valida apenas o arquivo local: O fato do BIND carregar a zona não significa que a internet está sendo roteada para o seu servidor.
2. Use dig +trace para ver o caminho real: O trace expõe onde a cadeia de resolução está sendo desviada.
3. Nameservers no mesmo domínio exigem Glue Records: Sempre que os servidores NS utilizarem o mesmo domínio do site, atualizar os IPs no registrador é mandatório para que a raiz da internet reconheça a nova infraestrutura.

Veja também

Servidores Guia Completo de Zonas DNS no cPanel e WHM: Correção do Erro 'DNS Entry Already Exists', killdns e Templates Avançados

Linux Como resolver o erro 'cannot refresh cache whilst offline' no Linux e cPanel

Infraestrutura Estudo de caso (RCA): investigando falha global de roteamento de e-mails pós-migração no cPanel

Este post está licenciado sob CC BY-NC.