beginner~4h

Docker Networking: Bridge, Host, Overlay, DNS & Port Mapping

Docker networking is implemented by libnetwork using a pluggable driver model. The four drivers you must know cold for interviews are: bridge (default, single-host container-to-container networking),

Docker networking is implemented by libnetwork using a pluggable driver model. The four drivers you must know cold for interviews are: bridge (default, single-host container-to-container networking), host (no isolation — container shares the host's network namespace), overlay (multi-host networking for Swarm/cluster scenarios), and none (fully isolated, no networking).

Every user-defined bridge network gets automatic embedded DNS resolution: containers can reach each other by container name or Compose service name, without hardcoded IPs — this is the single most important practical fact about Docker networking for real applications.

Port mapping (-p hostPort:containerPort) is how traffic from outside the Docker host reaches a container; it works by installing iptables NAT rules (DNAT) on the host that forward traffic to the container's internal IP on the bridge network.

The default bridge network (docker0) is created automatically; containers attached to it can reach each other only by IP address — there is no automatic DNS resolution by container name on the default bridge (a frequently misunderstood limitation).
User-defined bridge networks (docker network create mynet) get a built-in DNS server (127.0.0.11 inside each container) that resolves other container names and Compose service names to their current internal IPs automatically — this is why Compose-based multi-container apps 'just work' by service name.
Host networking mode removes network namespace isolation entirely: the container binds directly to the host's network stack, sees the host's interfaces, and any port the app listens on is immediately exposed on the host with no NAT/port-mapping layer at all.
Overlay networks use VXLAN tunneling to create a virtual Layer 2 network spanning multiple Docker hosts (used by Docker Swarm, and conceptually similar to what Kubernetes CNI plugins like Calico/Flannel provide), letting containers on different physical machines communicate as if on the same LAN.
Port publishing (-p 8080:80) creates an iptables DNAT rule: traffic arriving at the host's 8080 is rewritten to the container's internal bridge IP on port 80, then routed across the bridge interface into the container's network namespace.
Each container gets its own network namespace with its own loopback, routing table, and interfaces (typically a veth pair, one end in the container's namespace, one end attached to the bridge).

docker network create app-net — creates a new user-defined bridge network with its own embedded DNS.
docker run -d --name api --network app-net myapi:1.0 — container joins app-net; reachable by other containers on app-net as hostname api.
docker run -d --name db --network app-net postgres:16 — joins the same network; api can now reach the database simply via the JDBC URL host db, no IP needed, no hardcoding.
docker run -d -p 8080:8080 --network app-net myapi:1.0 — additionally publishes port 8080 to the host so external clients (outside Docker) can reach the API.
Internally, Docker writes an iptables DNAT rule routing host:8080 traffic to the container's internal bridge IP:8080.
When api resolves db, the embedded DNS server at 127.0.0.11 inside the container intercepts the query and returns db's current internal IP — critical because that IP can change if the container restarts; DNS resolution, not a hardcoded IP, is what makes this resilient.

Microservices on a single host (or single Compose project) communicating purely by service name — e.g., an order-service calling http://inventory-service:8081/check — with zero hardcoded IPs anywhere.
Host networking for high-throughput network monitoring/proxy tools where the overhead of NAT/bridge translation is unacceptable, accepting the trade-off of losing network isolation.
Overlay networks for Docker Swarm services spread across multiple physical/virtual machines that still need to discover and call each other as if co-located.
Network segmentation: putting a public-facing API container on one bridge network and a database on a second, internal-only network, with only the API container attached to both — the database is then completely unreachable from outside that link.

Always create and use a user-defined bridge network for multi-container applications — never rely on the default bridge, which lacks automatic DNS and requires the legacy, deprecated --link flag.
Use separate networks to segment trust boundaries (e.g., a 'frontend' network and a 'backend' network), attaching shared components like an API gateway to both while keeping the database reachable only from the backend network.
Bind published ports to a specific host interface (127.0.0.1:8080:80) when a service should only be reachable locally (e.g., behind a reverse proxy on the same host), not from the network at large.
Use container/service names in connection strings, not IP addresses — container IPs are not stable across restarts.

Expecting containers on the default bridge network to resolve each other by name — they cannot; this only works on user-defined networks.
Confusing EXPOSE (Dockerfile documentation) with -p (actual port publishing) and being surprised a service is unreachable from the host despite an EXPOSE line.
Using host networking by default 'for simplicity' and unintentionally losing all network isolation and port-conflict protection between containers.
Hardcoding a container's IP address in application config — IPs are dynamically assigned and change across container recreation; always use DNS names.

Host networking mode avoids the small latency/throughput overhead of NAT and the bridge's virtual ethernet pair — relevant for network-intensive workloads (proxies, packet capture tools), at the cost of isolation.
Avoid creating excessive numbers of small, overlapping bridge networks per service when one shared network for related services is simpler to operate and equally effective for isolation needs.
For high-throughput multi-host overlay networking, ensure VXLAN encapsulation overhead is acceptable for the workload, or evaluate dedicated CNI solutions if moving to Kubernetes.

In production, terminate TLS at a reverse proxy / load balancer container (or external LB) and keep internal service-to-service traffic on an internal Docker network, only publishing the proxy's port.
Use explicit network segmentation matching your trust boundaries — database and internal services should not be on the same network as anything publicly reachable.
Document your network topology (which services are on which networks) as part of your Compose files or infrastructure-as-code, since implicit topology becomes a debugging nightmare as services grow.

Create two containers on the default bridge and confirm name resolution fails; then retry on a user-defined network and confirm it works.
Run docker network inspect on a Compose project's auto-created network to see all connected containers and their internal IPs.
Publish a port bound to 127.0.0.1 only, and confirm via curl from another machine that it's unreachable while still working locally.
Use docker exec <container> getent hosts <other-container-name> to observe embedded DNS resolution directly.

Four drivers: bridge (default, single-host), host (no isolation), overlay (multi-host VXLAN), none (fully isolated).
Only user-defined bridge networks provide automatic container-name DNS resolution — avoid the default bridge.
Port publishing (-p) creates iptables DNAT rules; EXPOSE is documentation only and has no networking effect.
Use multiple networks to enforce trust-boundary segmentation between public-facing and internal/data services.
Always reference other services by DNS name, never by container IP, since IPs are not stable across restarts.

Want a visual for this concept?

Generate a diagram tailored to “Docker Networking: Bridge, Host, Overlay, DNS & Port Mapping” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.

Practice quiz

Next Step

Continue to Docker Compose: Services, Networks, Volumes, Scaling & Health Checks →← Back to all Docker chapters