Container Networking Foundations: Bridge, Host, None, User-Defined Networks, Endpoints, and Namespaces: Configuration, Design Choices, and Tradeoffs

1. Decision table

2. Default bridge versus user-defined bridge

The legacy default bridge is daemon-wide shared state. User-defined bridges are application-scoped objects that Docker can label, inspect, configure, and attach/detach dynamically. Docker explicitly recommends user-defined bridges for most same-host multi-container applications because they provide automatic name resolution and better isolation.

That does not mean a user-defined bridge is a security boundary equal to a host firewall or separate VM. Containers on the same user-defined bridge can communicate freely with each other's exposed/listening ports. Membership therefore matters.

3. Host versus isolated networking

Host mode deliberately removes one layer of network namespace isolation. On Linux, the process uses the host network namespace, avoiding bridge NAT and separate endpoint addressing. This can reduce some networking overhead and simplify large port ranges, but it also creates host port conflicts and couples behavior tightly to platform policy.

none takes the opposite position: keep the container process/filesystem model but give the workload no normal network path. It is suitable for offline transforms, local batch steps, or tests that should prove they do not depend on network access.

4. Single-homed versus multi-homed services

A single endpoint makes reachability easy to reason about: one network identity, one peer set, one subnet/gateway context. A dual-homed service can legitimately bridge roles—for example, a frontend connected to both an ingress-facing network and an internal application network. But every additional network creates another trust path.

Do not confuse “attached to both networks” with “routing between networks.” A dual-homed container receives endpoints on both networks, but forwarding traffic between them requires additional kernel/application behavior that this chapter deliberately does not enable.

5. Internal networks

docker network create --internal creates an externally isolated network. Current Docker documentation states that containers can communicate with peers on the internal network, but no normal default route to other networks is configured and Docker firewall policy drops cross-network external traffic. This is a useful data-tier pattern when a component should not initiate arbitrary outbound traffic.

docker network create   --driver bridge   --internal   --label devops-academy.lab=network17-design   da-net17-internal

docker network inspect da-net17-internal --format   'name={{.Name}} id={{.Id}} driver={{.Driver}} internal={{.Internal}} ipam={{json .IPAM.Config}}'

docker network rm da-net17-internal

6. Static IP addressing: exception, not service-discovery default

Docker can allocate from explicit subnets and can assign a requested endpoint IP. Use that only when an integration genuinely depends on an address. Most application-to-application dependencies should use a name or alias on a scoped network because recreation can then change addresses without changing the service contract.

If static addressing is required, record the subnet, gateway, reserved ranges, ownership, collision checks, and migration plan. A hard-coded address without those controls is fragile configuration, not reproducibility.

7. iptables versus nftables: keep the abstraction boundary

On current Linux Engine, Docker defaults to iptables for bridge-network firewall rules. Engine 29 adds an experimental nftables backend selected through daemon configuration. Both are host-level implementation choices; the container still experiences interfaces, routes, DNS, and connectivity. Do not teach application teams to edit Docker-owned rule tables to make a lab pass.

If an organization chooses the nftables backend, that is a platform engineering change requiring its own migration plan, forwarding review, Swarm limitations review, and rollback. It is outside this disposable chapter lab.

8. Docker Desktop is not a native-Linux bridge host

Docker Desktop uses a managed Linux VM for Linux containers. Host networking is opt-in from Desktop 4.34+ and is documented as layer-4 only. Use Docker API/network inspection and container-visible evidence as the portable teaching layer; avoid assuming a Windows/macOS host has the same docker0/veth topology as a native Linux Engine host.

9. Worked scenario: three-tier local application

Suppose a development application has web, api, and db. A defensible design is: web on front + back, api on back + data, and db only on an internal data network. The host publishes only the web entrypoint. No component uses a hard-coded container IP.

Before executing such a topology, predict each endpoint membership and expected DNS name. After execution, verify with docker network inspect and docker inspect. Network design becomes auditable when the intended traffic matrix and actual endpoint set agree.

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.