compose: bridge DNS does not work when referencing a service alias as dns

Description of the issue

Referencing the dns key in YAML does not work when the value is a service alias of another container in the docker-compose.yml file.

Sample compose file.

networks:
  internal:
     driver: bridge
services:
  dnsmasq:
    # ... some container configuration which should be reachable from the DNS host "dnsmasq"
    networks:
      - internal
  my-service:
    # NOTE: setting DNS to docker-compose service alias does not work
    dns: dnsmasq
    networks:
      - internal

Context information (for bug reports)

$ docker-compose version
docker-compose version 1.22.0, build f46880fe
docker-py version: 3.4.1
CPython version: 3.6.6
OpenSSL version: OpenSSL 1.1.0f  25 May 2017
$ docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:24:56 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:23:21 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Broken config https://github.com/samrocketman/docker-compose-ha-consul-vault-ui/blob/03ba4d1c5875e3b1c10d85425316ffa7d064ca74/docker-compose.yml

Steps to reproduce the issue

  1. docker-compose run dns-troubleshoot
  2. dig example.com
  3. dig @dnsmasq example.com

Observed result

dig example.com fails with the following message:

/ # dig example.com
; <<>> DiG 9.10.4-P3 <<>> example.com
;; global options: +cmd
;; connection timed out; no servers could be reached

/ # cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0

However, dig @dnsmasq example.com succeeds.

/ # dig @dnsmasq example.com

; <<>> DiG 9.10.4-P3 <<>> @dnsmasq example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4516
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		4335	IN	A	93.184.216.34

;; Query time: 0 msec
;; SERVER: 172.19.0.2#53(172.19.0.2)
;; WHEN: Wed Sep 12 04:53:29 UTC 2018
;; MSG SIZE  rcvd: 56

Expected result

I expect both dig example.com and dig @dnsmasq example.com to work the same way.

Additional information

I installed docker-compose by downloading the go binary from GitHub releases and adding it to a location available in my $PATH.

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 2
  • Comments: 32 (2 by maintainers)

Commits related to this issue

Most upvoted comments

@shin- can we remove the kind/question label? This is not a question. It is a docker-compose enhancement request originally reported as a bug since it made intuitive sense. Considering most things can be referenced by service name in the compose file it made sense you should be able to do the same in the DNS field and have docker-compose translate that to the service IP.

I feel like kind/question makes this issue not an obvious feature request so it has been overlooked for 2 years.

Why this is a docker-compose issue

docker-compose has some glue logic which makes using docker easy. For example, if you reference a service name foo there is no such reference in the docker daemon. docker-compose translates foo into a docker container (or group of docker containers) in dockerd backend.

The syntax exposed by docker-compose should support docker-compose services in the same way that the docker-compose syntax supports docker-compose services in other fields. To put another way, the brief syntax in docker-compose translates into API calls on the dockerd backend. This translation should occur for the service name in the DNS field.

I’ve updated the labels. From what @thaJeztah said, it appears that we need to make Engine changes before this is possible.

I understand that /etc/resolve.conf only takes IP’s in Linux (and why that is). My hope is that docker-compose would resolve the DNS IP from the compose service under the hood and do the right thing with it to expose the DNS automatically.

FWIW I have a workaround but it’s not ideal because I need to statically set the network and IP.

In case someone finds it useful.

Would need to extend https://github.com/compose-spec/compose-spec/blob/master/spec.md#dns so that we clarify a service name can be used to set dns. In terms of implementation, this implies an implicit depends_on being set between service and dns provider