SysAdmin chronicles: fixing cascading Dovecot and BIND9 errors

Some outages start as a single error and quickly expose deeper stack problems. This incident combined Exim/Dovecot mail flow failure and global BIND9 zone validation collapse.

1) LMTP failure in Dovecot

Initial Exim symptom:

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

Dovecot status showed failed due to invalid FTS Solr config.

Critical log line:

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

Root cause and fix

Dovecot 2.3+ expects updated block syntax, and there was also recursive include behavior in config files.

Legacy pattern:

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

Corrected pattern:

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

Mandatory pre-restart check:

doveconf -n

2) BIND9 startup failure

After mail fix, named still failed due to zone-level consistency errors.

Validation command:

named-checkconf -z

Findings:

1. orphan zones in named.conf without physical .db files
2. NS records missing glue A/AAAA records
3. MX records pointing to CNAME targets
4. zone file permissions incompatible with named runtime user

Remediation actions

1. remove orphaned zone references using managed tooling/workflow
2. add required glue records for authoritative nameservers
3. replace MX CNAME targets with valid host records
4. normalize zone file ownership/permissions for service readability

3) Multi-server authority conflict

One domain existed on two nodes:

• node A had correct zone but broken replication
• node B served outdated zone

Internet resolved to wrong authority chain.

Fix:

1. remove redundant zone from wrong secondary authority
2. restore replication on correct primary
3. revalidate authoritative path end-to-end

Survival checklist

1. validate config before restart (doveconf -n, named-checkconf -z)
2. audit file permissions, not only syntax
3. avoid manual deletion outside panel/automation flow
4. treat duplicated zones as authority incidents, not just local DNS issues

Mail and DNS failures are often coupled operationally. Stable recovery requires configuration correctness, file access integrity, and authoritative zone ownership consistency across nodes.

This post is licensed under CC BY-NC.