Crônicas do SysAdmin: resolvendo cascatas de erros no Dovecot e BIND9

Alguns incidentes começam com um erro simples e revelam problemas estruturais em camadas diferentes da stack. Este caso reuniu falha de entrega no Exim/Dovecot e inconsistências graves de zona no BIND9.

1) Falha de LMTP no Dovecot

Erro inicial no Exim:

Failed to connect to socket /var/run/dovecot/lmtp: Connection refused

No systemctl status dovecot, o serviço estava em failed por erro de configuração do FTS Solr.

Mensagem chave:

Fatal: Error in configuration file fts.conf: Unknown section name: plugin.

Causa e correção

Em versões Dovecot 2.3+, a sintaxe de blocos mudou. Além disso, havia include redundante/recursivo no arquivo.

Configuração antiga:

fts = solr
fts_solr = url=http://solr-server:8984/solr/dovecot/

Configuração corrigida:

fts solr {
  url = http://solr-server:8984/solr/dovecot/
}

Validação obrigatória antes de restart:

doveconf -n

2) BIND9 recusando inicialização

Após estabilizar e-mail, o named falhava por inconsistências em zonas.

Validação:

named-checkconf -z

Problemas encontrados:

1. zonas órfãs no named.conf sem arquivo .db correspondente
2. registros NS sem glue records (A/AAAA)
3. MX apontando para CNAME (incompatível com RFC)
4. permissões de arquivo incompatíveis com usuário do serviço

Intervenção aplicada

1. Remoção de entradas órfãs pelos mecanismos corretos do ambiente gerenciado
2. Correção de glue records para todos os nameservers autoritativos
3. Ajuste de MX para hostnames válidos (não CNAME)
4. Padronização de permissões de zona para leitura do processo named

3) Conflito de autoridade entre servidores

Um domínio estava presente em dois nós:

• servidor A com zona correta, porém sem replicação funcional
• servidor B replicando zona antiga

Resultado: internet enxergava dados incorretos por autoridade ativa no nó errado.

Correção:

1. remover zona redundante do secundário indevido
2. restaurar replicação no primário correto
3. validar novamente cadeia autoritativa

Checklist de sobrevivência

1. Valide sintaxe antes de restart (doveconf -n, named-checkconf -z).
2. Audite permissões de arquivo em serviços sensíveis.
3. Evite remoções manuais fora do fluxo do painel/automação.
4. Trate duplicidade de zona como incidente de autoridade, não apenas DNS local.

Incidentes em e-mail e DNS raramente são isolados. A recuperação estável exige visão sistêmica: configuração válida, permissões corretas e autoridade de zona coerente entre servidores.

Este post está licenciado sob CC BY-NC.