Netfilter throws dns nameserver error only after reboot

[gpz1100]

Contribution guidelines

• I've read the contribution guidelines and wholeheartedly agree

Checklist prior issue creation

• I understand that failure to follow below instructions may cause this issue to be closed.
• I understand that vague, incomplete or inaccurate information may cause this issue to be closed.
• I understand that this form is intended solely for reporting software bugs and not for support-related inquiries.
• I understand that all responses are voluntary and community-driven, and do not constitute commercial support.
• I confirm that I have reviewed previous issues to ensure this matter has not already been addressed.
• I confirm that my environment meets all prerequisite requirements as specified in the official documentation.

Description

Debian 13 (from iso) and mailcow dockerized installed in vps. After a reboot, netfilter container log reflects

Exception in thread Thread-4 (blacklistUpdate):
Traceback (most recent call last):
  File "/usr/lib/python3.12/threading.py", line 1075, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.12/threading.py", line 1012, in run
    self._target(*self._args, **self._kwargs)
  File "/app/main.py", line 412, in blacklistUpdate
    new_blacklist = genNetworkList(list)
                    ^^^^^^^^^^^^^^^^^^^^
  File "/app/main.py", line 362, in genNetworkList
    resolver = dns.resolver.Resolver()
               ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/dns/resolver.py", line 953, in __init__
    self.read_resolv_conf(filename)
  File "/usr/lib/python3.12/site-packages/dns/resolver.py", line 1047, in read_resolv_conf
    raise NoResolverConfiguration("no nameservers")
dns.resolver.NoResolverConfiguration: no nameservers

Restart container with docker compose down and bring it backup with docker compose up -d netfilter-mailcow, no more error.

Contents of resolv.conf in container is empty after reboot.

/app # cat /etc/resolv.conf
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.


# Based on host file: '/etc/resolv.conf'
# Overrides: []

Vps is configured for dhcp with statically assigned nameservers.

 cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens3
iface ens3 inet dhcp

interface ens3
static domain_name_servers=1.1.1.1 8.8.8.8

added to bottom of /etc/dhcpcd.conf.

It seems that docker and dhcp are starting simultaneously and /etc/resolv.conf on host isn't populated by the time docker has launched.

Contents of docker service file - docker installed using mailcow documentation instructions

cat /usr/lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target nss-lookup.target docker.socket firewalld.service containerd.service time-set.target
Wants=network-online.target containerd.service
Requires=docker.socket
StartLimitBurst=3
StartLimitIntervalSec=60

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutStartSec=0
RestartSec=2
Restart=always

# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity

# Comment TasksMax if your systemd version does not support it.
# Only systemd 226 and above support this option.
TasksMax=infinity

# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes

# kill only the docker process, not all processes in the cgroup
KillMode=process
OOMScoreAdjust=-500

[Install]
WantedBy=multi-user.target

WORK AROUND

Created another systemd service to not launch docker until /etc/resolv.conf on host is populated.

cat  /etc/systemd/system/wait-dhcpcd-resolv.service
[Unit]
Description=Wait for dhcpcd to populate resolv.conf
DefaultDependencies=no
Before=docker.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'while ! grep -q nameserver /etc/resolv.conf; do sleep 1; done'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Referenced this in docker service override file

cat /etc/systemd/system/docker.service.d/override.conf
[Unit]
After=wait-dhcpcd-resolv.service
Wants=wait-dhcpcd-resolv.service

No more errors in netfilter log and /etc/resolv.conf within the container is now populated with nameserver entries after reboot.

Steps to reproduce:

1. Reboot the host.

Logs:

2026-02-05 15:19:38 INFO: Watching Redis channel F2B_CHANNEL
Exception in thread Thread-4 (blacklistUpdate):
Traceback (most recent call last):
  File "/usr/lib/python3.12/threading.py", line 1075, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.12/threading.py", line 1012, in run
    self._target(*self._args, **self._kwargs)
  File "/app/main.py", line 412, in blacklistUpdate
    new_blacklist = genNetworkList(list)
                    ^^^^^^^^^^^^^^^^^^^^
  File "/app/main.py", line 362, in genNetworkList
    resolver = dns.resolver.Resolver()
               ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/dns/resolver.py", line 953, in __init__
    self.read_resolv_conf(filename)
  File "/usr/lib/python3.12/site-packages/dns/resolver.py", line 1047, in read_resolv_conf
    raise NoResolverConfiguration("no nameservers")
dns.resolver.NoResolverConfiguration: no nameservers

Which branch are you using?

master (stable)

Which architecture are you using?

x86_64

Operating System:

Debian GNU/Linux 13 (trixie)

Server/VM specifications:

6gb, 5 cores

Is Apparmor, SELinux or similar active?

apparmor active

Virtualization technology:

KVM

Docker version:

29.2.0

docker-compose version or docker compose version:

5.0.2

mailcow version:

2025-12a

Reverse proxy:

none

Logs of git diff:

Logs of iptables -L -vn:

n/a

Logs of ip6tables -L -vn:

n/a

Logs of iptables -L -vn -t nat:

n/a

Logs of ip6tables -L -vn -t nat:

n/a

DNS check:

n/a

[flightlesstux]

Hi, this looks like a container startup race condition — the netfilter container starts before Docker has fully populated /etc/resolv.conf inside it, so the DNS resolver finds an empty file and throws NoResolverConfiguration.

The fact that a docker compose down && up fixes it (but a reboot doesn't) points squarely at startup ordering: on a cold boot, the host's own DNS resolver may not be ready yet when Docker starts the container, leaving the generated resolv.conf empty.

A few things worth checking:

1. depends_on ordering — netfilter currently doesn't depend on unbound-mailcow in docker-compose.yml. Adding a dependency (or at minimum a health check) would ensure the internal DNS resolver is up before netfilter tries to use it.

2. Retry logic in genNetworkList() — the dns.resolver.Resolver() call in main.py line ~362 has no retry/backoff. Wrapping it in a short retry loop (e.g. 3 attempts with 2s sleep) would make the container resilient to transient DNS unavailability at startup without needing a manual restart.

3. Short-term workaround — adding restart: always is already in place, but the container may need to cycle a couple of times before DNS is ready on reboot. A healthcheck that verifies DNS resolution before marking the container healthy would help orchestration tools handle this more gracefully.

The cleanest fix is probably the retry loop in genNetworkList() combined with ensuring unbound-mailcow starts first.