Voltar para blog

Troubleshooting BIND9 + WHMCS: sintaxe DNS, cron de alta performance e integração eNom

02/03/2026 · 4 min · WHMCS

Compartilhar

Neste incidente, tratei três pontos encadeados em um ambiente de hosting: falha de sintaxe no BIND9, ajuste de cron no WHMCS para reduzir contenção e revisão da integração do registrador eNom com foco em segurança operacional.

A falha inicial foi:

missing ';' before 'deny'

A partir daí, executei um fluxo completo de diagnóstico, correção, validação e hardening para estabilizar DNS autoritativo, automação de billing/domínios e registro automático.

1) BIND9: diagnóstico de falha de sintaxe sem risco de indisponibilidade prolongada

1.1 Coleta inicial de evidência

Primeiro passo foi capturar estado do serviço e erro bruto no journal:

systemctl status bind9 --no-pager
journalctl -u bind9 -n 100 --no-pager

Em distros com unidade named:

systemctl status named --no-pager
journalctl -u named -n 100 --no-pager

O log apontava erro de parser em arquivo de configuração na linha do bloco ACL/allow-recursion.

1.2 Validação estática obrigatória antes de reload

Para não aplicar configuração quebrada em produção, executei validação sintática completa:

named-checkconf /etc/bind/named.conf

Esse comando foi determinante porque retornou a linha exata com missing ';' before 'deny'.

1.3 Correção efetiva

A causa foi ausência de ; em entrada dentro de bloco. Exemplo de padrão incorreto:

allow-recursion {
    127.0.0.1
    deny all;
};

Correção aplicada:

allow-recursion {
    127.0.0.1;
    deny all;
};

1.4 Hardening aplicado no mesmo ciclo

Aproveitei a intervenção para consolidar política de consulta/recursão:

acl "trusted" {
    127.0.0.1;
    192.168.0.0/24;
};

options {
    directory "/var/cache/bind";

    allow-query { any; };
    allow-recursion { trusted; };

    dnssec-validation auto;
    listen-on-v6 { any; };
};

Observação operacional: em DNS autoritativo puro, recursão deve ficar estritamente limitada ou desabilitada conforme arquitetura.

1.5 Reload seguro e validação pós-mudança

Em vez de restart, apliquei recarga para preservar disponibilidade:

rndc reload
# ou
systemctl reload bind9

Validação final de serviço e resposta:

systemctl is-active bind9
rndc status

# Teste funcional de resolução
dig @127.0.0.1 example.com A +short
dig @127.0.0.1 example.com NS +short

1.6 Validação de zonas (controle de qualidade)

Antes de encerrar janela, executei validação das zonas críticas:

named-checkzone domain.local /etc/bind/zones/domain.local.db
named-checkzone domain2.local /etc/bind/zones/domain2.local.db

Com isso, evitei correção parcial que resolve parser do named.conf, mas deixa zona inválida.

2) WHMCS cron: redução de concorrência e ganho de estabilidade

Após estabilizar DNS, o segundo ponto foi o agendamento da cron do WHMCS. O servidor estava com execução a cada minuto, o que estava gerando sobreposição de tarefas e aumento de load sem benefício real.

2.1 Estado anterior

* * * * * php -q /home/usuario/whmcs/crons/cron.php

Efeitos observados:

2.2 Ajuste aplicado (alta performance operacional)

Padronizei para janela de 5 minutos com caminho absoluto de PHP:

*/5 * * * * /usr/local/bin/php -q /home/usuario/whmcs/crons/cron.php

2.3 Prevenção de overlap com lock (prática SRE)

Para ambientes mais carregados, mantive recomendação com flock para impedir execução concorrente:

*/5 * * * * /usr/bin/flock -n /tmp/whmcs-cron.lock /usr/local/bin/php -q /home/usuario/whmcs/crons/cron.php

2.4 Validação operacional no WHMCS

No painel admin validei:

Admin -> System Health Status

Critérios de aceite:

Conferência no host:

crontab -l
pgrep -af "whmcs/crons/cron.php"

3) Integração eNom: API segura e fluxo de registro automático

Terceiro ponto foi revisar o pipeline de registro de domínios com eNom para garantir provisionamento consistente.

3.1 Ativação do módulo

No WHMCS:

Configuração -> Produtos/Serviços -> Registradores de Domínio -> eNom

Configurações aplicadas:

3.2 Whitelist de IP (etapa crítica)

Sem liberação do IP de saída do servidor no painel eNom, chamadas API falham por autenticação/ACL, mesmo com credenciais corretas.

Validei IP de saída do host e conferi whitelist no registrador antes dos testes de criação.

3.3 Definição como registrador padrão

No WHMCS:

Configuração -> Domínios -> Registrador Padrão -> eNom

Isso garante roteamento automático de novos pedidos para o mesmo fluxo.

3.4 Teste ponta a ponta executado

Fluxo validado:

  1. criação do pedido de domínio de teste
  2. confirmação de pagamento
  3. disparo do módulo registrador
  4. registro via API eNom
  5. validação de estado no WHMCS e no registrador
  6. validação de resolução DNS no BIND9

Comandos de checagem usados no pós-provisionamento:

dig domain-teste.local NS +short
dig domain-teste.local A +short

4) Lições técnicas consolidadas

  1. Erro de sintaxe de 1 caractere em BIND pode interromper resolução de zonas inteiras.
  2. named-checkconf e named-checkzone são gates obrigatórios antes de qualquer reload.
  3. Cron WHMCS a cada 1 minuto pode degradar performance por overlap; 5 minutos tende a ser o ponto de equilíbrio operacional.
  4. Integração de registrador exige credencial + whitelist de IP + ambiente correto; faltar qualquer um quebra automação.
  5. Correção profissional não encerra no “serviço voltou”: precisa validação de ponta a ponta com evidência.

5) Resultado operacional

Após os ajustes:

Esse cenário reforça um ponto central de operação em produção: estabilidade não vem só de ferramenta, vem de método, validação e disciplina de execução.

CC BY-NC

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.