Entenda o Bind9: 7 ajustes que evitam falhas de DNS

15 min de leitura  ·  Guia técnico

Bind9 é o servidor DNS de código aberto mais utilizado em ambientes Linux, responsável por resolver nomes de domínio, gerenciar zonas autoritativas e encaminhar consultas recursivas. Ajustes mal feitos — ou ausentes — no arquivo de configuração principal causam falhas silenciosas, consumo excessivo de memória e até brechas de segurança graves. Para aplicar os 7 ajustes que evitam as falhas mais comuns, siga esta sequência:

1. Validar a instalação e checar o estado do daemon com systemctl status named
2. Desativar recursão aberta no bloco options do named.conf
3. Definir max-cache-size para controlar o consumo de RAM
4. Configurar rate-limiting para bloquear amplificação de DNS
5. Habilitar DNSSEC nas zonas autoritativas
6. Ajustar TTL e parâmetros SOA para propagação confiável
7. Automatizar recarga de zonas com rndc reload sem downtime

Pré-requisitos para configurar o Bind9 corretamente

• Acesso root ou sudo ao servidor (Debian 12, Ubuntu 24.04 LTS ou AlmaLinux 9)
• Bind9 instalado — pacote bind9 no Debian/Ubuntu ou bind no AlmaLinux/Rocky Linux 9
• Editor de texto como nano ou vim disponível no sistema
• Porta 53 (UDP e TCP) liberada no firewall — verifique com ufw status ou firewall-cmd --list-all
• Conhecimento básico de registros DNS (A, AAAA, MX, NS, SOA, CNAME)
• Acesso ao artigo Como Configurar DNS Personalizado para Seu Domínio na AviraHost para referência de zonas

Ajuste 1: validar a configuração do Bind9 antes de qualquer mudança

O primeiro passo para evitar falhas de DNS com o Bind9 é nunca aplicar alterações sem validar a sintaxe. O utilitário named-checkconf analisa o arquivo principal e todos os includes referenciados, retornando erros de sintaxe com número de linha.

named-checkconf /etc/bind/named.conf

Output esperado (sem erros):
(nenhuma saída — retorno silencioso indica sucesso)

Para validar um arquivo de zona específico, use named-checkzone:

named-checkzone exemplo.com.br /etc/bind/db.exemplo.com.br

Output esperado:
zone exemplo.com.br/IN: loaded serial 2024061001
OK

Se o comando retornar erros como "unexpected end of input" ou "no SOA record", corrija antes de recarregar o serviço. Esse hábito evita que o daemon falhe silenciosamente ao iniciar após uma edição incorreta.

Ajuste 2: desativar recursão aberta no Bind9

Habilitar recursão sem restrição de origem transforma o servidor DNS em um amplificador de ataques DDoS — um dos erros mais críticos em servidores de hospedagem. O bloco options do named.conf deve restringir quem pode fazer consultas recursivas.

Abra o arquivo de configuração principal:

nano /etc/bind/named.conf.options

Localize ou adicione o bloco options com as seguintes diretivas:

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

    recursion no;

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

    dnssec-validation auto;

    listen-on { any; };
    listen-on-v6 { any; };
};

Se o servidor precisar oferecer recursão apenas para clientes internos (por exemplo, a rede do próprio datacenter), substitua none pelo bloco de IPs autorizados:

acl "clientes-internos" {
    127.0.0.1;
    10.0.0.0/8;
};

options {
    recursion yes;
    allow-recursion { clientes-internos; };
};

Atenção: nunca use allow-recursion { any; }; em servidores públicos. Isso permite que qualquer host na internet use seu servidor como relay DNS, consumindo banda e CPU.

Ajuste 3: limitar o cache de memória do Bind9

O consumo excessivo de RAM pelo Bind9 ocorre porque, por padrão, o cache recursivo cresce sem limite até esgotar a memória disponível. Definir max-cache-size é essencial em VPS com recursos limitados.

Adicione ao bloco options:

options {
    max-cache-size 256m;
    max-cache-ttl 86400;
    max-ncache-ttl 3600;
};

• max-cache-size 256m — limita o cache a 256 MB; ajuste conforme a RAM disponível (use 10–20% da RAM total como referência)
• max-cache-ttl 86400 — define o TTL máximo de entradas positivas no cache (24 horas)
• max-ncache-ttl 3600 — limita o tempo de cache de respostas negativas (NXDOMAIN) a 1 hora, evitando que falhas temporárias fiquem presas no cache

Após salvar, valide e recarregue:

named-checkconf && rndc reload

Output esperado:
server reload successful

Ajuste 4: ativar rate-limiting para bloquear amplificação de DNS

O mecanismo de Response Rate Limiting (RRL) do Bind9 reduz o impacto de ataques de amplificação ao limitar quantas respostas idênticas o servidor envia para o mesmo endereço IP em um intervalo de tempo. Esse ajuste de segurança é ignorado na maioria das instalações padrão.

