Problem

app can't reach the database. Its logs show it can't even resolve the name db — could not translate host name "db". But db is healthy and running right next to it, and you can confirm both are on the network. Even stranger: if you use db's IP address directly it works, but the name never resolves.

Figure out why name resolution fails between two running containers, and fix it so app can reach db by name.

Initial setup

• app — myapp:latest, Up, 172.17.0.2.
• db — postgres:15-alpine, Up, healthy, 172.17.0.3, port 5432.
• Both were started with no --network.

Example interaction

$ docker exec app getent hosts db
$ echo $?
2                                  # nothing resolved

$ docker inspect -f '{{json .NetworkSettings.Networks}}' app
{"bridge":{...}}                   # app is on "bridge"
$ docker inspect -f '{{json .NetworkSettings.Networks}}' db
{"bridge":{...}}                   # db is on "bridge" too — same default net, no DNS

Acceptance

You've solved it when:

• You've established that both containers are on the default bridge

network, which has no embedded DNS — so they can reach each other only by IP, never by name. This is not a dead database, a firewall, or a /etc/resolv.conf problem.

• You've restored name resolution by putting both containers on a

user-defined network (e.g. docker network create appnet then docker network connect appnet app + ... db), after which docker exec app getent hosts db resolves.

Constraints

• Tools: docker CLI only.
• End state: docker exec app getent hosts db resolves db's IP (the

containers share a user-defined network).

Follow-up

1. Why does the default bridge network behave differently from a network

you create with docker network create?

1. Why is hardcoding db's 172.17.0.x IP (which does work today) a

trap that breaks on the next restart?

1. What does --link do here, and why is it the deprecated answer?