Why do my containers lose DNS access after a reboot?

If you use Tailscale or another network manager, check whether it replaces /etc/resolv.conf during startup. A resolver such as 100.100.100.100 may work for the host but not from Docker containers. Look at the file before and after the network service starts, and inspect the service logs for changes. Configuring a reliable fallback nameserver or adjusting the resolver integration can prevent the race.

On systems using cloud-init or automated network configuration, resolv.conf may not be ready when Docker launches. Review the boot sequence and journal logs for Docker, the network manager, cloud-init, and the resolver service. Fixing the service ordering or disabling the component that keeps rewriting resolv.conf is better than relying on manually restarting containers.

Also investigate boot-time firewall changes. Docker creates forwarding and NAT rules when it starts, but a firewall service loaded afterward may flush or override those rules. Compare the firewall and Docker rules immediately after boot with the rules after the containers begin working, and check system logs for firewall reloads or failed network initialization.

Docker determines a container’s DNS configuration when the container starts; it doesn’t continuously reread the host’s /etc/resolv.conf. This usually points to a boot-order race where Docker starts before networking, a resolver service, or another tool has finished configuring that file. Check the host’s resolv.conf and the container’s /etc/resolv.conf immediately after boot, then compare them after restarting a container. As a workaround, configure stable DNS servers in /etc/docker/daemon.json, for example: {"dns":["1.1.1.1"]}, and restart Docker.