Por que o Bind9 falha silenciosamente no Debian 12 e como corrigir

16 min de leitura  ·  Guia técnico

Bind9 falhando silenciosamente no Debian 12 ocorre quando o daemon named para de responder a consultas DNS sem registrar erros visíveis no log padrão, geralmente por esgotamento de descritores de arquivo, limite de memória do processo ou erro de sintaxe em zona carregada tardiamente. Para diagnosticar e corrigir o problema, siga estes passos:

1. Verificar o status real do serviço com systemctl status named e journalctl -u named
2. Testar resolução local com dig @127.0.0.1 google.com e confirmar porta 53 com ss -ulnp | grep 53
3. Validar configuração com named-checkconf e arquivos de zona com named-checkzone
4. Aumentar o nível de log no named.conf para expor erros silenciosos
5. Ajustar o limite de descritores de arquivo via override do systemd
6. Reiniciar o serviço e confirmar resolução estável

Pré-requisitos para corrigir o Bind9 no Debian 12

• Sistema operacional: Debian 12 (Bookworm) com acesso root ou sudo
• Bind9 instalado: pacote bind9 versão 9.18.x (padrão do Debian 12)
• Acesso SSH: terminal com permissão para editar arquivos em /etc/bind/ e /etc/systemd/
• Ferramentas de diagnóstico: dig (pacote dnsutils), ss e journalctl disponíveis
• Editor de texto: nano ou vim para editar arquivos de configuração

Por que o Bind9 falha silenciosamente no Debian 12

O comportamento silencioso do Bind9 no Debian 12 está diretamente ligado à forma como o daemon named gerencia recursos internos e ao nível de verbosidade padrão do log. Por padrão, o Bind9 registra apenas eventos críticos no canal default_syslog, o que significa que erros de carregamento de zona, esgotamento de descritores e falhas de memória podem ocorrer sem nenhuma entrada visível no journalctl.

As três causas mais comuns de falha silenciosa são:

• Esgotamento de descritores de arquivo: O Debian 12 com systemd define por padrão LimitNOFILE=1024 para serviços legados. Em servidores com muitas zonas ou alto volume de consultas, o processo named atinge esse limite e para de aceitar novas conexões sem registrar o motivo.
• Erro de sintaxe em arquivo de zona carregado tardiamente: O Bind9 valida a sintaxe do named.conf na inicialização, mas carrega os arquivos de zona em segundo plano. Um erro em uma zona secundária pode fazer o daemon parar de responder para aquele domínio sem reiniciar o processo principal.
• Limite de memória do processo named: Em VPS com pouca RAM, o kernel pode enviar SIGKILL ao processo named via OOM Killer sem que o Bind9 tenha tempo de registrar o evento. O serviço aparece como inativo, mas o log do Bind9 não mostra nada.

Para confirmar qual causa está afetando seu servidor, execute a sequência de diagnóstico descrita nas seções seguintes. Se você está configurando um servidor DNS do zero, consulte também o artigo Configurando um Servidor Linux para Hospedagem de Sites para entender a arquitetura completa de serviços.

Diagnóstico completo do Bind9 com falha silenciosa

O diagnóstico de resolução DNS com falha silenciosa exige verificar camadas distintas: status do processo, porta de escuta, logs do sistema e integridade dos arquivos de configuração.

Passo 1: verificar o status do daemon named

Execute o comando abaixo para ver o estado atual do serviço e as últimas linhas de log do systemd:

systemctl status named

Output esperado (serviço ativo):
● named.service - BIND Domain Name Server
     Loaded: loaded (/lib/systemd/system/named.service; enabled)
     Active: active (running) since Mon 2024-03-11 14:22:10 UTC; 2h 15min ago
   Main PID: 1234 (named)
      Tasks: 6 (limit: 4915)
     Memory: 48.2M

Se o status mostrar failed ou inactive (dead), verifique o log completo com:

