Container DNS and service discovery in Docker - Step-by-Step Execution

Process Flow - Container DNS and service discovery

Container A starts

↓

Container A registers name in DNS

↓

Container B starts

↓

Container B queries DNS for Container A

↓

DNS returns Container A IP

↓

Container B connects to Container A using IP

↓

Service communication established

Containers register their names in an internal DNS. Other containers query this DNS to find IPs and connect, enabling service discovery.

Execution Sample

Docker

docker network create mynet

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

docker run -it --rm --network mynet busybox nslookup web

Create a network, run a web container, then run a busybox container to look up the web container's IP via DNS.

Process Table

Step	Action	Command/Query	Result/Output
1	Create network	docker network create mynet	Network 'mynet' created
2	Start web container	docker run -d --name web --network mynet nginx	Container 'web' running with IP 172.18.0.2
3	Start busybox container	docker run -it --rm --network mynet busybox nslookup web	Query DNS for 'web'
4	DNS response	nslookup web	Name: web Address: 172.18.0.2
5	Connect to web	busybox connects to 172.18.0.2	Connection successful
6	Exit	busybox exits	Container removed

💡 Busybox container exits after DNS query and connection test

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Network 'mynet'	none	created	created	created	created
Container 'web' IP	none	172.18.0.2	172.18.0.2	172.18.0.2	172.18.0.2
DNS query result	none	none	query sent	172.18.0.2	172.18.0.2

Key Moments - 3 Insights

Why can the busybox container find the web container by name?

Because both containers are on the same user-defined network 'mynet', Docker automatically provides DNS resolution for container names within that network, as shown in execution_table step 4.

What happens if containers are on different networks?

Containers on different networks cannot resolve each other's names via DNS, so the busybox container would fail to find 'web' by name, unlike in step 4 where they share 'mynet'.

Why does the busybox container get removed after exit?

Because it was run with --rm flag, which tells Docker to remove the container after it stops, as noted in execution_table step 6.

Visual Quiz - 3 Questions

Look at the execution table, what IP address does the DNS return for the 'web' container at step 4?

A 127.0.0.1

B 192.168.1.1

C 172.18.0.2

D None

💡 Hint

Check the 'Result/Output' column at step 4 in the execution_table.

At which step does the busybox container send the DNS query for 'web'?

A Step 3

B Step 2

C Step 5

D Step 6

💡 Hint

Look at the 'Action' and 'Command/Query' columns in the execution_table.

If the network 'mynet' was not created, what would happen when running the web container?

A Container would fail to start

B Container would run but no DNS resolution for 'web'

C Container would run but busybox cannot find 'web' by name

D Container would run with default network and DNS resolution works

💡 Hint

Refer to variable_tracker and key_moments about network and DNS behavior.

Concept Snapshot

Docker containers on the same user-defined network can resolve each other's names via built-in DNS.
Create a network with 'docker network create'.
Run containers attached to this network.
Use container names to connect instead of IPs.
DNS resolves names to container IPs automatically.
This enables simple service discovery inside Docker networks.

Full Transcript

This visual execution shows how Docker containers use internal DNS for service discovery. First, a user-defined network 'mynet' is created. Then, a web container runs attached to 'mynet' and gets an IP address. Next, a busybox container runs on the same network and queries DNS for the name 'web'. The DNS returns the IP of the web container. Busybox uses this IP to connect to the web container successfully. Finally, busybox exits and is removed because it was run with the --rm flag. This demonstrates how containers discover each other by name using Docker's internal DNS on user-defined networks.

Practice

1. What does Docker's built-in DNS service provide for containers on the same user-defined network?

easy

A. It assigns static IP addresses to containers.

B. It allows containers to find each other by their container names.

C. It disables network communication between containers.

D. It automatically updates container images.

Solution

1. Step 1: Understand Docker user-defined networks

   User-defined networks enable containers to communicate using DNS names instead of IP addresses.

2. Step 2: Role of Docker DNS service

   Docker's DNS service resolves container names to their current IP addresses on the same network.

