…DNS resolution only works between containers in same virtual docker network subnet
Short description of when routing is needed
A subnet means all the numbers in beginning of IP address must be the same. Only the end different. The subnet mask determines how many numbers have to be the same. All computers on the same network switch, must have the same numbers at beginning match. This is called a subnet.
Any computer that has a IP address with different subnet numbers, it is assumed that a router is required to forward network packets, to that IP address. Even with virtual subnets.
My reverse proxy’s docker networking configuration:
docker inspect nginx-reverse-prxy
...
"Networks": {
"nginxbridge": { ... }
}
...
It is named nginxbridge. It has its own docker virtual subnet. But execute a request to make http connection to a container on another docker virtual subnet in same host, and it returns:
root@11367e58420c:/# curl http://php-redis curl: (6) Could not resolve host: php-redis
Not “could not connect”, which is what you get when it CAN resolve the DNS. But iptables isn’t configured to route between the virtual subnets. It says “cannot resolve”.
The configuration for php-redis:
docker inspect php-redis
...
"Networks": {
"redis-guestbook-in-dockercompose_default": {
...
"DNSNames": [
...
"php-redis",
"a0f13febd6ea"
]
...
}
See that it is in network “redis-guestbook-in-dockercompose_default”, not “nginxbridge”. But it does have DNS name. So it seems that DNS resolution, doesn’t cross docker network subnets. And I think I experimented before, that routing between docker virtual subnets, even if you had the IP address of the other container, doesn’t exist.