Docker 29.1.1 fixes broken DNS on custom bridge networks

Q: How do I test if I'm affected by the Docker DNS regression?

Create a custom bridge network with docker network create test-net, then run docker run --rm --network test-net busybox nslookup example.com. If this fails but docker run --rm --network bridge busybox nslookup example.com works, you have hit the regression. Check /etc/resolv.conf inside the containe

I’ve watched this one waste entire afternoons. You upgrade to Docker 29.1.0, your containers keep running, and then every outbound call starts timing out because DNS lookups from custom bridge networks stop working.

Docker v29.1.1 (released Nov 28, 2025) rolls back the change that triggered the regression, via moby/moby#51615. If you run containers on custom bridge networks and they suddenly cannot resolve external hostnames, this patch sits at the top of your list.

What actually broke (and what 29.1.1 changes)

Here’s the thing. DNS failures feel like “the network is flaky,” but in this case Docker’s embedded DNS resolver lost the upstream nameserver list in a bad code path, so containers on custom bridges could not resolve anything outside.

Networking fix (the real payload): Docker 29.1.1 reverts the earlier DNS-related change and restores external DNS resolution for containers on custom bridge networks. See moby/moby#51615, and the related regression report moby/moby#51614.

How to tell if you’re affected (2-minute test)

Test it. Do not guess.

This is the quickest way I know to separate “upstream DNS is down” from “Docker networking just broke me.” You create a custom bridge, run a tiny container, and ask it to resolve a hostname.

Create a custom bridge: Run docker network create rr-dns-test.
Run a DNS lookup inside that network: Run docker run –rm –network rr-dns-test busybox nslookup example.com. If this fails but the host can resolve, you likely hit the regression.
Compare against the default bridge: Run docker run –rm –network bridge busybox nslookup example.com. A difference between the two is the tell.
Peek at resolver config inside the container: Run docker run –rm –network rr-dns-test busybox cat /etc/resolv.conf. If it points at Docker’s embedded resolver but lookups still fail, focus on the Docker Engine version and the daemon logs.

Who should upgrade (and who can probably wait)

🔔 Never Miss a Breaking Change

Get weekly release intelligence — breaking changes, security patches, and upgrade guides before they break your build.

✅ You're in! Check your inbox for confirmation.

Upgrade fast if DNS already fails. Otherwise, you can be a little boring about it.

If your production hosts run custom bridge networks and containers cannot resolve external names, treat this like an outage fix. Canary one host, validate, then roll forward. Some folks skip canaries for patch releases. I do not, because networking bugs love to show up only on the weird host with the weird iptables rules.

Upgrade now: You run custom bridge networks and you see DNS failures after moving to 29.1.0.
Upgrade soon: You depend on outbound DNS from containers (payments, auth, external APIs), even if you have not seen a failure yet.
Maybe wait a week: Dev laptops, throwaway environments, anything where a quick rollback costs less than the meeting you will schedule to discuss it.

I don’t trust “Known issues: none” from any project. I trust a before-and-after nslookup that I ran myself.

Upgrade plan I’d use on a real fleet

Go slow. But not too slow.

I can’t give one single command that’s correct for every distro and packaging choice (docker-ce vs moby-engine vs vendor images), so I’m going to be explicit about the safe pattern: follow Docker’s official install/upgrade steps for your OS, then restart the daemon, then prove DNS works on a custom bridge.

Pre-checks: Record your current version with docker version and dockerd –version. Note which hosts run custom bridge networks with docker network ls.
Upgrade using official docs: Use the Docker Engine install/upgrade guide for your OS, then upgrade to 29.1.1 through your normal repo workflow. This avoids the “apt-get upgrade docker-ce” trap when your package name is different.
Restart the daemon: Restart Docker with your service manager (often systemctl restart docker), then watch logs with journalctl -u docker -n 200 –no-pager.
Verify on a custom bridge: Re-run the nslookup tests above on at least one known custom bridge network, not just the default bridge.

If you can’t upgrade today (mitigations)

Sometimes you’re pinned. It happens.

If you can’t move off 29.1.0 immediately, you can sometimes limp along by setting explicit DNS for critical containers (for example via –dns flags or compose settings), or by shifting one critical workload to host networking. These workarounds have sharp edges, and they depend on your environment, so test them in staging first. I haven’t tested every combo here with every firewall and every CNI plugin, and the docs get vague fast.

Explicit DNS server: Configure a known resolver for the container and validate with nslookup.
Host networking (for the fire drill): Use it for one service that absolutely must resolve names, then undo it once you patch.
Rollback: If you have a known-good prior version and a clean package repo history, roll back the Engine, then rerun the same DNS tests.

Post-upgrade checklist

Prove it. Then ship it.

After you patch, run one simple smoke test that touches a real external dependency. Make your container resolve a hostname and make an HTTPS call, then watch error rates for an hour. Ignore the GitHub commit count. It’s a vanity metric. Your only metric here is “do my containers resolve names again?”

DNS test: docker run –rm –network rr-dns-test busybox nslookup example.com
Network sanity: docker network inspect rr-dns-test
Daemon signals: journalctl -u docker -n 200 –no-pager

Other stuff in this release: revert commits, small churn, the usual. There’s probably a better way to test this, but…

Frequently Asked Questions

What DNS bug does Docker 29.1.1 fix? Docker 29.1.0 introduced a regression where containers on custom bridge networks lost the ability to resolve external DNS names. Docker’s embedded DNS resolver dropped the upstream nameserver list in a bad code path, so containers could not reach anything outside the Docker network. Version 29.1.1 reverts the change (moby/moby#51615).

How do I test if I’m affected by the Docker DNS regression? Create a custom bridge network with docker network create test-net, then run docker run --rm --network test-net busybox nslookup example.com. If this fails but docker run --rm --network bridge busybox nslookup example.com works, you have hit the regression. Check /etc/resolv.conf inside the container to confirm it points at Docker’s embedded resolver.

Is the DNS bug specific to custom bridge networks? Yes. The default bridge network is not affected. Only containers running on user-created bridge networks (created with docker network create) lose external DNS resolution. This makes the bug particularly insidious because it only shows up in production-like configurations where teams use custom networks for isolation.

Should I upgrade to Docker 29.1.1 even if DNS works fine? If you run Docker 29.1.0 with custom bridge networks, yes. The bug can appear intermittently depending on timing and network configuration, so you might not see it until a container restart or a new deployment triggers the bad code path. Upgrading to 29.1.1 removes the risk entirely.