docker's embedded dns on the default bridged network

Question

This question is probably addressed to all docker gurus. But let me give some background first. I faced dns resolution problems (on docker's default network "bridge") until i read the following in the documentation at https://docs.docker.com/engine/userguide/networking/

The docker network inspect command above shows all the connected containers and their network resources on a given network. Containers in this default network are able to communicate with each other using IP addresses. Docker does not support automatic service discovery on the default bridge network. If you want to communicate with container names in this default bridge network, you must connect the containers via the legacy docker run --link option.

As the --link option is deprecated, makes any docker run command hang and finally smashes the docker daemon process (locally) i tried using a different bridged user network and pinned dummy instances to it.

docker network create -d bridge --subnet=172.15.0.0/16
  --gateway=172.15.0.1 
  -o com.docker.network.bridge.default_bridge=false 
  -o com.docker.network.bridge.enable_icc=true 
  -o com.docker.network.bridge.enable_ip_masquerade=true 
  -o com.docker.network.driver.mtu=1500 
  -o com.docker.network.bridge.name=docker1 
  -o com.docker.network.bridge.host_binding_ipv4=0.0.0.0 a

docker run --name db1 -e MYSQL_ROOT_PASSWORD=a -d mysql:5.7.16
docker run --name db2 -e MYSQL_ROOT_PASSWORD=a -d mysql:5.7.16
docker network connect --ip 172.15.0.40 a db1
docker network connect --ip 172.15.0.40 a db2

Now the resolution of services/containers named via --name works fine using ping but here is the question:

Why is service/container name resolution not possible on the default bridge network?

Would be great if any docker network guru could give a hint. Regards.

Answer 1

Why is service/container name resolution not possible on the default bridge network?

There's no technical reason this would not be possible, but a decision to keep backward compatibility.

The default ("bridge") network never supported service discovery through a built in DNS, and when the feature was under development, maintainers of some projects raised concerns that they did not want this added on the default network, as it would block alternative implementations.

In addition, custom networks are designed to explicitly allow containers to communicate. On the default network, this is achieved by disabling "inter container communication" (--icc=false), and using --link to establish a link between containers. Having automatic discovery for any container connected to the default network would make this a lot more complicated to use.

So; create a custom network, and attach containers to that network if they should be able to communicate with each other.

Note that in many cases, not all of the options you specified are needed; simply running docker network create foo should work for most use cases.