3. Final Answer:

   It allows containers to find each other by their container names. -> Option B

4. Quick Check:

   Docker DNS = container name resolution [OK]

Hint: Containers use names, not IPs, to find each other on user networks [OK]

Common Mistakes:

• Thinking Docker assigns static IPs by default
• Believing DNS disables container communication
• Confusing DNS with image updates

2. Which Docker command correctly creates a user-defined network named my-net to enable container DNS service discovery?

easy

A. docker network create my-net

B. docker create network my-net

C. docker network new my-net

D. docker network build my-net

Solution

1. Step 1: Identify correct Docker network creation syntax

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

2. Step 2: Verify options

   The options using 'docker network new', 'docker create network', and 'docker network build' have incorrect syntax; only docker network create my-net matches Docker syntax.

3. Final Answer:

   docker network create my-net -> Option A

4. Quick Check:

   Correct command = docker network create [OK]

Hint: Use 'docker network create' to make user-defined networks [OK]

Common Mistakes:

• Using 'docker create network' instead of 'docker network create'
• Confusing 'new' or 'build' with network creation
• 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 succeeds showing db IP address and response time.

B. Ping fails with 'unknown host db' error.

C. Ping succeeds but shows IP of web container.

D. Ping command is not available inside containers.

Solution

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

   Containers on the same user-defined network can resolve each other's names to IP addresses.

2. Step 2: Effect of ping command

   Running ping from web to db will resolve db to its IP and send ICMP packets successfully if db is running.

3. Final Answer:

   Ping succeeds showing db IP address and response time. -> Option A

4. Quick Check:

   Container DNS + ping = success if target running [OK]

Hint: Ping container name on same network to test DNS and connectivity [OK]

Common Mistakes:

• Assuming ping fails due to IP changes
• Confusing container names with hostnames outside network
• Believing ping is unavailable inside containers

4. You created two containers on a user-defined network, but web cannot resolve db by name. What is the most likely cause?

medium

A. The web container has no network interface.

B. The db container is stopped.

C. Docker daemon is not running.

D. Containers are on different Docker networks.

Solution

1. Step 1: Check network configuration

   Containers must be on the same user-defined network for DNS name resolution to work.

2. Step 2: Analyze failure cause

   If web cannot resolve db, they are likely on different networks, so DNS does not link them.

3. Final Answer:

   Containers are on different Docker networks. -> Option D

4. Quick Check:

   Different networks block DNS resolution [OK]

Hint: Ensure containers share the same user-defined network for DNS [OK]

Common Mistakes:

• Assuming stopped container causes DNS failure (it causes ping failure)
• Thinking Docker daemon status affects container DNS directly
• Believing container can lack network interface if running

5. You want to deploy a multi-container app with a web server and database. You want the web server to always connect to the database by name, even if the database container restarts and gets a new IP. Which Docker setup ensures this?

hard

A. Run containers on separate networks and link them with --link option.

B. Use the default bridge network and hardcode the database container's IP address in the web server config.

C. Create a user-defined network and run both containers attached to it; use the database container's name in the web server config.

D. Assign static IPs manually to both containers on the default network.

Solution

1. Step 1: Understand service discovery with user-defined networks

   User-defined networks provide automatic DNS resolution by container name, even if IPs change.

2. Step 2: Evaluate options for reliable name-based connection

   Create a user-defined network and run both containers attached to it; use the database container's name in the web server config. uses user-defined network and container names, which is the recommended way for service discovery.

3. Step 3: Why other options fail

   Default bridge network lacks automatic DNS; hardcoding IPs breaks if IP changes; --link is deprecated; static IPs are complex and error-prone.

4. Final Answer:

   Create a user-defined network and run both containers attached to it; use the database container's name in the web server config. -> Option C

5. Quick Check:

   User-defined network + container names = reliable service discovery [OK]

Hint: Use user-defined network and container names for stable service discovery [OK]

Common Mistakes:

• Hardcoding IP addresses instead of using container names
• Using default bridge network without DNS support
• Relying on deprecated --link option
• Manually assigning static IPs unnecessarily