Alterando SOA padrão no HestiaCP com controle de impacto em cache DNS

Quando o negative caching TTL do SOA está muito baixo, o autoritativo recebe consultas repetidas para respostas NXDOMAIN, aumentando carga sem ganho real. No HestiaCP, o padrão costuma vir agressivo para cenários de produção com volume. Neste artigo, descrevo como trato esse ajuste de forma controlada.

Contexto técnico do SOA

No registro SOA, o último campo define o tempo de cache para respostas negativas (quando o registro não existe). Esse valor impacta diretamente:

1. frequência de requisições repetidas no Bind;
2. latência percebida em resoluções inexistentes;
3. carga do autoritativo em ambiente com alto volume.

Valor padrão observado no painel

No meu ambiente Hestia, o template gerava valor baixo (180).

Exemplo:

$TTL 14400
@ IN SOA ns1.exemplo.com. admin.exemplo.com. (
  2025030101
  7200
  3600
  1209600
  180 )

Estratégia de ajuste

Eu não altero direto em produção sem medir. O fluxo que aplico:

1. capturar zonas atuais;
2. ajustar template para novas zonas;
3. validar criação de zona piloto;
4. aplicar alteração gradual no parque existente.

Ajuste no script do Hestia (template de novas zonas)

cp /usr/local/hestia/func/domain.sh /usr/local/hestia/func/domain.sh.bak.$(date +%F-%H%M)
sed -i 's/ 180 )/ 1800 )/g' /usr/local/hestia/func/domain.sh

Observação: esse ajuste afeta geração futura. Zonas já existentes não mudam automaticamente.

Aplicação em zonas existentes

Para cada zona, eu reviso com named-checkzone após edição.

named-checkzone exemplo.com.br /home/admin/conf/dns/exemplo.com.br.db

Se ok, recarrego Bind sem restart completo:

rndc reload

Validação operacional

1. consultar SOA atualizado:

dig +noall +answer SOA exemplo.com.br

1. validar serial incrementado;
2. confirmar resposta do autoritativo sem erro de sintaxe.

Risco de update do Hestia sobrescrever ajuste

Atualizações do painel podem regravar domain.sh. Por isso mantenho:

• backup datado;
• diff do arquivo customizado;
• tarefa de pós-update para reaplicar patch se necessário.

Exemplo de verificação rápida pós-update:

grep -n '1800' /usr/local/hestia/func/domain.sh || echo 'ajuste ausente'

Estratégia de rollback e governança

Se o ajuste gerar efeito colateral em algum tenant sensível, aplico rollback imediato no template:

cp /usr/local/hestia/func/domain.sh.bak.YYYY-MM-DD-HHMM /usr/local/hestia/func/domain.sh

Depois, reviso somente as zonas impactadas, mantendo serial consistente e recarregando via rndc reload.

Também deixo regra operacional documentada:

1. toda alteração em template DNS precisa de ticket/change;
2. validação de zona obrigatória com named-checkzone;
3. recarga sem restart total;
4. evidência de dig SOA anexada no fechamento.

Conclusão

Ajustar SOA no HestiaCP é simples tecnicamente, mas precisa de método para não virar despadronização silenciosa. Com backup, validação named-checkzone e controle pós-update, o ajuste reduz carga recorrente no DNS e mantém operação estável.

Este post está licenciado sob CC BY-NC.