Docker Community Forums

Share and learn in the Docker community.

Container can't connect to another container on same host using external DNS or host IP

docker
dns

(Brendan Fields) #1

I have the following setup…

  • Public DNS entry to point to a digital ocean droplet, lets call it foo.com

  • On the DO droplet, docker is running with a docker compose file with multiple services

  • The docker compose file is using the default bridge network

  • One service, lets call it service A, in the compose file handles http/https traffic (ports 80, 443)

  • Service B needs to do http(s) requests to service A and uses the public DNS foo.com as the host when performing these requests because I don’t want B to depend on A running on the same docker host and network. B and A will most likely end up on separate hosts/networks down the road.

From container B, when I do curl http://foo.com the request just times out.

Doing ping foo.com from inside B correctly resolves to the docker host IP address (the DO droplet) and the pings return.

My expectation for the curl request is that DNS would resolve to the docker host IP address, send the request there, which should then be be handled by the docker client and handed off to service A because ports 80, 443 are exposed.

Performing curl http://foo.com from the docker host or any other computer connected to the internet works correctly and requests are routed to service A. Why will this simple request not work from within the containers?


(Sam) #2

is this from inside the container b? not clear from the text.

i thing timed out means the host did not respond, not that the host was not found…
you could test by changing the foo.com to foo1.com (which should be a non existent host name),
and should return host not found

when I do that I get

curl fribble.sam.com
curl: (6) Could not resolve host: fribble.sam.com


(Brendan Fields) #3

Thanks for the reply. I clarified the ping test, yes it is from inside B.

Doing curl for an invalid host does result in a Could not resolve host response. So DNS resolution does seem to be working.

I used tcpdump to look at the traffic and could see that DNS did seem to be resolving. Here is a capture of that. I’ve replaced the IP of foo.com with foo.com so the actual IP is kept private.
172.28.0.3 is the IP address of container B
172.28.0.6 is the IP address of container A
172.28.0.1 is the docker gateway

I’m not experienced in tcpdump to make too many conclusions from this logging, but maybe it is helpful for someone else.

01:44:24.677632 IP 172.28.0.3.51806 > 67.207.67.2.53: 25680+ AAAA? staging.mochilafulfillment.com. (48)
01:44:24.677733 IP 67.207.67.2.53 > 172.28.0.3.46475: 56602 1/0/0 A 159.89.41.110 (64)
01:44:24.709364 IP 67.207.67.2.53 > 172.28.0.3.51806: 25680 0/1/0 (107)
01:44:24.737688 IP 172.28.0.3.45636 > foo.com.443: Flags [S], seq 687390928, win 29200, options [mss 1460,sackOK,TS val 130634531 ecr 0,nop,wscale 7], length 0
01:44:25.735689 IP 172.28.0.3.45636 > foo.com.443: Flags [S], seq 687390928, win 29200, options [mss 1460,sackOK,TS val 130634781 ecr 0,nop,wscale 7], length 0
01:44:27.739669 IP 172.28.0.3.45636 > foo.com.443: Flags [S], seq 687390928, win 29200, options [mss 1460,sackOK,TS val 130635282 ecr 0,nop,wscale 7], length 0
01:44:29.683621 ARP, Request who-has 172.28.0.3 tell 172.28.0.1, length 28
01:44:29.683657 ARP, Request who-has 172.28.0.1 tell 172.28.0.3, length 28
01:44:29.683669 ARP, Reply 172.28.0.1 is-at 02:42:72:a6:6d:cf, length 28
01:44:29.683680 ARP, Reply 172.28.0.3 is-at 02:42:ac:1c:00:03, length 28

(Brendan Fields) #4

I’d like to understand this issue and resolve it, but in the mean time I did come up with a workaround by specifying foo.com as an alias for service A in the docker compose file. Seems to work so far, I’m not sure if there are any potential issues in doing this down the road. Its definitely a band-aid I’d like to not keep.


(Johnfo) #5

Did this ever get resolved? I seem to have hit an identical issue: I’ve tried moving a docker based server (happens to be sonarqube) onto a machine I used for building. The build containers can’t seem to reach sonarqube. The sonarqube service is actually proxied behind an nginx container: they are setup using docker-compose and using a network declared as

networks:
sonarnet:
driver: bridge

between then. The other containers are all “standalone” - I start and stop them manually as required. [They are Jenkins build slaves].


(Johnfo) #6

OK if I use --net=host it fixes my specific issue. Have to say I think the default is possibly wrong, but there we are. Not yet tried a scenario where I have a mini-swarm (say two or three containers run via docker-compose.yml) which use a service which happen to be implemented by an independent container on the same VM. I would like to know how to solve that…