DNS resolution between containers in Docker - Deep Dive

Overview - DNS resolution between containers

What is it?

DNS resolution between containers is the process that allows one container to find and communicate with another container using a name instead of an IP address. In Docker, containers can use DNS to translate container names into IP addresses automatically. This makes it easier to connect containers without manually tracking IPs.

Why it matters

Without DNS resolution, containers would need hardcoded IP addresses to communicate, which can change every time containers restart. This would make managing container networks complex and error-prone. DNS resolution simplifies container communication, enabling scalable and flexible applications.

Where it fits

Learners should first understand basic Docker concepts like containers, images, and networking. After mastering DNS resolution, they can explore advanced Docker networking, service discovery, and orchestration tools like Docker Compose and Kubernetes.

Mental Model

Core Idea

DNS resolution between containers lets containers find each other by name, turning human-friendly names into IP addresses automatically within Docker networks.

Think of it like...

It's like a phone book inside a building: instead of remembering each person's phone number, you look up their name and get the number instantly.

Docker Network
┌─────────────────────────────┐
│                             │
│  ┌─────────┐   ┌─────────┐  │
│  │Container│   │Container│  │
│  │  app1   │   │  app2   │  │
│  └────┬────┘   └────┬────┘  │
│       │             │       │
│    DNS Server (built-in)    │
│       │             │       │
│  app2 → 172.18.0.3          │
│  app1 → 172.18.0.2          │
└─────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Docker Container Networking

Concept: Containers connect through virtual networks that allow them to communicate securely and isolated from the host.

Docker creates virtual networks where containers get their own IP addresses. By default, Docker uses a bridge network that connects containers on the same host. Containers can talk to each other using these IPs.

Result

Containers on the same Docker network can send data to each other using IP addresses.

Knowing that containers have IPs inside virtual networks is the base for understanding how they communicate.

2

Foundation

What is DNS and Why It Matters in Docker

Concept: DNS translates human-friendly names into IP addresses so containers can find each other without remembering numbers.

DNS stands for Domain Name System. It works like a phone book for the internet. Docker includes an internal DNS server that automatically maps container names to their IPs within a network.

Result

Containers can use container names to reach each other instead of IP addresses.

Understanding DNS inside Docker networks removes the need to track changing IPs manually.

3

Intermediate

Using Container Names for DNS Resolution

🤔Before reading on: do you think containers can reach each other by default using just their names? Commit to yes or no.

Concept: Docker automatically registers container names in its internal DNS for containers on the same user-defined network.

When you create a user-defined bridge network and run containers attached to it, Docker's DNS server lets containers resolve each other's names. For example, container 'web' can ping 'db' by name.

Result

Running 'ping db' inside 'web' container returns successful responses.

Knowing that user-defined networks enable automatic DNS resolution by container name helps design flexible multi-container apps.

4

Intermediate

Limitations of Default Bridge Network DNS

🤔Before reading on: does the default bridge network support DNS resolution by container name? Commit to yes or no.

Concept: The default bridge network does not support automatic DNS resolution by container name; user-defined networks are needed.

By default, Docker creates a 'bridge' network. Containers on this network cannot resolve each other's names automatically. You must use IP addresses or create a user-defined network for DNS resolution.

Result

Trying to ping a container by name on the default bridge network fails.

Understanding this limitation prevents confusion and guides proper network setup for container communication.

5

Advanced

Docker Compose and Service Name DNS Resolution

🤔Before reading on: do you think Docker Compose automatically sets up DNS for service names? Commit to yes or no.

Concept: Docker Compose creates a network where service names act as DNS names for containers, simplifying multi-container setups.

In a docker-compose.yml file, each service gets a DNS name matching its service name. Containers can reach each other by these names without extra configuration.

Result

Inside a container, 'ping db' works if 'db' is a service in the Compose file.

Knowing Compose handles DNS automatically saves time and reduces errors in multi-container projects.

6

Expert

Custom DNS and Multi-Host Container Resolution

🤔Before reading on: can Docker's built-in DNS resolve container names across multiple hosts by default? Commit to yes or no.

Concept: Docker's internal DNS works only within a single network on one host; multi-host DNS requires external tools or orchestration.

For multi-host setups, Docker Swarm or Kubernetes provide service discovery across hosts. Alternatively, custom DNS servers or overlay networks can be configured to resolve container names cluster-wide.

Result

Without orchestration, container name resolution fails across hosts; with orchestration, service names resolve globally.

Understanding DNS scope limits helps design scalable distributed systems and choose the right orchestration tools.

Under the Hood

Docker creates a virtual network namespace for each container and runs an embedded DNS server on the Docker daemon. When a container queries a name, the DNS server checks the network's container registry and returns the matching container's IP. This DNS server listens on the container's default gateway IP, intercepting DNS requests transparently.

Why designed this way?

This design allows containers to communicate by name without manual IP management, simplifying dynamic environments where containers start, stop, or move frequently. Alternatives like manual hosts files or external DNS would be cumbersome and error-prone.

