Resolvendo o "IP fantasma" após editar zonas DNS manualmente no cPanel
Voltar para blog

Resolvendo o "IP fantasma" após editar zonas DNS manualmente no cPanel

07/06/2026 · 9 min · Infraestrutura

O enigma do IP residual após edições manuais no BIND#

Quem administra servidores corporativos baseados na stack cPanel/WHM internaliza precocemente que, muitas vezes, as limitações reativas da interface gráfica demandam bypasses diretos via shell. Durante rotinas de manutenção recentes, executei a supressão de um apontamento hostil de DNS editando a base física da zona diretamente via SSH. Realizei a gravação do arquivo e considerei o ciclo finalizado. Contudo, na telemetria de testes, o IP expurgado persistia, "assombrando" as respostas globais do resolver.

Se você já vivenciou este atrito operacional, conhece a frustração contida ao disparar o client dig e deparar-se com um IP que foi absolutamente removido de /var/named/. Neste relatório documentarei as etapas de isolamento aplicadas, discriminando os vícios inerentes em injeções brutas de zonas locais e como forçar alinhamento absoluto nos nós do DNS Cluster (cPanel).

O cenário e a camada do disfuncional#

A premissa demandava truncar ativamente o tráfego eliminando a resolução de um IPv4 específico do grupo A-Record de um domínio ativo (domain.com). Conectado em superuser, manuseei os binários de arquivos estáticos localizando os arquivos coringa de BIND.

No entanto, antes de qualquer intervenção direta, é mandatório realizar o backup de segurança para permitir rollbacks rápidos caso ocorram falhas catastróficas de sintaxe no BIND:

# Backup da zona individual antes da alteração
cp /var/named/meudominio.com.br.db /var/named/meudominio.com.br.db.bak.$(date +%Y%m%d)

# Backup completo de segurança de todo o diretório do BIND
tar czf /root/named-backup-$(date +%Y%m%d).tar.gz /var/named/

Como localizar o arquivo de zona correto#

Muitas vezes, a zona DNS de um domínio pode estar nomeada de forma ligeiramente diferente ou residir em caminhos alternativos dependendo da customização do servidor cPanel. Para identificar e confirmar a localização do arquivo .db:

