compose: dns configuration option does not work on docker-compose==1.6.0

Dear all,

We were facing the same issue. Starting a container with docker run --dns was working fine, the file /etc/resolv.conf inherits the DNS servers of the host. However, using the dns option in docker-compose.yml leaves the default content:

search name.of.our.domain
nameserver 127.0.0.11
options ndots:0

After adding network_mode: bridge in the YML file it works, the file resolv.conf gets the configured DNS servers. I thought bridge was the option used by default.

I wonder whether this could be documented somewhere alongside the dns option? I couldn’t find the solution until reading all different workarounds here.

+1 same issue for me

this issue is not solved @mmarzantowicz open it again,

Resolved my issue by creating and adding the below to /etc/docker/daemon.json on the Centos:7 host.

{
  "dns-opts":[
    "ndots:1"
  ]
}

This marks year five.

Please, reopen this. I also can confirm this issue on Ubuntu 14.04. Restarting Docker service is what solves the issue.

I am not completely sure what is wrong but I am not able to add e.g. dns record to /etc/hosts at all even I am using just docker-compose up -d on a single docker-compose.yml with one service.

I am trying to setup nexus repo:

version: '2' 
services:
    nexus:
        hostname: nexus
        domainname: somedomain.net
        container_name: nexus
        image: sonatype/nexus:oss
        networks:
            server-net:
                ipv4_address: 172.19.0.7
        ports:
            - "8081:8081"
        volumes:
            -  /srv/docker/nexus/nexus-data:/sonatype-work
        dns:
            - 8.8.8.8
        dns_search:
            - somedomain.net
        environment:
            - MAX_HEAP=768m

networks:
    server-net:
        driver: bridge
        ipam:
            driver: default
            config:
                - subnet: 172.19.0.0/24
                  gateway: 172.19.0.1

I have verified that it works with --dns flag on normal docker run

docker run -d -p 8081:8081 \
    --name nexus \
    --dns 8.8.8.8 \
    sonatype/nexus

However, it does not work when I create a network manually like this:

docker network create server-net
docker run -d -p 8081:8081 \
    --name nexus \
    --net server-net \
    --dns 8.8.8.8 \
    sonatype/nexus

In this case, it is not there. Very interesting … Why specifying network prevents me from adding DNS record to /etc/hosts?

Adding this into docker-compose.yml solved my DNS issues:

dns: 8.8.8.8
dns_opt:
  - use-vc
  - no-tld-query

Can somebody reopen this? This is 5 years already, people still having problem with it. @ulyssessouza

Same problem, docker version 17.04.0-ce, docker-compose version 1.12.0, build b31ff33

I had the same problem under docker-compose 1.11. Solved adding network_mode to the yaml configuration.

@uy-rrodriguez I also always thought the default network mode was bridge, but turns out it’s not the case. It is mentioned in the compose documentation:

By default Compose sets up a single network for your app. Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by them at a hostname identical to the container name.

This issue is a critical one, please open it ASAP. Without ability to properly define DNS, compose is a harming manner, especially on production. Please consider removing 1.6 until problem is not fixed.

For me the problem is not fix. When I with a ‘docker run --dns’ command, the DNS work but not with the docker-compose file.

Second this. Running on debian stretch:

# dc version
docker-compose version 1.19.0, build 9e633ef
docker-py version: 2.7.0
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.1t  3 May 2016

 # docker --version
Docker version 17.12.0-ce, build c97c6d6

dns resolving for internal addresses is not working:

version: "3"
services:
  client1:
    build: ./testclient
    cap_add:
     - NET_ADMIN
    dns: 10.100.128.77
    image: "oclient:testing"
    container_name: "client1"
    privileged: true
    tty: true
    networks:
      nwclient1: {}
    volumes:
     - ./../:/ovpnconfig
    command: openvpn /ovpnconfig/client1.ovpn
  client2:
    build: ./testclient
    cap_add:
     - NET_ADMIN
    dns: 10.100.128.77
    image: "oclient:testing"
    container_name: "client2"
    privileged: true
    tty: true
    networks:
      nwclient2: {}
    volumes:
     - ./../:/ovpnconfig
    command: openvpn /ovpnconfig/client2.ovpn
networks:
  nwclient1:
    #internal: true
  nwclient2:
    #internal: true

Container:

dc run --rm client1 bash
bash-4.4# cat /etc/resolv.conf
search de.company.int
nameserver 127.0.0.11
options ndots:0
bash-4.4#

Host:

cat /etc/resolv.conf
# Generated by NetworkManager
search de.company.int
nameserver 10.100.128.77
nameserver 10.100.128.80

Starting regular docker run with --dns option works.

I investigate on my side and I found my problem. I cannot speak for everybody but here is what I found:

Setting the property: net: “host” in the docker-compose file or --net host in the docker run command will result in the ports not displayed when doing a docker ps. It is normal because setting this property let the container inherits the host network settings.

As per documentation, this configuration is not recommend so I change it to: net: “bridge” (default if not specified) and added a DNS on my docker host to solve my communication problems.

@mmarzantowicz also pls confirm if you are using fedora/centos/RHEL ? If yes, we have a known issue and the workaround is to disable firewalld.

dns configuration only applies to the default bridge network. If you have compose service to use a network (which is the case until you set network_mode: bridge the DNS configuration has no impact on container. This is not specific to compose. Ability to customize DNS resolution would have to apply on the network itself. Might be possible if you set adequate driver_opts for this purpose, I haven’t checked the default driver supports this.

See the related posts, there is a PR opened to fix it, but not yet merged.

Setting the dns in docker-compose.yml is one option. The real problem is the /etc/resolv.conf file on the host system, this generated by a network manager and should be a symlink. Docker containers use this file on the host system:

In the absence of the --dns=IP_ADDRESS…, --dns-search=DOMAIN…, or --dns-opt=OPTION… options, Docker uses the /etc/resolv.conf of the host machine (where the docker daemon runs). While doing so the daemon filters out all localhost IP address nameserver entries from the host’s original file.

Filtering is necessary because all localhost addresses on the host are unreachable from the container’s network. After this filtering, if there are no more nameserver entries left in the container’s /etc/resolv.conf file, the daemon adds public Google DNS nameservers (8.8.8.8 and 8.8.4.4) to the container’s DNS configuration. If IPv6 is enabled on the daemon, the public IPv6 Google DNS nameservers will also be added (2001:4860:4860::8888 and 2001:4860:4860::8844).

In my case upgrading to Ubuntu 17.04 probably triggered NetworkManager to misconfigure /etc/resolv.conf. As is shown here, sudo dpkg-reconfigure resolvconf fixed the issue for me.

You can be right if DNS are down by docker’s bug: https://github.com/docker/docker/issues/11407 But I’ll wait till this one is resolved and then try again.

Till then docker, so long, and thanks for all the fish…

DNS is configured differently when using a custom network (as is the case when using v2 of the Compose file format), but the dns setting is still respected. From the Docker networking docs:

The IP addresses passed via the --dns option is used by the embedded DNS server to forward the DNS query if embedded DNS server is unable to resolve a name resolution request from the containers. These --dns IP addresses are managed by the embedded DNS server and will not be updated in the container’s /etc/resolv.conf file.