journalctl -u named --since "1 hour ago" --no-pager

Passo 2: testar resolução DNS local

Mesmo com o serviço aparentemente ativo, o Bind9 pode não estar processando consultas. Teste diretamente na interface de loopback:

dig @127.0.0.1 google.com

Output esperado (funcionando):
;; ANSWER SECTION:
google.com.             300     IN      A       142.250.x.x

;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

Se retornar connection timed out; no servers could be reached ou SERVFAIL, o daemon não está processando consultas mesmo que o processo exista.

Passo 3: confirmar que a porta 53 está em escuta

ss -ulnp | grep 53

Output esperado:
UNCONN 0      0            0.0.0.0:53         0.0.0.0:*    users:(("named",pid=1234,fd=20))

Se a porta 53 não aparecer, o processo named iniciou mas não conseguiu fazer o bind na porta, geralmente por conflito com outro serviço como systemd-resolved.

Passo 4: verificar conflito com systemd-resolved no Debian 12

O Debian 12 pode ter o systemd-resolved ocupando a porta 53 em 127.0.0.53. Verifique:

ss -ulnp | grep :53

Se aparecer systemd-resolve na porta 53, desative o stub listener:

nano /etc/systemd/resolved.conf

Adicione ou altere a linha:

DNSStubListener=no

Em seguida, reinicie o serviço:

systemctl restart systemd-resolved
systemctl restart named

Validando arquivos de configuração do Bind9 antes de reiniciar

A validação de sintaxe do named.conf é a etapa mais ignorada por administradores que enfrentam falhas silenciosas. O Bind9 no Debian 12 separa a validação do arquivo principal da validação dos arquivos de zona, e ambos devem ser verificados independentemente.

Usando named-checkconf para validar o named.conf

O named-checkconf lê o arquivo principal e todos os include referenciados, verificando sintaxe e diretivas inválidas:

named-checkconf /etc/bind/named.conf

Output esperado (sem erros):
(nenhuma saída — silêncio indica sucesso)

Se houver erro, a saída será similar a:

/etc/bind/named.conf.local:12: missing ';' before '}'

Usando named-checkzone para validar arquivos de zona

Para cada zona configurada, execute o named-checkzone informando o nome da zona e o caminho do arquivo:

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

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

Erros comuns detectados pelo named-checkzone incluem serial desatualizado, registros NS sem ponto final e registros A com endereço IP inválido. Corrija cada erro antes de reiniciar o serviço.

Aumentando o nível de log do Bind9 para expor erros ocultos

A configuração de logging detalhado no named.conf é essencial para transformar falhas silenciosas em mensagens diagnósticas acionáveis. Adicione o bloco abaixo ao seu /etc/bind/named.conf.options:

logging {
    channel default_log {
        file "/var/log/named/named.log" versions 3 size 5m;
        severity dynamic;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    channel query_log {
        file "/var/log/named/query.log" versions 3 size 10m;
        severity info;
        print-time yes;
    };
    category default { default_log; };
    category queries { query_log; };
    category lame-servers { null; };
};

Crie o diretório de log e ajuste as permissões:

mkdir -p /var/log/named
chown bind:bind /var/log/named
chmod 750 /var/log/named

Após reiniciar o Bind9, monitore o log em tempo real:

tail -f /var/log/named/named.log

Corrigindo o limite de descritores de arquivo para o Bind9 no Debian 12

O ajuste de descritores de arquivo via systemd é a correção mais efetiva para servidores DNS com alto volume de zonas ou consultas simultâneas. O limite padrão pode ser insuficiente para ambientes de produção.

Atenção: editar arquivos de serviço do systemd incorretamente pode impedir o Bind9 de iniciar. Use sempre o diretório de override em vez de editar o arquivo de serviço original.

Crie o diretório de override e o arquivo de configuração:

mkdir -p /etc/systemd/system/named.service.d/
nano /etc/systemd/system/named.service.d/override.conf

Adicione o seguinte conteúdo:

[Service]
LimitNOFILE=65536

Recarregue o systemd e reinicie o Bind9:

systemctl daemon-reload
systemctl restart named

Confirme que o novo limite foi aplicado ao processo:

cat /proc/$(pidof named)/limits | grep "open files"

Output esperado:
Max open files            65536                65536                files

Para servidores com muitas zonas DNS, considere também verificar as Dicas de Otimização de Servidores Linux para ajustes complementares no kernel.

Verificando o OOM Killer como causa de parada silenciosa

O OOM Killer do Linux encerra processos sem aviso quando a memória RAM está esgotada. Em VPS com pouca memória, o processo named é frequentemente alvo. Verifique se o kernel matou o processo:

dmesg | grep -i "oom\|killed process" | tail -20

Output indicando problema:
[123456.789] Out of memory: Kill process 1234 (named) score 450 or sacrifice child
[123456.790] Killed process 1234 (named) total-vm:256000kB, anon-rss:48000kB

Se o OOM Killer estiver matando o named, as soluções são:

• Aumentar a RAM do VPS: solução definitiva para servidores DNS autoritativos com muitas zonas
• Reduzir o cache do Bind9: adicione max-cache-size 64m; no bloco options do named.conf.options
• Proteger o processo com oom_score_adj: adicione OOMScoreAdjust=-500 no arquivo de override do systemd

Problemas comuns e como resolver

Sintoma: Bind9 inicia mas para em menos de 30 segundos

Causa: Erro de sintaxe em arquivo de zona que o Bind9 detecta apenas durante o carregamento completo das zonas, após a inicialização imediata do processo. O systemctl status named pode mostrar o serviço como ativo por alguns segundos antes de falhar.
Solução: Execute named-checkconf -z /etc/bind/named.conf (com a flag -z para incluir verificação de zonas) e corrija todos os erros reportados antes de reiniciar. Verifique também o journalctl -u named -b para ver o log completo do boot atual.

Sintoma: Bind9 responde para alguns domínios mas não para outros

Causa: Arquivo de zona específico com erro de sintaxe ou serial inválido. O Bind9 carrega as zonas válidas e ignora silenciosamente as zonas com erro, dependendo da configuração de check-names.
Solução: Execute named-checkzone para cada zona suspeita. Verifique se o serial do registro SOA está no formato YYYYMMDDNN e se todos os registros NS têm ponto final no hostname (ex: ns1.exemplo.com.br. com ponto).

Sintoma: dig retorna SERVFAIL para consultas recursivas

Causa: A recursão está desabilitada no named.conf.options ou a ACL allow-recursion não inclui o endereço do cliente. No Debian 12, a configuração padrão do Bind9 desabilita recursão para endereços externos por segurança.
Solução: Verifique o bloco options no named.conf.options. Para um resolver interno, adicione recursion yes; e allow-recursion { 127.0.0.1; 192.168.0.0/16; }; com os ranges da sua rede. Para um servidor autoritativo, mantenha recursion no;.

Sintoma: porta 53 não aparece no ss mesmo com named rodando

Causa: O systemd-resolved está ocupando a porta 53 em 127.0.0.53 e o Bind9 não consegue fazer bind. Isso é comum em instalações novas do Debian 12 onde o systemd-resolved está habilitado por padrão.
Solução: Desative o stub listener do systemd-resolved editando /etc/systemd/resolved.conf e definindo DNSStubListener=no. Reinicie ambos os serviços na ordem: primeiro systemd-resolved, depois named.

Sintoma: named.log não é criado mesmo após configurar o bloco logging

Causa: O diretório /var/log/named/ não existe ou pertence ao usuário errado. O processo named no Debian 12 roda como usuário bind e não tem permissão para criar diretórios.
Solução: Crie o diretório manualmente com mkdir -p /var/log/named e ajuste o dono com chown bind:bind /var/log/named. Se o AppArmor estiver ativo, verifique se o perfil do Bind9 permite escrita no caminho configurado com aa-status.

Perguntas frequentes sobre Bind9 no Debian 12

Por que o Bind9 para de responder sem mostrar erro no log?

O Bind9 pode parar de responder silenciosamente por esgotamento de descritores de arquivo, limite de memória atingido pelo processo named ou falha na leitura de zona sem entrada de log configurada. O nível de log padrão do Bind9 no Debian 12 registra apenas eventos críticos, deixando erros operacionais sem registro. Verificar o status com systemctl status named e aumentar o nível de log no named.conf com um bloco logging detalhado resolve a maioria dos casos de diagnóstico.

Como verificar se o Bind9 está realmente respondendo no Debian 12?

Execute dig @127.0.0.1 google.com para testar a resolução local diretamente no daemon. Se o comando retornar connection timed out ou SERVFAIL, o daemon named não está processando consultas mesmo que o processo apareça como ativo no systemd. Confirme também com ss -ulnp | grep 53 se a porta UDP 53 está em escuta e associada ao processo named.

O Bind9 reinicia mas para logo depois no Debian 12 — o que causa isso?

Esse comportamento geralmente indica erro de sintaxe em um arquivo de zona ou no named.conf que o Bind9 detecta apenas ao carregar as zonas, não na inicialização imediata do processo. Execute named-checkconf para validar o arquivo de configuração principal e named-checkzone nome.da.zona /etc/bind/db.arquivo para cada zona configurada. Corrija todos os erros reportados antes de tentar reiniciar o serviço novamente.

Como aumentar o limite de descritores de arquivo para o Bind9 no Debian 12?

Crie ou edite o arquivo /etc/systemd/system/named.service.d/override.conf adicionando LimitNOFILE=65536 na seção [Service]. Em seguida, execute systemctl daemon-reload e systemctl restart named para aplicar a mudança. Confirme que o limite foi aplicado ao processo em execução com cat /proc/$(pidof named)/limits | grep open, que deve mostrar o valor 65536.

Qual a diferença entre named-checkconf e named-checkzone no diagnóstico do Bind9?

O named-checkconf valida a sintaxe do arquivo de configuração principal named.conf e todos os arquivos incluídos via diretiva include, sem verificar o conteúdo dos arquivos de zona. Já o named-checkzone valida a sintaxe e a consistência de um arquivo de zona específico, incluindo registros SOA, NS, a contagem de serial e a presença de ponto final nos hostnames. Ambos devem ser executados antes de qualquer reinicialização do Bind9 para garantir que não há erros que causem falha silenciosa.

Conclusão

• Diagnostique em camadas: sempre verifique status do processo, porta 53, logs do systemd e integridade dos arquivos de zona nessa ordem antes de reiniciar o Bind9
• Configure logging detalhado: adicione um bloco logging explícito no named.conf.options para transformar falhas silenciosas em mensagens diagnósticas acionáveis
• Ajuste limites do systemd: use o arquivo de override em /etc/systemd/system/named.service.d/override.conf para aumentar LimitNOFILE e OOMScoreAdjust em servidores de produção

Leia também

• Solucionar erros de BIND9 no Debian 12: diagnóstico real
• Qual servidor DNS escolher para VPS Linux: comparativo direto
• Solucionar falhas do Postfix não enviando emails no Debian 12

Precisa de ajuda com DNS e Bind9 no seu servidor?

Configurar e manter um servidor DNS autoritativo com Bind9 exige atenção a detalhes de configuração que podem causar falhas difíceis de diagnosticar. Um VPS Linux com recursos adequados e suporte especializado faz diferença na estabilidade do seu ambiente DNS.

Conheça os planos de VPS da AviraHost e hospede seu servidor Bind9 com estabilidade