DOCKER - 16 Network and DNS

In this lesson we explore DNS and its impact on containers in custom and default networks. Good DNS is essential because the dynamic nature of containers — they appear, disappear, move and scale — makes IP addresses unreliable. A container can fail and be rescheduled elsewhere with a different IP a minute later. The built-in answer to this problem is DNS-based naming: Docker uses each container's name as if it were a hostname so containers can locate each other by name rather than by IP.

Automatic DNS on custom networks

Any user-defined network (not the default bridge) provides automatic DNS resolution between the containers attached to it. With our new_nginx container already running on my_app_net, let's add a second one:

docker container run -d --name my_nginx --network my_app_net nginx
docker container exec -it my_nginx ping new_nginx
docker container exec -it new_nginx ping my_nginx

Both pings resolve thanks to the embedded DNS server. This is exactly what you need when a PHP container has to talk to a MySQL container through a configuration file: you reference the other side by name, and Docker keeps the resolution accurate even after restarts. In a production setup with many Docker Swarm hosts, IPs change all the time, but container names stay stable.

The default bridge network has a notable downside: the DNS server is not enabled there. To make two containers on the default bridge see each other by name you must use the --link flag at creation time, declaring each link manually. It works, but it gets tedious quickly.

  • Custom networks — automatic DNS, recommended default
  • Default bridge — requires explicit --link for name resolution
  • Docker Compose — creates a fresh virtual network per app automatically

To wrap up: containers shouldn't rely on IPs to communicate. DNS is the standard mechanism both within a single host and across hosts. Always prefer custom networks so DNS resolution is automatic — much cleaner than maintaining --link declarations everywhere.

Summary

This lesson explains why DNS is critical for Docker container communication and how it solves the problem of dynamic IP addresses. It covers the differences between default bridge networks and custom networks in handling DNS resolution, and demonstrates how container names act as hostnames for reliable communication. The lesson also addresses the limitations of the default bridge network and recommends creating custom networks for easier container intercommunication.

Key points

  • Containers cannot rely on IP addresses for communication because they are dynamic—containers constantly launch, disappear, move, and scale, making consistent communication impossible
  • Docker provides automatic DNS resolution on custom networks, allowing containers to find each other using container names instead of IP addresses
  • Container names serve as hostnames within the same virtual network, enabling predictable communication regardless of IP changes
  • Default bridge networks lack automatic DNS integration; the `--link` option can be used to manually enable it, but is cumbersome
  • Custom networks are recommended over the `--link` option because they provide built-in DNS and eliminate the need for manual configuration
  • Docker Compose further simplifies networking by automatically creating custom virtual networks for applications, making inter-container communication seamless

FAQ

Why can't containers use IP addresses to communicate with each other?

Because container IPs are highly dynamic. Containers constantly start, stop, fail, and relocate, so the same container may have different IP addresses from one moment to the next. This unpredictability makes IP-based communication unreliable in production environments where containers are managed at scale.

What is the key difference between default bridge networks and custom networks in terms of DNS?

Custom networks have automatic DNS resolution built-in, allowing containers to communicate using container names. Default bridge networks lack this feature and require manual `--link` options to enable DNS between containers. Custom networks are therefore the preferred approach.

Why are custom networks recommended over the `--link` option for container communication?

Custom networks are simpler and more scalable because DNS works automatically for all containers on the network without requiring manual configuration. Using `--link` requires explicit setup between each pair of containers, which becomes cumbersome. Docker Compose further simplifies this by automatically creating custom networks.