┌─────────────────────────────┐
│ Docker Daemon (runs DNS)    │
│ ┌─────────────────────────┐ │
│ │ Embedded DNS Server      │ │
│ │                         │ │
│ │ Container Name → IP Map │ │
│ └──────────┬──────────────┘ │
│            │                │
│ ┌──────────▼──────────────┐ │
│ │ Docker Network Bridge    │ │
│ └──────────┬──────────────┘ │
│            │                │
│ ┌──────────▼──────────────┐ │
│ │ Container A             │ │
│ │ DNS Query: 'db'         │ │
│ │ Receives IP from DNS    │ │
│ └─────────────────────────┘ │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Docker's default bridge network support container name DNS resolution? Commit to yes or no.

Common Belief: Docker containers can always resolve each other's names regardless of network type.

Reality: Only containers on user-defined bridge networks or overlay networks have automatic DNS resolution by container name; the default bridge network does not support this.

Why it matters: Assuming default bridge supports DNS leads to failed connections and wasted debugging time.

Quick: Can Docker's internal DNS resolve container names across multiple hosts without extra setup? Commit to yes or no.

Common Belief: Docker's built-in DNS works across all hosts in a cluster automatically.

Reality: Docker's internal DNS only works within a single host's network; multi-host name resolution requires orchestration tools like Docker Swarm or Kubernetes.

Why it matters: Expecting cross-host DNS without orchestration causes network failures in distributed applications.

Quick: Does Docker Compose require manual DNS configuration for service name resolution? Commit to yes or no.

Common Belief: You must manually configure DNS for Docker Compose services to communicate by name.

Reality: Docker Compose automatically creates a network where service names resolve to container IPs without extra DNS setup.

Why it matters: Not knowing this leads to unnecessary complexity and configuration errors.

Quick: Is container IP address stable and reliable for long-term communication? Commit to yes or no.

Common Belief: Containers keep the same IP address forever, so using IPs is safe.

Reality: Container IPs can change on restart or recreation; relying on IPs instead of DNS names is fragile.

Why it matters: Hardcoding IPs causes broken connections and maintenance headaches.

Expert Zone

1

Docker's DNS server caches results per container, which can cause stale entries if containers restart quickly; understanding cache behavior helps troubleshoot intermittent failures.

2

Service discovery in Docker Swarm extends DNS resolution with load balancing and failover, which is invisible to containers but critical for production reliability.

3

Custom user-defined networks can be configured with different drivers (bridge, overlay) affecting DNS scope and container reachability.

When NOT to use

Avoid relying solely on Docker's internal DNS for multi-host or large-scale deployments; instead, use orchestration platforms like Kubernetes or Docker Swarm that provide robust service discovery and DNS across clusters.

Production Patterns

In production, teams use Docker Compose for local development with service name DNS, then deploy to Swarm or Kubernetes for multi-host DNS and service discovery. They also combine DNS with environment variables and health checks for resilient communication.

Connections

Service Discovery in Kubernetes

Builds-on Docker container DNS resolution by adding cluster-wide name resolution and load balancing.

Understanding Docker's DNS helps grasp Kubernetes service discovery, which extends these ideas to multi-host clusters.

Domain Name System (DNS) in Networking

Same pattern of translating names to IPs applied inside container networks.

Knowing general DNS principles clarifies how Docker's embedded DNS server works internally.

Phone Book Systems

Both map human-friendly names to numeric addresses for easier communication.

Recognizing this pattern across domains shows how naming systems simplify complex addressing.

Common Pitfalls

#1 Trying to ping a container by name on the default bridge network and failing.

Wrong approach:

docker network create default
# Run containers on default bridge

docker run -d --name db busybox sleep 1000
docker run -it --name web busybox
ping db

Correct approach:

docker network create mynet

docker run -d --net mynet --name db busybox sleep 1000
docker run -it --net mynet --name web busybox
ping db

Root cause:

Assuming default bridge network supports DNS resolution by container name, which it does not.

#2 Hardcoding container IP addresses in application configs for communication.

Wrong approach:

db_host=172.17.0.2
# Use this IP in app config

Correct approach:

db_host=db
# Use container name for DNS resolution

Root cause:

Not understanding that container IPs can change, making hardcoded IPs unreliable.

#3 Expecting Docker's internal DNS to resolve container names across multiple hosts without orchestration.

Wrong approach:

Running containers on different hosts and pinging by name without overlay network or Swarm.

Correct approach:

Use Docker Swarm or Kubernetes for multi-host service discovery and DNS resolution.

Root cause:

Misunderstanding the scope of Docker's internal DNS limited to single-host networks.

Key Takeaways

Docker provides an internal DNS server that lets containers on the same user-defined network resolve each other's names automatically.

The default Docker bridge network does not support container name DNS resolution; user-defined networks are required.

Docker Compose simplifies multi-container communication by creating networks where service names act as DNS names.

Docker's internal DNS works only within a single host; multi-host name resolution requires orchestration tools like Docker Swarm or Kubernetes.

Relying on container names instead of IP addresses makes container communication more reliable and easier to manage.