Why do Docker containers lose DNS after a reboot?

Cloud-init or another network-management service can also rewrite /etc/resolv.conf during boot. Check system and service logs around startup, identify which process owns or replaces the file, and disable or reconfigure that behavior if it is not needed. Also verify that Docker’s bridge and firewall rules are still present after boot—custom firewall rules loaded later can remove Docker’s forwarding or masquerading rules and make the problem look like DNS failure.

Docker typically creates a container’s DNS configuration when the container starts, so it may capture the host’s /etc/resolv.conf before the networking stack or another service has finished updating it. Restarting the containers later works because the host resolver is valid by then. Check the host’s resolver file and Docker/container logs at boot, and consider configuring explicit DNS servers in /etc/docker/daemon.json, such as {"dns":["1.1.1.1"]}, instead of relying on boot timing.

If you use Tailscale, check for a race with Debian’s networking services. Tailscale can change the host resolver to its own address, such as 100.100.100.100, after Docker has already started. Compare /etc/resolv.conf before and after Tailscale starts, and make sure the resolver Docker receives is reachable from the containers. A stable fallback resolver may help, but the better fix is to correct the service startup ordering or configure Docker’s DNS explicitly.