Sabe aquele momento em que você percebe que uma zona de DNS está completamente "zuada" e o painel web simplesmente não responde como deveria? Recentemente, passei por isso. Eu precisava resetar as zonas imediatamente, mas os scripts tradicionais do DirectAdmin pareciam ter sido deixados de lado nas versões mais recentes.
Neste artigo, vou detalhar os erros que encontrei e a sintaxe exata que usei para forçar a reconstrução das zonas via terminal, sem depender da interface gráfica.
O cenário: quando o rndc reload não basta#
Muitas vezes, tentamos o básico: um rndc reload. Mas, se a estrutura do arquivo .db em /var/named/ estiver com erros de sintaxe ou seriais inconsistentes, o BIND vai ignorar as mudanças. Em casos de corrupção real, o melhor caminho que encontrei é o Reset (Reserver).
O erro comum: scripts legados que desapareceram#
Ao pesquisar em fóruns antigos, vi muita gente citando o dns_control.sh. No entanto, ao tentar executá-lo: bash: /usr/local/directadmin/scripts/dns_control.sh: No such file or directory
O DirectAdmin modernizou sua estrutura, e muitas dessas tarefas agora estão centralizadas em chamadas diretas ao binário principal. Tentar usar comandos "chutados" no binário novo também pode resultar em Unknown command.
A solução: comandos diretos no binário moderno#
Se você está trabalhando com versões atuais do DirectAdmin, o segredo é usar o argumento taskq com a flag --run. Isso coloca a tarefa na fila de execução imediata do daemon.
1. Recriando a zona do zero (reserver)#
O comando reserver é o que eu chamo de "botão de pânico". Ele limpa a zona atual e reconstrói o arquivo .db com base nos templates padrão e nos IPs vinculados à conta do usuário. Executei assim:
/usr/local/directadmin/directadmin taskq --run "action=dns&value=reserver&domain=meudominio.com.br"2. Forçando o rewrite da tabela#
Se o comando de reserva não gerar o arquivo físico por algum motivo de cache, você pode forçar o DirectAdmin a reescrever especificamente as configurações do serviço named para aquele domínio:
/usr/local/directadmin/directadmin taskq --run "action=rewrite&value=named&domain=meudominio.com.br"O passo final: forçar a leitura e propagação#
Não adianta o arquivo estar perfeito no disco se o serviço de DNS não "acordar". Siga esta ordem que validei em produção:
- Validação de Sintaxe: Sempre verifique se o arquivo recriado está íntegro antes de qualquer reload:
named-checkzone meudominio.com.br /var/named/meudominio.com.br.db
- Notificar o BIND: Notifique apenas a zona alterada para evitar overhead:
rndc reload meudominio.com.br
- Reiniciar o Serviço (Segurança): Se sentir que algo ainda está travado, o restart é o caminho mais seguro:
systemctl restart named
Checklist de troubleshooting operacional#
Se a zona ainda não subiu após esses passos, verifiquei que geralmente o culpado é um destes:
- Permissões de Arquivo: O dono do arquivo em
/var/named/deve ser o usuárionamed(oubind). Se estiver comoroot, o serviço não lerá. - Serial Number: O serial (ex:
2026020301) deve ser sempre maior que o anterior. Caso contrário, o Google e a Cloudflare vão ignorar sua atualização. - Declaração no named.conf: Garanta que a zona está devidamente declarada no arquivo principal de configuração do BIND.
trabalhar com DNS via CLI exige precisão absoluta. No DirectAdmin moderno, centralizar as tarefas no comando taskq --run é a forma mais ágil e profissional de resolver crises em segundos.
Espero que esse guia ajude você a economizar o tempo que eu gastei debugando scripts antigos! Se tiver alguma dúvida ou caso específico, me conte aqui nos comentários.
Este artigo foi útil?
Deixe uma reação rápida para apoiar o conteúdo:
Veja também
Este post está licenciado sob CC BY-NC.
Comentários
Participe da discussão abaixo.
0 comentários