Adicione o bloco rate-limit dentro de options:

options {
    rate-limit {
        responses-per-second 10;
        window 5;
        log-only no;
    };
};

• responses-per-second 10 — máximo de 10 respostas por segundo para o mesmo IP de origem
• window 5 — janela de observação de 5 segundos
• log-only no — aplica o limite de fato (mude para yes para testar sem bloquear)

Para monitorar se o RRL está atuando, verifique os logs do Bind9:

journalctl -u named --since "1 hour ago" | grep "rate limit"

Ajuste 5: configurar DNSSEC nas zonas autoritativas

O DNSSEC (DNS Security Extensions) adiciona assinaturas criptográficas aos registros DNS, impedindo ataques de envenenamento de cache. No Bind9 moderno (versão 9.16+), a configuração inline simplificou bastante o processo.

No arquivo de zona, habilite a assinatura automática:

zone "exemplo.com.br" {
    type master;
    file "/etc/bind/db.exemplo.com.br";
    dnssec-policy default;
    inline-signing yes;
};

A diretiva dnssec-policy default usa a política padrão da ISC, que gera e rotaciona as chaves automaticamente. Após recarregar, verifique se as chaves foram criadas:

ls /var/cache/bind/*.key 2>/dev/null || ls /etc/bind/*.key

Para confirmar que o DNSSEC está ativo na zona, consulte com dig:

dig +dnssec exemplo.com.br SOA @127.0.0.1

Output esperado (trecho):
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
exemplo.com.br.  3600  IN  SOA  ns1.exemplo.com.br. ...
exemplo.com.br.  3600  IN  RRSIG SOA 13 2 3600 ...

A presença do registro RRSIG confirma que a zona está sendo assinada corretamente.

Ajuste 6: otimizar TTL e parâmetros SOA para propagação confiável

Parâmetros SOA mal configurados causam propagação lenta, replicação inconsistente entre servidores secundários e resolução falha durante migrações. Entender cada campo do registro SOA é fundamental para administrar zonas DNS com confiabilidade.

Exemplo de registro SOA bem configurado:

$TTL 3600
@   IN  SOA  ns1.exemplo.com.br. admin.exemplo.com.br. (
        2024061001  ; Serial (formato YYYYMMDDNN)
        3600        ; Refresh — intervalo de verificação do secundário (1h)
        900         ; Retry — intervalo de nova tentativa em caso de falha (15min)
        604800      ; Expire — tempo máximo sem contato com o primário (7 dias)
        300         ; Negative TTL — cache de respostas NXDOMAIN (5min)
    )

• Serial: incremente sempre que editar a zona. O secundário só sincroniza quando o serial aumenta.
• Refresh baixo (3600s): secundários verificam atualizações a cada hora — adequado para zonas que mudam com frequência.
• Negative TTL 300s: respostas negativas ficam em cache por apenas 5 minutos, útil durante migrações onde registros ainda não existem.
• TTL global 3600: antes de uma migração, reduza para 300s com 24h de antecedência para acelerar a propagação.

Consulte também o artigo Como gerenciar um domínio para entender como os registros DNS se relacionam com o painel de controle do seu serviço.

Ajuste 7: recarregar zonas sem downtime com rndc

Reiniciar o daemon named completo para aplicar alterações em zonas é desnecessário e causa uma janela de indisponibilidade. O utilitário rndc (Remote Name Daemon Control) permite recarregar configurações e zonas de forma cirúrgica.

Para recarregar todas as zonas:

rndc reload

Output esperado:
server reload successful

Para recarregar apenas uma zona específica (mais rápido em servidores com muitas zonas):

rndc reload exemplo.com.br

Output esperado:
zone reload up-to-date

Para forçar a retransferência de uma zona secundária a partir do primário:

rndc retransfer exemplo.com.br

Outros comandos úteis do rndc:

• rndc status — exibe estatísticas do daemon (versão, zonas carregadas, uptime)
• rndc flush — limpa todo o cache DNS (use com cautela em produção)
• rndc dumpdb -cache — despeja o cache atual em /var/cache/bind/named_dump.db para análise
• rndc freeze exemplo.com.br — congela a zona para edição manual segura
• rndc thaw exemplo.com.br — descongela e recarrega após a edição

Atenção: o comando rndc flush apaga todo o cache recursivo imediatamente. Em servidores que atendem muitos clientes, isso pode causar aumento temporário de latência até o cache ser reconstruído.

Problemas comuns e como resolver

Sintoma: Bind9 não inicia após edição do named.conf

Causa: erro de sintaxe no arquivo de configuração — parêntese não fechado, ponto-e-vírgula ausente ou diretiva inválida para a versão instalada.
Solução: execute named-checkconf -p 2>&1 | head -30 para ver o erro com contexto. O flag -p imprime a configuração expandida, facilitando identificar a linha problemática. Corrija o erro apontado e tente iniciar novamente com systemctl start named.

Sintoma: resolução DNS lenta ou timeout intermitente

Causa: forwarders configurados com servidores lentos ou inacessíveis, ou ausência de forwarders com recursão habilitada forçando o Bind9 a consultar os root servers diretamente.
Solução: adicione forwarders confiáveis ao bloco options:

options {
    forwarders {
        1.1.1.1;
        8.8.8.8;
    };
    forward only;
};

Use forward only para que o Bind9 dependa exclusivamente dos forwarders, ou forward first para tentar os forwarders e cair para recursão direta em caso de falha.

Sintoma: erro "transfer failed" nos logs do servidor secundário

Causa: o servidor primário não permite transferência de zona (AXFR) para o IP do secundário. A diretiva allow-transfer está ausente ou incorreta.
Solução: no servidor primário, adicione ao bloco da zona:

zone "exemplo.com.br" {
    type master;
    file "/etc/bind/db.exemplo.com.br";
    allow-transfer { 203.0.113.10; };
};

Substitua 203.0.113.10 pelo IP real do servidor secundário. Recarregue com rndc reload e verifique os logs no secundário com journalctl -u named -f.

Sintoma: resposta SERVFAIL para domínios com DNSSEC

Causa: a validação DNSSEC está habilitada (dnssec-validation auto), mas a cadeia de confiança está quebrada — chaves expiradas, DS record ausente no registrador ou zona assinada incorretamente.
Solução: desative temporariamente a validação para confirmar o diagnóstico:

rndc validation off

Se a resolução voltar a funcionar, o problema é na cadeia DNSSEC. Verifique a validade das chaves com dig +dnssec +cd exemplo.com.br SOA e confirme se o registro DS está publicado no servidor do TLD. Reative a validação após corrigir: rndc validation on.

Perguntas frequentes sobre Bind9

O que é o Bind9 e para que ele serve?

Bind9 (Berkeley Internet Name Domain versão 9) é o servidor DNS mais utilizado em ambientes Linux. Ele resolve nomes de domínio em endereços IP, gerencia zonas autoritativas e pode atuar como resolver recursivo ou forwarder. É mantido pela ISC e amplamente usado em VPS, servidores dedicados e infraestruturas corporativas.

Como verificar se o Bind9 está funcionando corretamente?

Execute systemctl status named para checar o estado do daemon. Em seguida, use named-checkconf para validar o arquivo de configuração principal e named-checkzone nome.da.zona /etc/bind/db.zona para validar cada arquivo de zona. Se ambos retornarem sem erros, o serviço está operacional.

Por que o Bind9 consome muita memória no servidor?

O Bind9 carrega todas as zonas configuradas na memória RAM ao iniciar. Zonas muito grandes, cache recursivo sem limite definido e o parâmetro max-cache-size não configurado são as causas mais comuns. Definir max-cache-size no bloco options e desativar recursão quando não necessário reduz significativamente o consumo.

Qual a diferença entre zona autoritativa e resolver recursivo no Bind9?

Uma zona autoritativa significa que o Bind9 é a fonte oficial das respostas para aquele domínio, respondendo com dados locais. Um resolver recursivo consulta outros servidores DNS em nome do cliente até obter a resposta final. Em servidores de hospedagem, o Bind9 geralmente opera como autoritativo; habilitar recursão aberta é um risco de segurança grave.

Como recarregar zonas do Bind9 sem reiniciar o serviço?

Use o comando rndc reload para recarregar todas as zonas sem interromper o daemon. Para recarregar apenas uma zona específica, execute rndc reload nome.da.zona. Isso evita downtime e é a forma correta de aplicar alterações em arquivos de zona em produção.

Conclusão

• Valide sempre antes de aplicar: use named-checkconf e named-checkzone como etapa obrigatória antes de qualquer rndc reload — isso evita que erros de sintaxe derrubem o serviço DNS em produção.
• Segurança não é opcional: desativar recursão aberta e ativar rate-limiting são ajustes de minutos que eliminam vetores de ataque graves; DNSSEC adiciona uma camada de autenticidade que protege seus usuários de envenenamento de cache.
• Monitore ativamente: combine rndc status, journalctl -u named e consultas periódicas com dig para detectar anomalias antes que se tornem falhas visíveis para os usuários finais.

Leia também

• Qual servidor DNS escolher para VPS Linux: comparativo direto
• Solucionar erros de DNS no Bind9 no Rocky Linux 9
• Entenda o Controle de Processos no Linux: o que é, como funciona e exemplos práticos

Precisa de ajuda com DNS e infraestrutura de servidor?

Configurar e manter o Bind9 em produção exige atenção a detalhes que vão além da documentação básica — especialmente em ambientes com múltiplas zonas, DNSSEC ativo e alta disponibilidade. Um VPS Linux com recursos adequados e suporte técnico especializado faz diferença real na estabilidade do seu DNS.

Conheça os planos de VPS da AviraHost e monte sua infraestrutura DNS com desempenho e segurança