Como liberar novos servidores no cluster de DNS do HestiaCP

O gerenciamento de clusters DNS de alta disponibilidade é um requisito primordial em infraestruturas resilientes de hospedagem. No ecossistema HestiaCP, cada novo servidor configurado com o servidor DNS BIND9 pode atuar como nó primário (Master) ou secundário (Slave). As atualizações aplicadas em um servidor principal devem ser replicadas de forma ágil e segura para os servidores secundários do cluster (ns01 e ns02); a integridade dos dados e a resposta rápida a consultas públicas de DNS dependem dessa replicação.

Neste guia técnico detalhado, documento o procedimento passo a passo para integrar e liberar novos servidores em seu cluster de DNS gerenciado pelo HestiaCP, cobrindo a liberação de regras de API no painel, ajustes essenciais de segurança no arquivo de opções do BIND (named.conf.options), configuração de segurança de rede e comandos CLI necessários para registrar, sincronizar e testar o tráfego de zonas DNS.

1. Topologia e fluxo operacional do cluster#

Cada novo servidor integrado ao cluster do HestiaCP atua como o servidor primário (Master) para as zonas criadas sob a sua gestão. Nele, todas as edições iniciais de zonas ocorrem de forma centralizada. Posteriormente, o painel do HestiaCP coordena a transferência de zonas DNS via protocolo AXFR (dig @servidor AXFR) utilizando a API do painel para disparar a sincronização assíncrona com os servidores de nomes secundários (ns01 e ns02).

Esse fluxo de replicação em tempo real funciona de acordo com as seguintes rotas de sincronização:

1. Alteração via integração externa (ex: Integração API / WHMCS):

   WHMCS -> API -> Servidor Master -> NS01/NS02 (sincronização em tempo real)

1. Alteração direta na interface web do HestiaCP:

   Servidor Master -> NS01/NS02 (sincronização em tempo real)

A propagação das zonas ocorre apenas nos servidores secundários configurados, mantendo os dados consolidados nos servidores DNS autoritativos públicos.

2. Requisitos e pré-requisitos do cluster#

Para prosseguir com a liberação de um novo servidor no sistema de cluster de DNS do HestiaCP, certifique-se de possuir as seguintes informações e credenciais:

• Endereços de IP Internos: O mapeamento dos IPs da rede interna dos servidores (essencial para que o tráfego de API e as consultas do BIND fiquem restritos à rede privada).
• Usuário da API: Para fins de sincronização de cluster, o HestiaCP utiliza o usuário administrador padrão (admin) ou chaves de API restritas.
• Segurança de Autenticação (HTTPS): Certifique-se de que a comunicação da API ocorra estritamente sob conexões seguras HTTPS (Porta 8083). Se o seu servidor secundário não possuir um certificado SSL válido para o hostname do painel, configure-o previamente:

  v-add-letsencrypt-host admin seu-hostname-vps

• Auditoria do Usuário dns-cluster no Slave: O HestiaCP armazena e isola as zonas replicadas sob o usuário especial dns-cluster nos servidores secundários. Antes de cadastrar o nó remetente, verifique se esse usuário existe no servidor Slave (ns01/ns02):

  # Verificar se o usuário existe no servidor secundário
  sudo /usr/local/hestia/bin/v-list-user dns-cluster
  
  # Caso não exista, crie-o
  sudo /usr/local/hestia/bin/v-add-user dns-cluster 'SENHA_FORTE_AQUI'
  sudo /usr/local/hestia/bin/v-add-user-dns-cluster dns-cluster

3. Autorizando o acesso à API do HestiaCP#

Para que a sincronização ocorra sem erros de autorização de rede, os endereços IP dos servidores de destino (ns01 e ns02) devem ser expressamente permitidos na lista branca (whitelist) de chamadas de API do novo servidor Master, e vice-versa.

Passo 1: Liberar o novo servidor nos nós secundários (ns01/ns02)#

