Solucionar erros de BIND9 no Debian 12: diagnóstico real

14 min de leitura  ·  Guia técnico

Erros de BIND9 no Debian 12 ocorrem quando arquivos de zona contêm sintaxe inválida, o daemon named perde permissões em diretórios críticos ou forwarders ficam inacessíveis. A maioria dos problemas pode ser diagnosticada antes de qualquer reinicialização usando as ferramentas named-checkconf e named-checkzone. Veja abaixo como identificar e corrigir cada categoria de falha com precisão.

Pré-requisitos para diagnosticar erros de BIND9 no Debian 12

• Debian 12 (Bookworm) com BIND9 instalado via apt install bind9 bind9utils bind9-doc
• Acesso root ou usuário com sudo configurado
• Pacote dnsutils instalado para usar dig e nslookup
• Acesso ao terminal via SSH — consulte como acessar servidores VPS Linux da AviraHost se precisar configurar o acesso
• Permissão para ler /var/log/syslog e os arquivos em /etc/bind/

Diagnóstico inicial: verificando o estado do BIND9 e os logs do sistema

O primeiro passo em qualquer diagnóstico de servidor DNS autoritativo é confirmar se o daemon está ativo e quais mensagens ele registrou. No Debian 12, o BIND9 roda como serviço named gerenciado pelo systemd.

1. Verifique o estado do serviço:

systemctl status named

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

2. Se o serviço estiver em estado failed ou inactive, leia as últimas 50 linhas do journal:

journalctl -u named -n 50 --no-pager

3. Filtre o syslog para mensagens do BIND9:

grep named /var/log/syslog | tail -30

Output típico de erro de zona:
Jun 10 14:20:01 srv named[1234]: zone example.com/IN: loading from master file /etc/bind/db.example.com failed: no owner
Jun 10 14:20:01 srv named[1234]: zone example.com/IN: not loaded due to errors.

Anote o nome da zona e o tipo de erro antes de avançar. Cada categoria de falha tem uma ferramenta de diagnóstico específica descrita nas seções seguintes.

Validando a configuração principal com named-checkconf

Antes de investigar arquivos de zona individuais, valide a configuração global do servidor DNS recursivo ou autoritativo. O utilitário named-checkconf analisa toda a árvore de includes do named.conf sem iniciar o daemon.

named-checkconf /etc/bind/named.conf

Output esperado (sem erros):
(nenhuma saída — retorno 0 indica configuração válida)

Se houver erro, a saída indica o arquivo e a linha exata:

Output com erro:
/etc/bind/named.conf.local:12: unknown option 'forwarder'

Erros comuns detectados pelo named-checkconf:

• Ponto e vírgula ausente ao final de uma diretiva options ou zone
• Chave de fechamento faltando em blocos acl ou view
• Opção desconhecida — geralmente causada por copiar configuração de versão diferente do BIND
• Arquivo de zona referenciado mas inexistente no caminho declarado

Após corrigir, execute novamente o named-checkconf até obter retorno limpo antes de tentar reiniciar o serviço.

Validando arquivos de zona com named-checkzone

O erro zone not loaded due to errors é o mais frequente em ambientes de DNS autoritativo e sempre aponta para um problema dentro do arquivo de zona. O utilitário named-checkzone analisa o arquivo sem carregar o daemon.

named-checkzone example.com /etc/bind/db.example.com

Output esperado (zona válida):
zone example.com/IN: loaded serial 2024061001
OK

Output com erro de sintaxe:
dns_master_load: /etc/bind/db.example.com:18: no owner
zone example.com/IN: loading from master file /etc/bind/db.example.com failed: no owner
zone example.com/IN: not loaded due to errors.

A linha 18 do arquivo de zona contém o problema. Abra o arquivo e inspecione:

nano /etc/bind/db.example.com

Estrutura mínima correta de um arquivo de zona para o domínio example.com:

$TTL 86400
@   IN  SOA ns1.example.com. admin.example.com. (
            2024061001  ; Serial
            3600        ; Refresh
            1800        ; Retry
            604800      ; Expire
            86400 )     ; Minimum TTL

@   IN  NS  ns1.example.com.
@   IN  NS  ns2.example.com.
@   IN  A   203.0.113.10
ns1 IN  A   203.0.113.10
ns2 IN  A   203.0.113.11
www IN  A   203.0.113.10
mail IN  A  203.0.113.12
@   IN  MX  10 mail.example.com.

Atenção: o número de série no campo SOA deve ser incrementado sempre que o arquivo de zona for modificado. Um número de série igual ou menor ao anterior impede que servidores secundários sincronizem a zona.

