Como alterar o tempo de transferência de zonas DNS no HestiaCP

1. Introdução: o desafio da latência de sincronização DNS#

O gerenciamento e a sincronização ágil de zonas DNS são fundamentais em infraestruturas multi-servidor (clusters Master-Slave ou Master-Master) para garantir que alterações nos registros (como novos apontamentos de IPs ou atualizações de SPF/DKIM) propaguem-se rapidamente.

No HestiaCP, a replicação das configurações de DNS entre os servidores do cluster não ocorre de forma instantânea para todas as operações em background; ela é coordenada por uma tarefa do sistema (cron job). Se o administrador alterar um registro e o cron job estiver configurado com um intervalo longo, haverá uma janela de atraso em que os servidores secundários de nomes (NS) responderão com dados desatualizados.

Neste guia prático, documento como alterar o tempo de transferência de zonas no HestiaCP, tanto via interface gráfica quanto diretamente pelo shell Linux, detalhando o funcionamento interno desse fluxo, os mecanismos de transferência (AXFR/IXFR) e os recursos de notificação direta do BIND9.

2. O fluxo de sincronização do HestiaCP: o papel do v-update-sys-queue#

No ecossistema do HestiaCP, o painel abstrai a complexidade do sincronismo em lote. Toda vez que um domínio DNS é editado, a alteração não é empurrada imediatamente via rede para o servidor escravo pelo painel de controle; em vez disso, a tarefa é enfileirada na fila de sincronização do sistema.

Essa fila é processada periodicamente por um cron job executado no servidor Master que chama o script interno:

/usr/local/hestia/bin/v-update-sys-queue dns-cluster

Quando o cron é disparado, o HestiaCP lê a fila acumulada e, para cada domínio pendente, realiza a transferência de dados e dispara comandos remotos para os servidores secundários cadastrados, mantendo os registros idênticos em toda a topologia de rede.

3. Mecanismos de transferência: AXFR vs. IXFR#

Muitos sysadmins presumem erroneamente que o principal gargalo de performance em clusters DNS reside na frequência de execução do cron job. Na realidade, o principal fator limitante é o tipo de transferência de zona empregado pelo servidor de nomes (BIND9):

• AXFR (Authoritative Transfer): Representa a cópia completa do arquivo de zona DNS. Toda vez que o sincronismo ocorre, o servidor Master envia o arquivo inteiro com todos os registros (A, MX, TXT, CNAME, etc.) para o servidor Slave. Em clusters com centenas ou milhares de domínios, realizar transferências recorrentes via AXFR a cada minuto gera um overhead extremo de rede, consumo indevido de banda e processamento de CPU.
• IXFR (Incremental Zone Transfer): O servidor Master envia apenas as alterações ocorridas na zona em relação ao número de série (Serial) anterior (por exemplo, a adição de um único registro TXT). Isso reduz drasticamente o tamanho do payload transmitido e acelera o processamento de atualização no BIND9 secundário.

O HestiaCP e o BIND9 utilizam IXFR por padrão sempre que possível, mas a transferência completa (AXFR) é automaticamente acionada se o histórico de mudanças do banco de dados de zonas for perdido ou se o número de série da zona no Master for menor que o do Slave.

4. Otimização com DNS notify: push vs. polling (also-notify)#

Depender exclusivamente da execução do cron job do HestiaCP a cada 5 ou 3 minutos representa um modelo baseado em polling (onde o sistema verifica de tempos em tempos se há alterações). Para obter uma sincronização imediata (modelo push), você deve configurar e auditar as diretivas de notificação ativa do BIND9:

O protocolo DNS prevê o mecanismo DNS NOTIFY (RFC 1996). Quando uma zona é alterada no servidor Master, o daemon BIND9 envia imediatamente um pacote de notificação UDP especial na porta 53 para os servidores secundários cadastrados. O servidor secundário, ao receber a notificação, compara o número serial e inicia imediatamente uma transferência IXFR/AXFR sem esperar o tempo de atualização padrão (Refresh interval) definido no registro SOA.

Para configurar o disparo dessas notificações no Master para servidores secundários que não estão explicitamente listados nos registros NS da zona, edite as diretivas globais no arquivo de configuração named.conf.options:

// Configuração no /etc/bind/named.conf.options do Master
options {
    ...
    notify yes;
    also-notify { 198.51.100.2; 203.0.113.5; }; // IPs dos servidores secundários (Slaves)
};

5. Configurando controle de acesso e segurança (allow-transfer)#

