How to tell docker to use host dns configuration?

Question

I am working behind a company proxy. Because of the many limitations enforced, I have to switch to public network when I come to build my docker images (mainly ubuntu-based images). The build is performed on the same computer (thus, the same dns conf).

Apart from the build, I always run my containers behind this proxy. The company also (and indeed) has its own dns.

Unfortunately, I don't understand how to pass the host dns to the containers the "proper way" and don't understand how docker manages to build the containers resolv.conf.

When I look at my host, I see such a conf :

$ cat /etc/resolv.conf

nameserver 8.8.8.8
nameserver 8.8.8.4
nameserver 10.xxx.yyy.z
search rennes.mycompany.fr

And from within my containers, I see:

search rennes.mycompany.fr
nameserver 127.0.0.11
options ndots:0

What looks odd to me is that only a part of the host configuration can be found in the container... And when I try to reach any company-hosted name from the container, I have a name resolution failure.

But if I add the host's resolv.conf nameserver to the container's one, it works:

$ echo nameserver 192.168.1.1 >> /etc/resolv.conf

So, this is indeed not the way to do it... but I am not sure how I should perform it. I tried to add the 'dns' to my services in the docker-compose, but I didn't work (or not a way I understand), and the documentation there is quite spartan...

Is there a way to tell docker to use/share host's dns configuration? May my problem come from my building the image outside of the company network?

EDIT: the docker-compose.yml

version: '3.3'
services:
  my-apache:
    image: apache:latest
    ports:
      - 8088:80
    networks:
      - my-project-net
    dns: 
      - 192.168.1.1
    depends_on:
      - my-project
  my-project:
    image: my-project:latest
    networks:
      - my-project-net
    dns: 
      - 192.168.1.1

networks:
  my-project-net:
    driver: bridge

only 'my-project' requires access to company dns, but I added dns to both in case I missed some clue...

EDIT 2 : few more details and attempts

• docker version : 18.03.0-ce, build 0520e24
• docker-compose version : 1.18.0, build 8dd22a9

The name I try to resolve looks like this :

some-pf-db.network.mycompany.fr

The (modified) docker daemon conf looks like this :

$ cat /etc/docker/daemon.json :

{
    "insecure-registries": [
        "some.test.registry.mycompany.fr:5000"
    ],
    "log-driver": "json-file",
    "log-opts": {
        "max-file": "3",
        "max-size": "10m"
    },
    "dns-opts": ["ndots:15"]
}

Following @BMitch link, I tried to update docker daemon (+restart) with the ndots options up to 15 (don't think I'd need that many, but it's the lazy way!)... and unfortunately it didn't solve the problem. The new value replaces the former one within the container, but it keeps failing reaching the dns

could not translate host name "some-pf-db.network.mycompany.fr" to address: Temporary failure in name resolution

EDIT3 : I was looking at the wrong container... so, changing the threshold for dots (ndots) up to (eg.) 15 within the docker daemon conf (/etc/docker/daemon.json) AND removing the "dns" param from the service makes the magic operate! I have now access to my company dns for names (with a lot of dots in them!!)

Answer 1

The 127.0.0.11 entry inside the container is expected even when you override DNS on the container. This points back to the loopback interface inside the container which has a mapping for port 53 to go back to the docker engine for DNS resolution. You need docker to do the DNS resolution to give you container to container networking with DNS for discovery.

You should still see the docker engine call out to your DNS server even with the 127.0.0.11 entry inside the container, so it's not a bug, or lack of configurability, you just don't see this configuration from inside the container.

We'd need more details on the actual issue you are encountering, but one possible problem I've seen from this before is DNS not resolving external hosts without a fully qualified name in some specific scenarios. You can read about that in this issue/thread here: https://github.com/moby/moby/issues/32093