DNS resolution between containers in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

How does Docker DNS resolution work between containers on the same user-defined network?

When two containers are connected to the same user-defined Docker network, how does one container resolve the hostname of the other container?

A Docker uses the host machine's DNS settings to resolve container names.

B Containers must use external DNS servers like 8.8.8.8 to resolve each other's hostnames.

C Containers cannot resolve each other's hostnames unless you manually edit the /etc/hosts file inside each container.

D Docker automatically creates an internal DNS server that resolves container names to their IP addresses within that network.

💡 Hint

Think about how Docker manages networking internally for containers on the same network.

Docker creates an internal DNS server for each user-defined network. This DNS server automatically resolves container names to their IP addresses, allowing containers to communicate by name.

💻 Command Output

intermediate

What is the output of 'docker network inspect' for container name resolution?

Given two containers web and db connected to the same user-defined network mynetwork, what key in the output of docker network inspect mynetwork shows the container names and their IP addresses?

Docker

docker network inspect mynetwork

A The <code>Containers</code> section lists container IDs, names, and IPv4 addresses.

B The <code>Services</code> section lists container names and IPs.

C The <code>Endpoints</code> section shows container names and IPs.

D The <code>Hosts</code> section shows container names and IPs.

💡 Hint

Look for the section that maps containers to their network details.

The Containers section in the network inspect output shows each container's ID, name, and IP address on that network.

❓ Configuration

advanced

How to enable DNS resolution between containers on different Docker networks?

You have two containers on different user-defined Docker networks. You want them to resolve each other's hostnames. Which configuration allows this?

A Manually add entries to each container's /etc/hosts file.

B Connect both containers to a common user-defined network in addition to their existing networks.

C Use the <code>--link</code> flag to link containers across networks.

D Set the <code>--dns</code> flag to the host's DNS server when running containers.

💡 Hint

Think about how Docker networks isolate containers and how to bridge that isolation.

Containers must share at least one common user-defined network for Docker's internal DNS to resolve their names. Connecting both containers to a shared network enables this.

❓ Troubleshoot

advanced

Why does DNS resolution fail between containers on the default bridge network?

You have two containers on the default bridge network. One container tries to ping the other by container name but fails. Why?

A The containers need to have the <code>--dns</code> flag set to enable DNS resolution.

B The containers must be restarted to refresh DNS entries.

C The default bridge network does not provide automatic DNS resolution for container names.

D Docker requires containers to be on the same host to resolve names.

💡 Hint

Consider the difference between the default bridge network and user-defined networks.

The default bridge network does not support automatic DNS resolution by container name. Only user-defined networks provide this feature.

✅ Best Practice

expert

What is the best practice for reliable DNS resolution between containers in a multi-host Docker Swarm cluster?

In a Docker Swarm cluster with multiple hosts, how should you configure services to ensure DNS resolution between containers works reliably?

A Use an overlay network for the services so Docker's internal DNS resolves service names across hosts.

B Manually configure each host's /etc/hosts file with all container IPs.

C Use the default bridge network and rely on external DNS servers.

D Assign static IP addresses to containers and use those IPs directly.

💡 Hint

Think about how Docker Swarm manages networking across multiple hosts.

Docker Swarm uses overlay networks to connect containers across hosts. The internal DNS resolves service names within these overlay networks, enabling reliable cross-host communication.

Practice

1. What allows Docker containers on the same user-defined network to communicate using container names instead of IP addresses?

easy

A. Using container IP addresses only

B. Manual editing of /etc/hosts file

C. Docker's built-in DNS service

D. Exposing ports to the host machine

Solution

1. Step 1: Understand Docker networking basics

   Docker provides a built-in DNS service for containers on the same user-defined network.

2. Step 2: Recognize how containers resolve names

   Containers use this DNS service to resolve other container names to their IP addresses automatically.

3. Final Answer:

   Docker's built-in DNS service -> Option C

4. Quick Check:

   Docker DNS = container name resolution [OK]

Hint: User-defined networks enable DNS by default [OK]

Common Mistakes:

• Assuming default bridge network supports DNS resolution by name
• Thinking manual /etc/hosts editing is needed
• Using IP addresses instead of container names

2. Which Docker command correctly creates a user-defined network named mynetwork?

easy

A. docker network create mynetwork

B. docker create network mynetwork

C. docker network new mynetwork

D. docker network build mynetwork

Solution

1. Step 1: Recall Docker network creation syntax

   The correct command to create a network is docker network create <name>.

2. Step 2: Match the command with options

   docker network create mynetwork matches the correct syntax exactly.

3. Final Answer:

   docker network create mynetwork -> Option A

4. Quick Check:

   docker network create = create network [OK]

Hint: Use 'docker network create' to make new networks [OK]

Common Mistakes:

• Using 'docker create network' which is invalid syntax
• Confusing 'new' or 'build' with 'create'
• Omitting the network name

3. Given two containers web and db on the same user-defined network, what will be the output of docker exec web ping -c 1 db if db is running?

medium

A. ping: unknown host db

B. PING db (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: icmp_seq=0 ttl=64 time=0.123 ms

--- db ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss

C. Error: container 'db' not found

D. Request timed out

Solution

1. Step 1: Understand DNS resolution on user-defined networks

   Containers on the same user-defined network resolve each other's names automatically.

2. Step 2: Predict ping command output

   Since db is running and reachable, ping will succeed and show reply details.

3. Final Answer:

   Successful ping output with reply from db's IP -> Option B

4. Quick Check:

   Same network + running container = ping success [OK]

Hint: Ping container name works if on same user network [OK]

Common Mistakes:

• Expecting 'unknown host' on user-defined network
• Confusing default bridge network behavior
• Assuming container must expose ports for ping

4. You created two containers on the default bridge network but ping db from web returns "unknown host db". What is the likely cause?

medium

A. The ping command is not installed in the web container

B. The db container is stopped

C. The web container has no network access

D. Containers are not on a user-defined network, so DNS resolution by name fails

Solution

1. Step 1: Recall default bridge network limitations

   Default bridge network does not support automatic DNS resolution by container name.

2. Step 2: Analyze the error message

   "unknown host db" means DNS lookup failed, likely because containers are not on a user-defined network.

3. Final Answer:

   Containers are not on a user-defined network, so DNS resolution by name fails -> Option D

4. Quick Check:

   Default bridge lacks DNS by name [OK]

Hint: Use user-defined networks for container name DNS [OK]

Common Mistakes:

• Assuming default bridge network supports DNS names
• Ignoring network configuration
• Blaming container stopped state without checking

5. You want two containers, app and cache, to communicate by name. You create a user-defined network mynet. Which sequence of commands correctly sets this up?

hard

A. docker network create mynet
docker run -d --name app --network mynet myappimage
docker run -d --name cache --network mynet mycacheimage

B. docker run -d --name app myappimage
docker run -d --name cache mycacheimage
docker network create mynet

C. docker network create mynet
docker run -d --name app myappimage
docker network connect mynet cache

D. docker run -d --name app --network bridge myappimage
docker run -d --name cache --network bridge mycacheimage

Solution

1. Step 1: Create a user-defined network

   Use docker network create mynet to create the network.

2. Step 2: Run containers attached to the network

   Start both containers with --network mynet to enable DNS resolution by name.

3. Final Answer:

   Create network first, then run containers with --network mynet -> Option A

4. Quick Check:

   User-defined network + containers attached = DNS by name [OK]

Hint: Create network first, then run containers on it [OK]

Common Mistakes:

• Running containers before creating network
• Using default bridge network instead of user-defined
• Not attaching containers to the same network