Liberar transferências de zona de forma irrestrita é uma vulnerabilidade grave (exposição a ataques de Zone Transfer Reconnaissance). Um atacante com acesso ao AXFR de uma zona pode mapear todos os subdomínios, IPs internos e servidores ativos da empresa.

Portanto, configure rigidamente a diretiva allow-transfer para aceitar conexões apenas a partir dos IPs dos seus servidores secundários legítimos e de localhost para depuração interna:

// Configuração no /etc/bind/named.conf.options
options {
    ...
    allow-transfer { 127.0.0.1; 198.51.100.2; 203.0.113.5; };
};

Certifique-se também de que o firewall local (como iptables ou UFW) permita o tráfego bidirecional na porta 53 TCP/UDP entre os endereços IP dos nós de nomes do cluster, pois as notificações utilizam UDP, enquanto as transferências de zona AXFR/IXFR utilizam conexões TCP persistentes.

6. Segurança no dig AXFR: o risco de exposição de zonas#

O comando dig AXFR é o utilitário padrão empregado para validar se as transferências de zona estão funcionando:

dig @127.0.0.1 domain.com AXFR

7. Passo a passo: alterando o intervalo da cron pelo painel#

Se você optou por ajustar a periodicidade do processamento da fila de 5 para 3 minutos via interface administrativa do HestiaCP, execute estas etapas:

1. Acesse o painel do HestiaCP com o usuário administrador (admin).
2. No menu superior, clique no ícone de engrenagem para acessar as Configurações do Servidor e clique em Tarefas (ou navegue diretamente até a lista de Cron Jobs do usuário administrador).
3. Localize a linha contendo a tarefa associada ao comando:

v-update-sys-queue dns-cluster

1. Clique em Editar.
2. Modifique o campo Minuto de /5 para /3 (ou insira o formato cron customizado de acordo com o intervalo pretendido).
3. Clique em Salvar para aplicar e gerar as novas regras no crontab.

8. Passo a passo: alterando o intervalo da cron pelo terminal#

Para administradores de sistemas que operam via linha de comando no SSH, o arquivo que armazena os agendamentos de tarefas do usuário administrador fica localizado no caminho físico:

cron.conf

1. Abra o arquivo de configuração para edição com privilégios elevados:

   sudo nano /usr/local/hestia/data/users/admin/cron.conf

1. Localize a linha contendo a chamada dns-cluster. Ela estará declarada com esta estrutura:

   JOB='12' MIN='*/5' HOUR='*' DAY='*' MONTH='*' WDAY='*' CMD='sudo /usr/local/hestia/bin/v-update-sys-queue dns-cluster' SUSPENDED='no' TIME='15:53:34' DATE='2024-10-16'

1. Edite o parâmetro MIN='/5' alterando-o para MIN='/3'.
2. Salve o arquivo e saia do editor (no nano: Ctrl+O, Enter, Ctrl+X).

Nota técnica: A edição direta do arquivo cron.conf não regenera a tabela crontab do Linux automaticamente. Para aplicar as novas regras, execute sudo /usr/local/hestia/bin/v-rebuild-cron-jobs admin ou utilize o comando CLI nativo v-change-cron-job admin 12 '/3' '' '' '' '*'.

9. Depuração de erros de transferência nos logs do BIND9#

Se as alterações aplicadas na cron não resultarem na atualização das zonas nos servidores Slaves, investigue os logs do sistema localizados em syslog (sistemas baseados em Debian/Ubuntu) ou no diretório de logs dedicados do BIND9 em named:

Procure por mensagens de erro típicas de falha de conexão ou validação:

• transfer of 'domain.com/IN' from 198.51.100.1#53: failed connection refused: O firewall local ou de borda no servidor Master está bloqueando conexões TCP na porta 53 vindas do IP do Slave.
• transfer of 'domain.com/IN' from 198.51.100.1#53: failed to connect: timeout: O tráfego de rede na porta 53 TCP está bloqueado ou a rota de rede entre os servidores está indisponível.
• zone domain.com/IN: transfer refused: A diretiva allow-transfer no Master não incluiu o IP do servidor Slave correspondente ou a validação de chave TSIG falhou.

Conclusão: matriz de impacto e recomendações de performance#

A tabela abaixo consolida os custos de processamento, riscos de rede e configurações ideais de intervalo baseadas na dimensão do cluster DNS:

Veja também

Infraestrutura Como liberar novos servidores no cluster de DNS do HestiaCP

Infraestrutura Como criar e configurar templates de DNS no HestiaCP

Infraestrutura DirectAdmin: como recriar zonas DNS via CLI (o guia de sobrevivência)

Este post está licenciado sob CC BY-NC.