Container DNS and User-Defined Networks

The problem: no DNS on the default bridge

As you saw in the previous lesson, containers on the default bridge can reach each other by IP address but not by name. This is a significant limitation in practice — IP addresses are dynamic and change every time a container is recreated.

Hardcoding IP addresses into application configuration is fragile. You need a way to refer to services by a stable name. That is exactly what user-defined networks provide.

The solution: create a user-defined bridge

Use docker network create to create a named bridge network:

docker network create appnet

Docker creates a new bridge (separate from docker0) and starts an embedded DNS resolver scoped to that network. Containers attached to appnet can resolve each other’s names automatically.

Running containers on a user-defined network

Start an nginx container named web on appnet:

docker run -d --name web --network appnet nginx:alpine

Start an Alpine container named client on the same network:

docker run -it --name client --network appnet alpine sh

Inside the client shell, ping web by name:

ping -c 3 web

The ping succeeds. Docker’s embedded DNS resolver translates web to the container’s IP address automatically.

Inspecting the network

From the host, inspect appnet to see which containers are attached and what IPs they were assigned:

docker network inspect appnet

The output includes a Containers section listing each attached container with its name, IP, and MAC address.

Teardown

docker stop web client
docker rm web client
docker network rm appnet

Hands-on: DNS on a user-defined network

# Create a user-defined bridge network
docker network create appnet

# Start an nginx container on appnet
docker run -d --name web --network appnet nginx:alpine

# Start a client container on appnet and ping web by name
docker run --rm --name client --network appnet alpine ping -c 3 web

# Inspect the network to see attached containers
docker network inspect appnet

# Cleanup
docker stop web && docker rm web
docker network rm appnet

Try container DNS resolution ↗

🐳 User-defined networks give you DNS

Create a named network with docker network create and attach containers with --network. Containers on the same user-defined bridge resolve each other by container name automatically.

What feature do user-defined bridge networks provide that the default bridge does not?

Faster network throughput between containers The ability to publish ports to the host An embedded DNS resolver for container name resolution Encryption of all inter-container traffic

Which command creates a user-defined bridge network named 'appnet'?

docker network init appnet docker network create appnet docker network add --driver bridge appnet docker bridge create appnet

You run two containers on the same user-defined bridge network. Container A is named 'api' and container B is named 'db'. How can container A reach container B?

Only by the container's IP address — names do not work on any bridge network By using 'db.local' as the hostname By the container name 'db' — the embedded DNS resolver handles it Only after running docker network connect for each container

What happens to container name resolution if you move containers back to the default bridge after using a user-defined network?

Name resolution continues to work because it is cached Name resolution stops working — the default bridge has no embedded DNS Name resolution works only for containers started after the move Docker automatically migrates the DNS resolver to the default bridge

Submit

Mark as complete