DNS resolution between containers in Docker - Step-by-Step Execution

Process Flow - DNS resolution between containers

Start Docker Network

↓

Create Containers

↓

Containers Join Network

↓

Container A Queries DNS

↓

Docker Embedded DNS Resolves Name

↓

IP Address Returned to Container A

↓

Container A Connects to Container B Using IP

Docker creates a network where containers join and can resolve each other's names via embedded DNS, allowing communication by container names.

Execution Sample

Docker

docker network create mynet

docker run -d --name containerA --network mynet nginx

docker run -d --name containerB --network mynet nginx

docker exec containerA ping -c 1 containerB

Create a network, start two containers on it, then ping containerB from containerA using its name.

Process Table

Step	Action	Command/Query	Result	Notes
1	Create network	docker network create mynet	Network 'mynet' created	Custom bridge network allows DNS resolution
2	Start containerA	docker run -d --name containerA --network mynet nginx	containerA running	Attached to 'mynet'
3	Start containerB	docker run -d --name containerB --network mynet nginx	containerB running	Attached to 'mynet'
4	Ping containerB from containerA	docker exec containerA ping -c 1 containerB	Ping successful, IP resolved	DNS resolved 'containerB' to IP inside 'mynet'
5	Exit	Ping command ends	Ping command exits with success	Communication verified

💡 Ping command completes successfully, confirming DNS resolution and connectivity

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Network 'mynet'	None	Created	Created	Created	Created	Created
containerA status	None	None	Running	Running	Running	Running
containerB status	None	None	None	Running	Running	Running
DNS resolution in containerA	None	None	None	None	containerB -> IP	containerB -> IP

Key Moments - 2 Insights

Why can't containers resolve each other's names without a user-defined network?

By default, containers on the default bridge network cannot resolve names because Docker's embedded DNS only works on user-defined networks, as shown by step 1 creating 'mynet' enabling DNS.

What does the ping command inside containerA actually test?

It tests both DNS resolution of 'containerB' to its IP and network connectivity, as seen in step 4 where ping succeeds after DNS resolves the name.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the network 'mynet' created?

A Step 2

B Step 3

C Step 1

D Step 4

💡 Hint

Check the 'Action' and 'Result' columns in the first row of the execution table.

According to the variable tracker, when does containerB start running?

A After Step 3

B After Step 2

C After Step 1

D After Step 4

💡 Hint

Look at the 'containerB status' row and see when it changes to 'Running'.

If containerA was not attached to 'mynet', what would happen to the ping command in step 4?

A Ping would succeed as usual

B Ping would fail due to no DNS resolution

C Ping would resolve IP but fail to connect

D Ping would connect but not resolve IP

💡 Hint

Refer to the key moment about DNS resolution requiring user-defined networks.

Concept Snapshot

Docker DNS resolution between containers:
- Create a user-defined network (docker network create)
- Run containers attached to this network (--network option)
- Containers can resolve each other by name via Docker embedded DNS
- Use commands like ping containerName inside containers to test
- Default bridge network does NOT support this DNS resolution

Full Transcript

This visual execution shows how Docker enables DNS resolution between containers by using a user-defined network. First, a network named 'mynet' is created. Then two containers, containerA and containerB, are started and attached to 'mynet'. When containerA runs a ping command to 'containerB', Docker's embedded DNS resolves 'containerB' to its IP address within the network. The ping succeeds, confirming both DNS resolution and network connectivity. Variables like container statuses and network state are tracked step-by-step. Key points include the necessity of a user-defined network for DNS resolution and that the ping command tests both name resolution and connectivity.

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