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

Created on 12 Sep 2018  路  18Comments  路  Source: docker/compose

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.

arenetworking kinquestion

Most helpful comment

@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.

All 18 comments

It is desirable to use a custom dnsmasq container so that I can use consul DNS across all of my containers. Example, here I look up DNS using consul DNS.

/ # dig @dnsmasq consul.service.consul

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

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

;; ANSWER SECTION:
consul.service.consul.  0   IN  A   172.16.238.5
consul.service.consul.  0   IN  A   172.16.238.3
consul.service.consul.  0   IN  A   172.16.238.4

;; ADDITIONAL SECTION:
consul.service.consul.  0   IN  TXT "consul-network-segment="
consul.service.consul.  0   IN  TXT "consul-network-segment="
consul.service.consul.  0   IN  TXT "consul-network-segment="

;; Query time: 0 msec
;; SERVER: 172.16.238.2#53(172.16.238.2)
;; WHEN: Wed Sep 12 05:05:22 UTC 2018
;; MSG SIZE  rcvd: 206

The only fix currently is to statically set the DNS and not use the docker-compose service name in the dns YAML key.

ref: https://github.com/samrocketman/docker-compose-ha-consul-vault-ui/commit/3b5f422dbf386056d1a11ba9e45de05a98a9487f

That is to say, the bug still exists but there's currently a workaround until it is fixed.

Hi @samrocketman

As far as I can tell, the issue you're reporting is a Docker networking issue, not a Compose issue. If you concur, please open an issue on the moby/moby tracker where it can more readily be addressed.

I don't understand if it's a docker networking issue. I've only seen docker-compose service aliases used in docker-compose as hostnames. So I assumed it was this project.

I can copy my issue to moby/moby if that's what you think is appropriate. I don't have the expertise to determine which project is appropriate to address the root cause of this issue.

Please let me know.

I'd like to see this issue get resolved as well. Is there an update on whether this is actually a docker-compose issue or does a new issue need to be filed with Docker? If it does need to be filed with moby/moby, can someone with an understanding of why it's a moby/moby issue expand upon it so we can file it correctly? Thanks.

This is because a DNS server should be specified by IP-address, so using a name won't work (unless some step was added to resolve the IP based on the name, and use that).

There's a tracking issue for that in the cli repository; https://github.com/docker/cli/issues/385 (I think there's also one in the Moby repository, but I'd have to search for that)

I understand that /etc/resolve.conf only takes IP鈥檚 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鈥檚 not ideal because I need to statically set the network and IP.

In case someone finds it useful.

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.

This is exactly what I'd like to see as well. Hardcoding IP addresses for this specific purpose is less than ideal.

I had the same problem.

And I thought about another solution. This solution is only available for nginx container:

version: '3'
services:
  openresty:
    image: openresty/openresty:1.13.6.2-alpine
    volumes:
      - ./nginx.conf:/usr/local/openresty/nginx/conf/nginx.conf
    ports:
      - 80:80
    dns:
      - 127.0.0.1
    links:
      - dns-server
  dns-server:
    image: jpillora/dnsmasq
    cap_add:
      - NET_ADMIN
    ports:
      - 53:53/tcp
      - 8080:8080

nginx.conf has such a code snippet:

stream {
    upstream dns {
        server dns-server:53;
    }

    server{
        listen 53 udp;
        proxy_connect_timeout 1s;
        proxy_pass dns;
    }
}

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This is still desirable so should not be stale IMO.

This issue has been automatically marked as not stale anymore due to the recent activity.

This is still desirable so should not be stale IMO.

Same issue. I expect this behaviour as well.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This is still desirable so should not be stale IMO.

This issue has been automatically marked as not stale anymore due to the recent activity.

@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.

Was this page helpful?
0 / 5 - 0 ratings