Container Networking Foundations: Bridge, Host, None, User-Defined Networks, Endpoints, and Namespaces: Concepts, Architecture, and Mental Model

1. Why container networking needs its own mental model

Earlier chapters separated client, daemon, image, container, and process state. Networking adds another set of objects that can fail independently. A container can be running and healthy while attached to the wrong network. Two containers can be on the same Docker host but intentionally isolated. A published port can exist while the application is not listening. Conversely, two containers on the same user-defined bridge can communicate directly without any published host port.

The practical goal is to stop treating a failed request as one vague “Docker network problem.” Instead, identify which layer owns the failure: application listener, container network namespace, endpoint attachment, Docker network driver, DNS, host routing/firewall, or an external path.

2. Mental model: from process socket to peer

A normal bridge-networked container has its own network namespace. Inside it, the application sees an interface such as eth0, an IP address, a route, and DNS configuration. Docker creates an endpoint that connects this namespace to the selected Docker network. On Linux bridge networks, that endpoint is commonly implemented through a virtual Ethernet path into a host-side software bridge. Host routing, NAT/masquerading, and firewall rules then govern traffic leaving that network or entering through published paths.

flowchart TD
  P[Application process socket bind/connect] --> N[Container network namespace eth0 + IP + routes + DNS]
  N --> E[Docker endpoint virtual interface attachment]
  E --> D[Network driver user-defined bridge]
  D --> H[Host routing + firewall iptables by default / nftables optional]
  H --> C[Peer endpoint on same network]
  H --> X[External network via host routing/NAT]
            

Do not read the diagram as a promise that every platform exposes identical host interfaces. Docker Desktop runs Linux containers behind a managed VM boundary, so the same logical network object can be implemented differently from a native Linux Engine host. The Docker API and container-visible state remain the portable evidence layer.

3. Four different things called “the network”

4. Bridge, host, and none are different isolation contracts

Docker documents host networking for Linux Engine and, as an opt-in feature, Docker Desktop 4.34+. Desktop host networking is layer-4 only and has additional restrictions. Treat host mode as platform-sensitive, not as a portable shortcut.

5. DNS differs between default and custom networks

Containers attached to the default bridge receive resolver configuration based on the host. Containers attached to a custom network use Docker's embedded DNS service, currently exposed inside the container at 127.0.0.11. The embedded resolver supports name/alias lookup for peers on the same user-defined network and forwards external lookups to configured host DNS.

This is why service name is normally a better identity than container IP. Endpoint addresses can change after recreation; a name on the intended network expresses the relationship rather than an incidental allocation.

6. Read-only inspection before changing anything

docker version
docker info
docker context show

docker network ls
docker network inspect bridge
docker network inspect host
docker network inspect none

# Existing containers only; no state change:
docker ps -a --no-trunc
docker inspect <container> --format '{{json .NetworkSettings.Networks}}'
docker port <container>

On an authorized native Linux host, additional read-only evidence may include ip link, ip route, and firewall-rule inspection. Do not edit Docker-managed firewall rules as a troubleshooting shortcut. On Docker Desktop, treat VM-internal host networking as an implementation boundary rather than assuming the Windows/macOS host directly owns Linux bridge devices.

7. Firewall backend is host policy, not container application state

Docker Engine creates firewall rules for bridge networking. The current default backend is iptables. Engine 29 introduced an experimental nftables backend selectable by daemon configuration; Docker explicitly warns that behavior can change and that overlay-network migration is not complete. That makes backend choice a version-sensitive host assumption.

For this chapter, the safe approach is read-only: record Engine version and any available firewall-backend evidence, then diagnose container and Docker network state first. Chapter 19 will treat port publication and firewall/NAT behavior in depth.

8. Evidence inventory for a reproducible network state

9. Misconceptions to retire

• “localhost means the Docker host.” In a bridge-networked container, localhost refers to that container's own network namespace.
• “same host means containers can talk.” User-defined networks intentionally scope membership and isolation.
• “EXPOSE opens a port.” It does not publish anything; publication is a separate host-exposure decision.
• “container IP is stable service identity.” It is an allocation, not a durable contract.
• “host mode is faster, so use it everywhere.” It trades away isolation/port-mapping semantics and is platform-sensitive.

Knowledge check

Official references and version notes

• Docker Docs — Networking overview: container-visible interfaces, routes, gateways, DNS, and built-in drivers.
• Docker Docs — Bridge network driver: default versus user-defined bridges, DNS, isolation, masquerading, and dynamic connect/disconnect.
• Docker Docs — Host network driver: shared host networking, ignored port publishing, Linux support, and Docker Desktop limitations.
• Docker Docs — None network driver: isolated network stack with loopback only.
• Docker CLI — docker network create: bridge creation, --internal, IPAM, labels, and network scope.
• Docker Docs — Packet filtering and firewalls: firewall rules for bridge networks and backend selection.
• Docker Docs — Docker with iptables: current iptables rule ownership and DOCKER-USER behavior.
• Docker Docs — Docker with nftables: Engine 29 experimental nftables backend and migration caveats.
• Docker Desktop networking how-tos: VM-boundary networking and host.docker.internal.
• Docker Engine 29 release notes: current Engine 29 networking changes and compatibility notes.