Docker Container Networking - Bridges, Custom Networks, and DNS

Docker networking is the connective tissue that turns isolated containers into cooperating services. Every container the Docker daemon launches is attached to a network, and the network it joins determines whether it can talk to other containers, whether it can resolve them by name, and whether it is reachable from the outside world. Without an understanding of bridges, drivers, and the embedded DNS resolver, multi-container applications quickly devolve into hardcoded IP addresses, brittle --link flags, and accidental cross-environment leakage.

The bridge driver is the workhorse for single-host Docker deployments. Docker ships with a default bridge network for backwards compatibility, but it has a deliberate quirk: containers on the default bridge cannot resolve each other by name. The moment you create a user-defined bridge network, Docker activates an embedded DNS server at 127.0.0.11 inside each attached container, and service discovery by container name starts to work. This single behavior is the foundation of every modern Docker Compose stack, every microservices topology on a single host, and the mental model you need before moving on to overlay networks for Swarm or CNI plugins for Kubernetes.

Objectives

Upon completion of this intermediate level lab, you will be able to:

• Inspect the default bridge network and observe its lack of name-based DNS resolution between containers.
• Create a user-defined bridge network with docker network create and attach containers to it with the --network flag.
• Use Docker's embedded DNS at 127.0.0.11 to resolve and reach containers by name on a user-defined bridge.
• Build a Redis-plus-client topology where the client connects to Redis using the container name as the hostname.
• Verify network isolation between two custom bridges and deliberately bridge them with docker network connect.

Who is this lab for?

This lab is designed for:

• Developers building multi-container applications who need service discovery without external orchestration
• Platform engineers wiring containers together on a single host before moving to Compose or Kubernetes
• DevOps engineers troubleshooting "why can container A not reach container B" symptoms in production