7.2.1.1 Default Bridge Driver

The default bridge driver-based network is the network every container connects to automatically unless explicitly configured otherwise, providing basic connectivity but lacking the automatic DNS-based name resolution that a user-defined bridge network provides.

Containers Use This Network Automatically

Without any explicit --network flag, a newly created container is automatically attached to this default network.

docker run -d --name myapp alpine sleep 1000
docker inspect myapp --format '{{json .NetworkSettings.Networks}}'

This reveals the container is connected to the network named bridge, Docker's default, without any explicit configuration having requested this.

The Key Limitation: No Automatic Name Resolution

Unlike a user-defined bridge network, the default bridge network does not provide automatic DNS-based resolution between containers attached to it, making name-based communication between containers on this network unreliable.

docker run -d --name container-a alpine sleep 1000
docker run -d --name container-b alpine sleep 1000
docker exec container-b ping container-a

This typically fails, since the default bridge network doesn't provide the name resolution that would be needed for it to succeed.

Working Around This Limitation With Legacy Linking

An older mechanism, --link, can provide limited name resolution on the default bridge network, though it is now considered legacy and largely superseded by simply using a user-defined network instead.

docker run -d --name container-b --link container-a alpine sleep 1000

Why a User-Defined Network Is Generally Preferred Instead

Given the default bridge network's limitations, creating and using a dedicated user-defined network is the generally recommended approach for any application involving container-to-container communication.

docker network create mynet
docker run -d --name container-a --network mynet alpine sleep 1000

Why Understanding the Default Bridge Driver Matters

Recognizing the default bridge network's specific limitations — particularly its lack of automatic name resolution — clarifies why containers may unexpectedly fail to communicate by name unless explicitly placed on a dedicated, user-defined network instead.