1. Acesse o painel de controle do HestiaCP na porta 8083 de cada servidor DNS secundário utilizando a conta admin via HTTPS.
2. No menu superior direito, clique em Server Settings (Configurações do Servidor) e depois em Configure (Configurar).
3. Selecione a aba Security (Segurança) -> System (Sistema) -> API.
4. Localize o campo Allowed IP addresses for API (Endereços de IP autorizados para API).
5. Adicione uma nova linha contendo o IP interno do novo servidor Master.
6. Salve a configuração.

Passo 2: Configurar a whitelist de API no novo servidor master#

No painel do novo servidor que está sendo adicionado à infraestrutura, execute o mesmo caminho para permitir a entrada de conexões das APIs dos nós secundários.

1. Acesse o painel HestiaCP do novo servidor (https://seu-vps:8083).
2. Navegue até Server Settings >> Configure >> Security >> System >> API.
3. No campo Allowed IP addresses for API, insira os endereços IP autorizados. Certifique-se de adicionar o IP local e os IPs dos nós secundários:

• 127.0.0.1 (Loopback local)
• 172.16.45.5 (IP Interno do NS01)
• 172.16.45.6 (IP Interno do NS02)

1. Clique em Save (Salvar) para persistir as alterações.

4. Otimização e segurança do BIND9 (named.conf.options / named.conf)#

Para autorizar a transferência segura de zonas (AXFR) do novo Master para os nós secundários (ns01 e ns02), você deve editar o arquivo de configuração de opções do daemon BIND.

Passo 0: Backup obrigatório#

Antes de alterar as configurações do BIND, crie cópias de segurança de seus arquivos de configuração para rápida recuperação em caso de erros de inicialização:

Debian/Ubuntu:

# Backup com carimbo de data/hora do arquivo de opções
sudo cp /etc/bind/named.conf.options /etc/bind/named.conf.options.backup.$(date +%Y%m%d-%H%M%S)

# Backup completo do diretório de configurações do BIND
sudo tar czf /root/bind-backup-$(date +%Y%m%d).tar.gz /etc/bind/

RHEL/Rocky Linux/AlmaLinux:

# Backup com carimbo de data/hora do arquivo principal
sudo cp /etc/named.conf /etc/named.conf.backup.$(date +%Y%m%d-%H%M%S)

Passo 1: Edição da configuração#

Abra o arquivo apropriado no servidor Master utilizando o seu editor de texto:

Debian/Ubuntu:

sudo nano /etc/bind/named.conf.options

RHEL/Rocky/AlmaLinux:

sudo nano /etc/named.conf

Substitua ou configure o bloco options conforme a estrutura abaixo:

options {
        directory "/var/cache/bind"; // No RHEL/Rocky usar "/var/named"
        
        dnssec-validation auto;
        auth-nxdomain no;

        // Limita a recursão apenas para a interface localhost (evita open resolver)
        allow-recursion { 127.0.0.1; };

        // Permite a transferência de zonas (AXFR) exclusivamente para o NS01 e NS02
        allow-transfer { 172.16.45.5; 172.16.45.6; };

        // Notifica os servidores secundários sobre as atualizações das zonas
        allow-notify { 172.16.45.5; 172.16.45.6; };
        also-notify { 172.16.45.5; 172.16.45.6; };

        hostname none;
        server-id none;
        version none;
};

Passo 2: Validação de sintaxe e reinicialização#

Após salvar o arquivo, valide as alterações sintáticas usando o utilitário named-checkconf antes de reiniciar o serviço:

# Validar no Debian/Ubuntu (se não houver retorno, a sintaxe está correta)
sudo named-checkconf /etc/bind/named.conf.options

# Validar no RHEL/Rocky Linux/AlmaLinux
sudo named-checkconf /etc/named.conf

Se houver algum erro de sintaxe, o terminal retornará a linha exata e a descrição do problema. Corrija o arquivo antes de prosseguir.

Se a validação retornar sucesso, reinicie o daemon de DNS correspondente:

# Reiniciar no Debian/Ubuntu
sudo systemctl restart bind9

# Reiniciar no RHEL/Rocky Linux/AlmaLinux
sudo systemctl restart named

Roteiro de rollback de emergência#

Se o serviço falhar em iniciar ou parar de responder:

Debian/Ubuntu:

# 1. Restaurar o arquivo de backup
sudo cp /etc/bind/named.conf.options.backup.* /etc/bind/named.conf.options

# 2. Validar sintaxe e reiniciar
sudo named-checkconf /etc/bind/named.conf.options
sudo systemctl restart bind9

RHEL/Rocky Linux/AlmaLinux:

# 1. Restaurar o arquivo de backup
sudo cp /etc/named.conf.backup.* /etc/named.conf

# 2. Validar sintaxe e reiniciar
sudo named-checkconf /etc/named.conf
sudo systemctl restart named

5. Liberação de firewall para transferência de zonas (AXFR)#

O tráfego de consultas de resolução de DNS convencional utiliza a porta UDP 53. No entanto, as transferências de zona completas (AXFR) utilizadas na replicação de servidores primários para secundários utilizam a porta TCP 53. É obrigatório liberar as conexões na porta TCP 53 especificamente entre os IPs dos nós do cluster.

Configuração via UFW (Debian/Ubuntu)#

# Permitir conexões de entrada TCP/UDP na porta 53 para os IPs do cluster
sudo ufw allow from 172.16.45.5 to any port 53 proto tcp
sudo ufw allow from 172.16.45.6 to any port 53 proto tcp
sudo ufw reload

Configuração via iptables diretamente#

sudo iptables -A INPUT -p tcp -s 172.16.45.5 --dport 53 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 172.16.45.6 --dport 53 -j ACCEPT
# Salvar regras de forma persistente
sudo netfilter-persistent save || sudo sh -c 'iptables-save > /etc/iptables/rules.v4'

6. Cadastrando e sincronizando servidores remotos no HestiaCP#

Com a rede de APIs e o DNS BIND configurados, registre os nós no HestiaCP Master.

Cadastro seguro via variável de ambiente ou API key#

Considere gerar uma API Key no painel em Server Settings -> API -> Generate para maior isolamento e segurança de acessos.

Se utilizar a senha admin do servidor remoto, utilize variáveis de ambiente temporárias envelopadas por diretivas que desabilitam temporariamente o histórico de comandos do shell:

# 1. Desabilitar temporariamente a gravação do histórico de comandos do terminal
set +o history

# 2. Exportar a senha para o ambiente local
export NS_PASS="SENHA_NS01"

# 3. Registrar o nó NS01 apontando para o usuário isolado dns-cluster
sudo /usr/local/hestia/bin/v-add-remote-dns-host 172.16.45.5 8083 'admin' "$NS_PASS" 'api' 'dns-cluster'

# 4. Registrar o nó NS02
export NS_PASS="SENHA_NS02"
sudo /usr/local/hestia/bin/v-add-remote-dns-host 172.16.45.6 8083 'admin' "$NS_PASS" 'api' 'dns-cluster'

# 5. Limpar a senha da memória e reativar o histórico do terminal
unset NS_PASS
set -o history

Os hosts adicionados serão gravados no arquivo de configuração do cluster em dns-cluster.conf.

Sincronização manual imediata#

O HestiaCP realiza a sincronização automática das zonas periodicamente via cron a cada 1-5 minutos. Para sincronizar as zonas manualmente e testar a conexão de forma imediata, execute:

sudo /usr/local/hestia/bin/v-sync-dns-cluster

Para validar a integridade dos dados e confirmar se as zonas foram criadas no servidor secundário remoto, acesse o terminal do servidor DNS secundário e liste as zonas importadas para o usuário dns-cluster:

sudo /usr/local/hestia/bin/v-list-dns-domains dns-cluster

7. Depuração e resolução de problemas (troubleshooting)#

Logs do sistema para depuração#

Caso ocorram erros de replicação, consulte os logs detalhados nos caminhos abaixo:

• Logs de Eventos do BIND9: sudo tail -f /var/log/syslog | grep named (no RHEL, consulte messages)
• Logs do HestiaCP Master: sudo tail -f /usr/local/hestia/log/system.log (consulte system.log) e /usr/local/hestia/log/history.log (consulte history.log)
• Auditando Erros do Cluster: sudo grep "dns-cluster" /var/log/syslog (ou messages no RHEL)

Auditoria de zonas DNS com dig#

Para certificar que as zonas foram propagadas e respondem de forma autoritativa fora da rede privada, utilize ferramentas de diagnóstico como o dig.

A perfeita sincronização entre os nós é validada quando os números seriais dos registros SOA (Start of Authority) retornados no Master e nos Slaves são exatamente idênticos:

# Consultando o registro SOA no NS01
dig SOA +short @ns01.domain.com dev.domain.com
# Retorno: ns01.domain.com. root.dev.domain.com. 2024091201 7200 3600 1209600 180

# Consultando o registro SOA no NS02 (deve conter o mesmo serial)
dig SOA +short @ns02.domain.com dev.domain.com
# Retorno: ns01.domain.com. root.dev.domain.com. 2024091201 7200 3600 1209600 180

Se os seriais retornados divergirem (ex: 2024091201 no NS01 e 2024091202 no NS02), as zonas estão dessincronizadas. Force a execução manual ou consulte os logs do BIND por erros de transferência de zona.

8. Script de validação de integridade do cluster DNS#

Para auxiliar sysadmins na verificação rotineira do cluster, o script abaixo testa a conectividade ICMP, valida se a API do HestiaCP está respondendo via HTTPS nas portas configuradas, audita o status ativo do BIND9 e compara os números seriais das zonas entre os servidores para certificar a integridade do cluster:

#!/bin/bash
# validate_dns_cluster.sh - Valida integridade do cluster DNS no HestiaCP
# ⚠️ Deve ser executado com privilégios adequados

set -e

# Configurar IPs dos servidores da infraestrutura
MASTER_IP="172.16.45.4"
SLAVES=("172.16.45.5" "172.16.45.6")
DOMAIN="dev.domain.com"

# Cores para formatação de saída
GREEN='\033[0;32m'
RED='\033[0;31m'
YELLOW='\033[1;33m'
NC='\033[0m'

log() { echo -e "${GREEN}[OK]${NC} $1"; }
error() { echo -e "${RED}[FAIL]${NC} $1"; }
warn() { echo -e "${YELLOW}[WARN]${NC} $1"; }

echo "=== Testando conectividade de rede (Ping) ==="
for slave in "${SLAVES[@]}"; do
    if ping -c 1 -W 2 "$slave" &>/dev/null; then
        log "Slave $slave respondendo a pacotes ICMP"
    else
        error "Slave $slave inacessível via rede"
    fi
done

echo ""
echo "=== Testando API HestiaCP via HTTPS (Porta 8083) ==="
for slave in "${SLAVES[@]}"; do
    HTTP_CODE=$(curl -sk -o /dev/null -w "%{http_code}" "https://$slave:8083/")
    if [[ "$HTTP_CODE" == "200" || "$HTTP_CODE" == "401" ]]; then
        log "API em $slave ativa (HTTP $HTTP_CODE)"
    else
        error "API em $slave falhou (HTTP $HTTP_CODE)"
    fi
done

echo ""
echo "=== Verificando Sincronização de Números Seriais SOA ==="
MASTER_SERIAL=$(dig SOA +short @${MASTER_IP} "$DOMAIN" | awk '{print $3}')
if [[ -z "$MASTER_SERIAL" ]]; then
    error "Não foi possível obter o serial SOA do Master (${MASTER_IP})"
else
    log "Serial no Master: $MASTER_SERIAL"
    for slave in "${SLAVES[@]}"; do
        SLAVE_SERIAL=$(dig SOA +short @"$slave" "$DOMAIN" | awk '{print $3}')
        if [[ "$MASTER_SERIAL" == "$SLAVE_SERIAL" ]]; then
            log "Slave $slave sincronizado com sucesso ($SLAVE_SERIAL)"
        else
            warn "Slave $slave desatualizado! Master: $MASTER_SERIAL, Slave: $SLAVE_SERIAL"
        fi
    done
fi

echo ""
echo "=== Auditoria Concluída ==="

Veja também

Infraestrutura Como alterar o tempo de transferência de zonas DNS no 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.