# 1. Listar todas as zonas cadastradas no diretório padrão do BIND
ls -la /var/named/*.db

# 2. Consultar a configuração do named para encontrar a diretiva 'file' da zona
named-checkconf | grep -i "file"

# 3. Via WHM, o caminho pode ser visualizado em: DNS Functions → Edit DNS Zone → Selecionar domínio → Ver caminho
# Ou via utilitários internos do cPanel via CLI:
cat /var/cpanel/users/usuario/dns

Uma vez localizado e feito o backup, procedi com a edição:

vi /var/named/meudominio.com.br.db

Suprimi o line array contendo a entidade mapeada (para exemplificação: 200.100.50.25), gravei os blocos no disco e verifiquei a eficácia executando query externa em seguida. Para atrito com a lógica padrão, o socket do terminal devolveu as seguintes outputs de debug:

[root@server ~]# dig +short A meudominio.com.br
10.20.30.40
10.20.30.41
200.100.50.25

A ocorrência reflete a falha sistêmica visualmente: O IP 200.100.50.25 figurava perfeitamente visível e roteável. Físicamente o armazenamento certificava apagamento nos descritores /var/named/, todavia o socket port 53 prosseguia despejando a indexação apagada.

O diagnóstico forense: isolando a origem paramétrica#

Quando SysAdmins expedem strings convencionais através de dig negando especificação de resolvedores dedicados primários, os cálculos são processados subordinando-se às definições descritas no próprio núcleo operativo (como Google, Cloudflare ou roteamentos root listados no cache dos datacenters) - estruturas pesadamente ancoradas em Cache (TTL).

Precisando auditar se o bloqueio provinha dos enraizamentos em ISPs distantes sofrendo latência global ou inibição puramente em tempo real atrelada à Engine de resposta nativa do nó servidor local, apliquei query loopback bypass visando unicamente o núcleo base residente do daemon (BIND).

Desencadeei o verificador local estrito abaixo:

dig @localhost +short A meudominio.com.br

Essa ramificação isolou ativamente meu threshold de decisão técnica determinando perfeitamente a topologia correta atuando diante de dois escopos excludentes:

Cenário a: supressão efetiva pelo root local (@localhost limpo)#

Caso a resposta sob bypass local (@localhost) omitisse a anomalia do IP, confirma-se inquestionavelmente leitura base validada pelo aplicativo de serviço operativo (BIND). O engasgo temporal das queries públicas enquadrava-se puramente sob TTL (Time To Live) da referida zona de DNS original.

Caso um .db mantivesse $TTL pré-assinado como 14400 (4H) fixo ou 3600 (1H), todos os resolvers subjacentes baseados na internet mantinham tabelas bloqueadas temporalmente aguardando inativação nativa estrita natural temporal orgânica. Zero falhas internas.

Cenário b: propagação do vício reincidente (@localhost contendo IP antigo)#

E aqui incidiu na raiz problemática: o daemon primário no localhost persistia entregando as routes obsoletas retransmitindo inteiramente as tabelas que eu excluí no disco. A leitura explícita identificou falha na sincronia entre Disk Storage State contrapondo o Active Memory Cache. Quais motivos fariam cPanel/BIND omitirem as injeções atualizadas brutamente? Abaixo evidencio as amarras exatas.

Quebras na confiabilidade nas injeções diretas via cPanel#

Incidimos no cenário de suspensão em memória do cPanel. Forcei normalização estruturada mapeada superando os seguintes equívocos atômicos intrínsecos de edições shell não supervisionadas nos motores Linux:

1. Incremento de sequenciamento de série omitido (avaria no serial number)#

A interface UI do painel incorpora reestruturações em batch atestando injeção. Ao contrário do WHM API local, as edições via nano/vi não provocam hooks automáticos de update local alertando as flags de reload. BIND não varre incondicionalmente arrays verificando diferenciações no disco puro a menos que um SOA_Trigger expresse mutações explícitas no SOA (Start of Authority).

O arquivo .db aberto obriga incremento manual restrito na métrica do Serial Number, padronizada via modelo de versionamento AAAAMMDDnn (Ano, Mês, Dia, Revisão).

2024030801 ;Serial <- Se este número não for aumentado, a alteração é ignorada catastroficamente

Executei mutação para versão subida (2024030802) escrevendo com sucesso.

Verificação do Serial#

Para confirmar se o serial foi devidamente modificado na base do arquivo físico e nas respostas locais do SOA:

# Buscar a linha correspondente ao serial no arquivo de zona
grep -i "serial" /var/named/meudominio.com.br.db

# Verificar se o SOA local já está respondendo com o novo serial
dig SOA meudominio.com.br @localhost +short
# Exemplo de saída: ns1.meudominio.com.br. admin.meudominio.com.br. 2024030802 3600 900 604800 86400

2. Associações clones escondidas em zonas (verificação de registros duplicados)#

Remoções parciais acarretam disfunções sistêmicas; IPs alvos de expurgo tendem a figurar paralelamente referenciados em registros de alias (CNAMEs) ou registros do tipo A residuais espalhados. Adoto instâncias forenses rastreando via regex a inexistência garantida em loop-holes:

# Buscar todos os registros A contendo o IP antigo a ser removido
grep "200.100.50.25" /var/named/meudominio.com.br.db

# Buscar todos os registros A do domínio (casa espaço inicial ou host explícito)
grep -E "^\s*(\S+\s+)?IN\s+A\s+" /var/named/meudominio.com.br.db

# Contar de forma precisa os registros A restantes (evita falsos positivos como AAAA)
grep -cE "^\s*(\S+\s+)?IN\s+A\s+" /var/named/meudominio.com.br.db

O procedimento arquitetural resolutivo seguro e sincronização#

Adicionado e formatado corretamente o Incremento de Serial, a nova rotina imperiosamente carece injeção no núcleo da RAM transitória propagando para as filiais de BIND operantes globais (Data Clusters). Emprego este Standard Operations Procedure (SOP) estrito executando pela interface backend puramente CLI:

1. Verificação gramatical de sintaxe de zona (safety net override)#

Garantir zero erros sintáticos inviabilizando colapsos em domínios core exige parsing validante de segurança:

named-checkzone meudominio.com.br /var/named/meudominio.com.br.db

Se retornar "OK", é possível prosseguir para o reload. Caso contrário, corrija o erro antes de efetuar qualquer alteração. Os erros de sintaxe mais comuns no BIND são:

2. Verificação de permissões da zona#

Arquivos de zona editados sob a credencial root podem sofrer com desvios de dono e permissão, impedindo o daemon do BIND (named) de ler as atualizações:

# Auditar as permissões atuais
ls -la /var/named/meudominio.com.br.db

# As permissões devem ser 644 (-rw-r--r--) e o proprietário named:named (ou root:root em algumas distros)
# Se necessário, corrija com:
chown named:named /var/named/meudominio.com.br.db
chmod 644 /var/named/meudominio.com.br.db

3. Reloading ativo em memória nativa isolada#

Realizei instrução mandando os pools do sistema absorver a arquitetura com o auxílio restrito gerencial rndc:

rndc reload meudominio.com.br
Verificação da Conectividade do rndc e Daemon named#

Se o reload falhar ou apresentar lentidão, valide a saúde e conectividade do utilitário rndc:

# Verificar o status de operação do rndc e do BIND
rndc status

# Limpar o cache do BIND local (teste de integridade da conexão do rndc)
rndc flush

# Detectar serviço BIND ativo automaticamente (named ou named-chroot no cPanel)
BIND_SVC="named"
systemctl is-active named-chroot >/dev/null 2>&1 && BIND_SVC="named-chroot"
systemctl is-active named >/dev/null 2>&1 && BIND_SVC="named"

# Confirmar se o daemon do BIND está ativo
systemctl status "$BIND_SVC"
Inspecionando Logs do BIND para Debug#

Sempre audite a saída dos logs do BIND correspondentes ao serviço ativo para garantir que a recarga da zona foi concluída sem avisos críticos:

# Acompanhar logs do named em tempo real usando o serviço detectado
journalctl -u "$BIND_SVC" -f

# Auditar logs específicos de erro
journalctl -u "$BIND_SVC" -p error

# Procurar erros e avisos na leitura das zonas
journalctl -u "$BIND_SVC" | grep -i "error\|warning" | tail -20

4. Replicação master para o BIND DNS cluster array#

Alojados frente configurações de tolerância (Master-Multi-Slave model via DNS Roles do WHM), atualizações exclusivamente alocadas e registradas isoladamente permanecem vulneráveis sem difusões ativas. Proibi um custoso recarregamento estático integral (/scripts/dnscluster syncall) poupando latência e recursos base, mandando recarga orientada singularmente ao escopo focal modificado estrito:

/scripts/dnscluster synczone meudominio.com.br
Validação de Status do DNS Cluster#

Para confirmar que o cluster DNS está funcional e em sincronia:

# Verificar status atual do cluster
/scripts/dnscluster status

# Listar zonas sincronizadas no cluster
/scripts/dnscluster listzones

# Visualizar logs em tempo real da sincronização
tail -50 /usr/local/cpanel/logs/dnscluster.log

# Caso o cluster esteja desatualizado por completo, execute um sync global:
/scripts/dnscluster syncall

5. Pós-edição: verificação de propagação externa#

Após concluir a sincronização da zona local e do cluster, certifique-se de que a propagação externa ocorreu conforme o planejado:

# Consultar via servidores DNS públicos externos
dig @8.8.8.8 meudominio.com.br A +short
dig @1.1.1.1 meudominio.com.br A +short

# Inspecionar o tempo de cache (TTL) restante no resolvedor público
dig meudominio.com.br | grep -A1 "ANSWER SECTION"

# Loop rápido para consultar múltiplos provedores externos simultaneamente
for dns in 8.8.8.8 1.1.1.1 208.67.222.222; do
    echo "DNS $dns: $(dig @$dns meudominio.com.br +short)"
done

Cuidados especiais em produção: DNSSEC, zonas dinâmicas e templates WHM#

A. Zonas assinadas com DNSSEC#

Se o domínio possui DNSSEC ativo, os registros da zona são assinados criptograficamente. Qualquer modificação manual no arquivo .db invalidará as assinaturas (RRSIG), fazendo com que resolvedores DNS que validam DNSSEC retornem erro SERVFAIL para os clientes. Ao editar a zona manualmente, você precisa re-assinar a zona. Se o cPanel gerencia as chaves:

# Re-assinar a zona usando as ferramentas integradas do cPanel/WHM
/usr/local/cpanel/bin/dnssec-signzone meudominio.com.br

Ou manualmente com o BIND:

dnssec-signzone -o meudominio.com.br -N INCREMENT /var/named/meudominio.com.br.db

B. Zonas dinâmicas (DDNS) e concorrência (rndc freeze/thaw)#

Se o servidor aceita atualizações dinâmicas, o BIND mantém as alterações temporárias em um arquivo de journal .jnl. Editar o .db diretamente enquanto o named está rodando causará conflitos e o named irá sobrescrever o arquivo .db a partir da memória ou do journal, descartando suas edições manuais. Para editar com segurança, use as instruções do rndc:

# 1. Congelar a zona (escreve o journal no .db e suspende updates dinâmicos na memória)
rndc freeze meudominio.com.br

# 2. Realizar as edições manuais no arquivo .db

# 3. Descongelar a zona (recarrega as alterações e reativa os updates dinâmicos)
rndc thaw meudominio.com.br

C. Templates de zona do WHM#

O cPanel reconstrói os arquivos de zona DNS em diversas operações automáticas (por exemplo, ao alterar o IP da conta, renomear domínios ou restaurar backups) baseando-se em templates localizados em /var/cpanel/templates/dnszones/. Modificações manuais feitas diretamente no /var/named/ que não estejam previstas no template correm o risco de serem completamente descartadas em futuras reconstruções. Sempre que realizar alterações estruturais permanentes, avalie adaptá-las nos templates de zona via WHM ou CLI.

Fluxo de diagnóstico e decisão: "IP fantasma"#

O diagrama abaixo ilustra o processo lógico detalhado de triagem e mitigação de inconsistências em zonas DNS do BIND:

flowchart TD A["dig +short meudominio.com.br<br/>retorna IP antigo"] --> B[dig @localhost +short] B --> C{"@localhost retorna<br/>IP antigo?"} C -->|Não| D["Cache público (TTL).<br/>Aguardar expiração ou reduzir TTL"] C -->|Sim| E["Serial SOA foi<br/>incrementado?"] E -->|Não| F["Incrementar serial<br/>AAAAMMDDnn e salvar"] E -->|Sim| G[named-checkzone OK?] G -->|Não| H["Corrigir sintaxe:<br/>ponto final em FQDN, $ORIGIN ausente"] G -->|Sim| I{Zona é dinâmica?} I -->|Sim| J["rndc freeze<br/>fazer alteração<br/>rndc thaw"] I -->|No| K[rndc reload meudominio.com.br] J --> L["Verificar permissões do arquivo<br/>named:named + chmod 644"] K --> L L --> M{Zona assinada com DNSSEC?} M -->|Sim| N[Re-assinar a zona com dnssec-signzone] M -->|Não| O[/scripts/dnscluster synczone] N --> O O --> P[dnscluster status OK?] P -->|Não| Q[tail -f /usr/local/cpanel/logs/dnscluster.log] P -->|Sim| R["dig @8.8.8.8 +short<br/>verificar propagação externa"]

SOP: edição segura de zona DNS no cPanel/BIND#

Abaixo está o checklist do fluxo operacional padrão para garantir que nenhuma etapa de segurança ou validação seja omitida em ambientes de produção:

Pré-edição#

Edição#

Validação de sintaxe e permissões#

Ativação e cluster#

Pós-edição (validação de propagação)#

Script de validação automatizada de zonas DNS#

#!/bin/bash
# validate-dns.sh - Diagnóstico de Zonas DNS BIND no cPanel
# Uso: ./validate-dns.sh <dominio.com.br>

ZONE="${1:-}"
DB_FILE="/var/named/${ZONE}.db"

if [ -z "$ZONE" ] || [ ! -f "$DB_FILE" ]; then
    echo "Erro: Domínio ou arquivo de zona não encontrado."
    echo "Uso: $0 <dominio.com.br>"
    exit 1
fi

echo "=========================================================="
echo " INICIANDO DIAGNÓSTICO DA ZONA DNS: ${ZONE}"
echo "=========================================================="

# 1. Detectar o serviço BIND correto no cPanel/WHM
BIND_SVC="named"
systemctl is-active named-chroot >/dev/null 2>&1 && BIND_SVC="named-chroot"
systemctl is-active named >/dev/null 2>&1 && BIND_SVC="named"

# 2. Checagem de integridade e metadados do arquivo
echo -e "\n[1] Arquivo de Zona, Serviço Ativo ($BIND_SVC) e Permissões:"
ls -la "$DB_FILE"

# 3. Extração do Serial do arquivo
echo -e "\n[2] Serial Declarado no Arquivo:"
grep -i "serial" "$DB_FILE" | head -1

# 4. Validação de Sintaxe BIND
echo -e "\n[3] Validação de Sintaxe (named-checkzone):"
CHECK_OUT=$(named-checkzone "$ZONE" "$DB_FILE")
CHECK_RES=$?
echo "$CHECK_OUT"
if [ $CHECK_RES -ne 0 ]; then
    echo -e "\n--> [ERRO] Falha crítica de sintaxe detectada na zona. Não efetue reload!"
    exit 1
fi

# 5. Checagem de ORIGIN e Domínios FQDN sem ponto
echo -e "\n[4] Checagem de $ORIGIN e Sufixos DNS:"
grep -i '^$ORIGIN' "$DB_FILE" || echo "Aviso: ORIGIN não declarado explicitamente no topo."
echo "Exibindo primeiras linhas de FQDN para validação visual:"
grep -E "^[^$;]" "$DB_FILE" | grep -v "^$" | head -5

# 6. Listagem de Registros A
echo -e "\n[5] Registros A Ativos na Zona:"
grep -E "^\s*(\S+\s+)?IN\s+A\s+" "$DB_FILE" | head -15

# 7. Consulta Local (localhost)
echo -e "\n[6] Resolução Local (Query localhost):"
dig "@localhost" "$ZONE" A +short

# 8. Consulta Externa (Google DNS)
echo -e "\n[7] Resolução Externa (Query Google DNS 8.8.8.8):"
dig "@8.8.8.8" "$ZONE" A +short

# 9. Status do rndc
echo -e "\n[8] Saúde do rndc local:"
rndc status | head -5

echo -e "\n=========================================================="
echo " DIAGNÓSTICO CONCLUÍDO COM SUCESSO"
echo "=========================================================="

Sumário forense#

Manusear /var/named/ diretamente exige disciplina com SOA serial, recarregamento de daemons e sincronização de nós no cluster DNS. A regra de ouro é: Remover Registro -> Incrementar SOA Serial -> Recarregar BIND -> Sincronizar Cluster.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Veja também

Infraestrutura A ilusão do `sshd_config`: como realmente garantir a segurança da autenticação SSH no cPanel/CloudLinux
Infraestrutura Guia Definitivo de Troubleshooting de Let's Encrypt e SSL no DirectAdmin (CLI, CAA e Subdomínio WWW)
Infraestrutura Diário de suporte: driblando o pkgacct no cPanel e alinhando a comunicação com o cliente
CC BY-NC

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.

Ao comentar, você concorda com nossos Termos de Uso e Política de Privacidade.

0 comentários