DOCKER - 16 Network and DNS

In this lesson you learn how Docker's built-in DNS works and how it impacts containers on default versus custom networks. Containers come and go all the time, so relying on IP addresses to make them communicate is fragile. Docker solves this with built-in DNS naming: the container name becomes its hostname inside the network.

Take the previous example with two nginx containers on a custom network my_app_net. Because my_app_net is not the default bridge, every container attached to it gets automatic DNS resolution for the names of the other containers on the same network. Try it:

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

What this changes for you

  • Custom networks have built-in DNS: containers find each other by name even if IPs change.
  • Default bridge does NOT have DNS: you must use the legacy --link option when creating a container to wire names manually.
  • Best practice: always create a dedicated network per application. It removes the need for --link and keeps unrelated apps isolated.
  • Docker Compose (covered later) takes this further: it automatically creates a virtual network per application stack, so inter-container communication "just works".

This pattern solves a huge problem when you build multi-container apps: a PHP container can call its MySQL companion by name regardless of which IP each gets at startup. In production with Docker Swarm and many hosts, the same logic applies, so container names are something you can really count on. See you in the next video.

Summary

This lesson covers Docker's DNS and networking capabilities, explaining how container naming solves the problem of dynamic IP addresses. It compares default networks (which lack DNS) with custom networks (which provide automatic DNS resolution), and introduces the --link option as an alternative for bridge networks before recommending custom networks as the standard approach for container communication.

Key points

  • Container IPs are dynamic and unreliable—DNS-based naming provides stable communication between containers
  • Custom Docker networks provide automatic DNS resolution for all containers on that network; default bridge network does not
  • The --link option enables DNS on default bridge networks but is less practical than creating dedicated networks
  • Container names act as hostnames (DNS equivalent), allowing containers to discover each other regardless of IP assignment
  • Production environments benefit from custom networks to ensure consistent container-to-container communication as containers start, stop, and migrate
  • Docker Compose further simplifies this by automatically creating custom networks for applications

FAQ

Why can't containers rely on IP addresses for communication?

Container IP addresses are dynamic and unpredictable. Containers can be started, stopped, replaced, or rescheduled at any time, changing their IP addresses. Container names, by contrast, remain constant and serve as a reliable communication identifier.

What's the difference between default networks and custom networks regarding DNS?

Default bridge networks do not provide automatic DNS resolution between containers. Custom networks, however, have built-in DNS support that automatically resolves container names to IP addresses for all containers on that network.

When should you use the --link option instead of creating a custom network?

The --link option is available for default bridge networks but is considered less practical than creating dedicated custom networks. Custom networks are the recommended approach as they simplify configuration and scale better in multi-container applications.