DNS resolution between containers in Docker - Commands & Configuration

Introduction

When you run multiple containers that need to talk to each other, they must find each other by name. DNS resolution lets containers use simple names instead of IP addresses, making communication easier and more reliable.

When you want a web app container to connect to a database container using a simple name.

When you run multiple microservices in separate containers that need to call each other.

When you want to avoid hardcoding IP addresses that can change every time containers restart.

When you want to organize containers in a network so they can discover each other automatically.

When you need to scale containers and want them to find new instances by name.

Config File - docker-compose.yml

docker-compose.yml

version: '3.8'
services:
  web:
    image: nginx:1.23
    networks:
      - app-network
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: example
    networks:
      - app-network
networks:
  app-network:
    driver: bridge

This file defines two services: web and db. Both are connected to the same custom network called app-network. Docker creates an internal DNS so the web container can reach the db container by the name db. The bridge driver creates an isolated network for these containers to communicate securely.

Commands

Create a custom network named app-network so containers can communicate using DNS names.

Terminal

docker network create app-network

Expected Output

app-network

Start a MySQL container named db connected to app-network. The password is set for root user.

Terminal

docker run -d --name db --network app-network -e MYSQL_ROOT_PASSWORD=example mysql:8.0

Expected Output

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6a7b8c9d0e1f2

→

--name - Assign a name to the container for easy reference

→

--network - Connect the container to the specified network

→

-e - Set environment variables inside the container

Run a temporary Alpine Linux container connected to app-network to test DNS resolution by pinging the db container.

Terminal

docker run -it --rm --network app-network alpine sh

Expected Output

/ # ping -c 1 db

PING db (172.18.0.2): 56 data bytes

64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.123 ms



--- db ping statistics ---

1 packets transmitted, 1 packets received, 0% packet loss

→

-it - Run container interactively with a terminal

→

--rm - Remove container after it exits

→

--network - Connect container to the specified network

Start all services defined in the docker-compose.yml file in detached mode, creating the network and containers automatically.

Terminal

docker-compose up -d

Expected Output

Creating network "app-network" with driver "bridge"

Creating db ... done

Creating web ... done

→

-d - Run containers in the background

From the web container, ping the db container by its service name to verify DNS resolution works.

Terminal

docker exec -it web ping -c 1 db

Expected Output

PING db (172.18.0.2): 56 data bytes

64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.098 ms



--- db ping statistics ---

1 packets transmitted, 1 packets received, 0% packet loss

→

-it - Run a command inside a running container interactively

Key Concept

If containers share a user-defined network, Docker automatically provides DNS so they can find each other by container or service name.

Common Mistakes

Not connecting containers to the same custom network

Containers on different networks cannot resolve each other's names, so DNS resolution fails.

Always create and connect containers to the same user-defined network for DNS to work.

Using default bridge network expecting DNS resolution by container name

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

Create a custom bridge network and connect containers to it.

Trying to ping container names without running containers on the same network

Ping fails because the name cannot be resolved to an IP address.

Verify containers are on the same network before testing DNS resolution.

Summary

Create a user-defined network so containers can communicate by name.

Run containers attached to this network to enable DNS resolution.

Test DNS by pinging one container from another using container or service names.

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