Pontos críticos a verificar manualmente:

• Todo nome de host totalmente qualificado (FQDN) deve terminar com ponto (.)
• Registros MX devem apontar para um nome de host, nunca diretamente para um IP
• O campo de e-mail no SOA usa ponto no lugar de @ (ex: admin.example.com.)
• Linhas em branco dentro do bloco SOA entre parênteses são permitidas, mas a indentação deve ser consistente

Recarregando zonas sem downtime com rndc

Em servidores que atendem múltiplos domínios, reiniciar o BIND9 inteiro para aplicar uma correção em uma única zona causa interrupção desnecessária. O utilitário rndc permite recarregar zonas individualmente ou toda a configuração sem derrubar o daemon.

Recarregar todas as zonas:

rndc reload

Output esperado:
server reload successful

Recarregar apenas uma zona específica:

rndc reload example.com

Output esperado:
zone reload up-to-date

Verificar o status de uma zona específica após o reload:

rndc zonestatus example.com

Output esperado:
name: example.com
type: primary
files: db.example.com
serial: 2024061001
nodes: 8
last loaded: Mon, 10 Jun 2024 14:22:01 GMT
secure: no
dynamic: no
reconfigurable via modzone: no

Se o rndc retornar rndc: connect failed: 127.0.0.1#953: connection refused, o canal de controle do BIND9 não está acessível. Verifique se o bloco controls está presente no named.conf e se o arquivo /etc/bind/rndc.key existe e tem permissões corretas.

Diagnosticando SERVFAIL e falhas de resolução

Quando o BIND9 retorna SERVFAIL para consultas, o problema pode estar em três categorias distintas: falha na zona autoritativa, forwarders inacessíveis ou DNSSEC mal configurado. Use o dig para reproduzir o erro localmente:

dig @127.0.0.1 example.com A +short

Output indicando SERVFAIL:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12345

Para identificar a causa, adicione o flag +dnssec e observe se o problema está relacionado a validação:

dig @127.0.0.1 example.com A +dnssec +cd

O flag +cd (checking disabled) desativa a validação DNSSEC temporariamente. Se a consulta retornar NOERROR com +cd mas SERVFAIL sem ele, o problema é DNSSEC.

Para verificar se forwarders estão acessíveis, teste diretamente:

dig @8.8.8.8 example.com A +short

Se o forwarder responder mas o BIND9 não, verifique o bloco forwarders no named.conf.options:

options {
    directory "/var/cache/bind";
    forwarders {
        8.8.8.8;
        8.8.4.4;
    };
    forward only;
    dnssec-validation auto;
    listen-on { any; };
};

Atenção: a diretiva forward only faz o BIND9 depender completamente dos forwarders. Se eles ficarem inacessíveis, todas as consultas falharão. Considere usar forward first para permitir resolução recursiva como fallback.

Para ambientes que gerenciam DNS junto com outros serviços de hospedagem, o artigo Configurando um Servidor Linux para Hospedagem de Sites oferece contexto adicional sobre a integração de serviços.

Problemas comuns e como resolver

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

Causa: Erro de sintaxe introduzido durante a edição — ponto e vírgula ausente, chave não fechada ou opção inválida para a versão do BIND9 instalada no Debian 12.
Solução: Execute named-checkconf /etc/bind/named.conf antes de tentar iniciar o serviço. Corrija cada erro reportado na ordem em que aparecem. Após a correção, use systemctl start named e confirme com systemctl status named.

Sintoma: zona carrega mas registros não são resolvidos externamente

Causa: O servidor está configurado como autoritativo para a zona, mas os registros NS nos servidores de domínio raiz ainda apontam para os nameservers antigos, ou o TTL do registro anterior ainda está em cache nos resolvers externos.
Solução: Confirme que os nameservers registrados no registrador de domínio apontam para o IP correto. Use dig NS example.com @8.8.8.8 para verificar o que os resolvers externos enxergam. Se o TTL ainda estiver em cache, aguarde a expiração ou reduza o TTL com antecedência antes de migrações. Consulte também como gerenciar um domínio para detalhes sobre propagação de DNS.

Sintoma: named ocupa memória crescente ao longo do tempo

Causa: Cache DNS acumulando entradas sem limite configurado, comum em servidores que atuam como resolvers recursivos para redes internas.
Solução: Defina um limite de cache no bloco options do named.conf.options:

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

Após aplicar, recarregue com rndc reload e monitore o consumo com rndc stats seguido de cat /var/cache/bind/named_stats.txt.

Sintoma: erro "permission denied" ao carregar arquivo de zona

Causa: O daemon named roda como usuário bind no Debian 12. Se os arquivos de zona foram criados ou copiados como root sem ajuste de permissões, o daemon não consegue lê-los.
Solução: Corrija o proprietário e as permissões dos arquivos de zona:

chown root:bind /etc/bind/db.example.com
chmod 640 /etc/bind/db.example.com

Verifique também o diretório /var/cache/bind:

ls -la /var/cache/bind

Output esperado:
drwxrwsr-x 2 root bind 4096 Jun 10 14:00 .

Sintoma: rndc retorna "connection refused" na porta 953

Causa: O canal de controle do BIND9 não está configurado ou o arquivo de chave rndc.key está ausente ou com permissões incorretas.
Solução: Gere uma nova chave e configure o canal de controle:

rndc-confgen -a -b 512

chown bind:bind /etc/bind/rndc.key
chmod 640 /etc/bind/rndc.key

Confirme que o named.conf contém o bloco:

include "/etc/bind/rndc.key";

controls {
    inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
};

Perguntas frequentes sobre erros de BIND9 no Debian 12

Como verificar se o BIND9 está rodando corretamente no Debian 12?

Execute systemctl status named para ver o estado do daemon. Se o serviço estiver ativo, confirme a resolução com dig @127.0.0.1 seudominio.com. Um retorno com status NOERROR indica que o BIND9 está respondendo corretamente às consultas DNS. Caso o status mostre falha, consulte o journal com journalctl -u named -n 50 para identificar a mensagem de erro específica.

O que causa o erro 'zone not loaded due to errors' no BIND9?

Esse erro ocorre quando o arquivo de zona contém sintaxe inválida, número de série desatualizado ou registros malformados. Execute named-checkzone seudominio.com /etc/bind/db.seudominio para identificar a linha exata do problema antes de reiniciar o serviço. Os erros mais comuns incluem FQDNs sem ponto final, registros MX apontando para IPs em vez de hostnames e blocos SOA com parênteses não fechados.

Como testar a sintaxe do named.conf sem reiniciar o BIND9?

Use o comando named-checkconf /etc/bind/named.conf para validar toda a configuração sem interromper o serviço. Se não houver saída, a sintaxe está correta. Qualquer linha de erro indica o arquivo e a linha exata que precisa de correção. Este utilitário também valida todos os arquivos incluídos via diretiva include, como named.conf.local e named.conf.options.

Por que o BIND9 responde SERVFAIL para algumas consultas?

SERVFAIL geralmente indica que o BIND9 não conseguiu resolver a consulta por falha na zona autoritativa, problema de encaminhamento (forwarders inacessíveis) ou DNSSEC inválido. Verifique os logs em /var/log/syslog com grep named /var/log/syslog para identificar a causa específica. Use dig @127.0.0.1 dominio.com +cd para testar com validação DNSSEC desabilitada e isolar se o problema é de validação ou de resolução.

É possível recarregar zonas do BIND9 sem reiniciar o serviço?

Sim. Use rndc reload para recarregar todas as zonas sem interromper o daemon, ou rndc reload seudominio.com para recarregar apenas uma zona específica. Isso evita downtime em servidores que atendem múltiplos domínios simultaneamente. Após o reload, confirme que a zona foi carregada com sucesso usando rndc zonestatus seudominio.com e verificando o número de serial atualizado.

Conclusão

• Sempre valide antes de reiniciar: use named-checkconf para a configuração global e named-checkzone para cada arquivo de zona modificado — isso evita downtime causado por erros de digitação.
• Use rndc para recargas cirúrgicas: em servidores com múltiplas zonas, rndc reload dominio.com aplica correções sem afetar outros domínios ativos no mesmo servidor.
• Monitore os logs continuamente: configure grep named /var/log/syslog como parte da rotina de verificação ou use journalctl -u named -f para acompanhar eventos em tempo real durante manutenções.

Leia também

• Solucionar falhas do Postfix não enviando emails no Debian 12
• Qual servidor DNS escolher para VPS Linux: comparativo direto
• Guia de zona DNS: registros A, MX, CNAME e TXT do zero

Precisa de ajuda com BIND9 e DNS no seu servidor?

Configurar e manter um servidor DNS autoritativo exige atenção a detalhes de sintaxe e permissões que podem ser difíceis de rastrear sob pressão. Um VPS Linux com suporte técnico especializado pode reduzir significativamente o tempo de diagnóstico em situações críticas.

Conheça os planos de VPS Linux da AviraHost