On my local machine, and inside of a test debian docker container I can resolve a dns name, thename.mycompany.com. This DNS name can not be resolved from within a drone plugins/docker build Dockerfile. Has anyone else seen anything like this? Have any ideas?
Ended up using the custom_dns field for the docker plugin and that fixed it.
I also ran into this. Not sure if for the same reason. But I wanted to post to show why it happens.
In Drone 0.6+ a network is created and attached to build containers. By doing this Docker changes how it handles DNS. It switches from using host daemon DNS to using an embedded Docker DNS server running on 127.0.0.11.
It seems plugins/docker is started and a build network is connected. When the additional network is connected (docker already attached a default ābridgeā network when container was created) it switches the DNS to the embedded DNS server described above. DNS continues to work as expected inside plugins/docker.
Now, when plugins/docker starts building an image it spins up itās own docker daemon, which we call DDplugin. When DDplugin creates containers for each step of Dockerfile it will set DNS to some other DNS servers with message:
INFO[0039] No non-localhost DNS nameservers are left in resolv.conf. Using default external servers: [nameserver 8.8.8.8 nameserver 8.8.4.4]
INFO[0039] IPv6 enabled; Adding default IPv6 external servers: [nameserver 2001:4860:4860::8888 nameserver 2001:4860:4860::8844]
It seems since DDplugin is using DNS of 127.0.0.11 that is a ālocalhostā DNS server and causes DDplugin to start containers with DNS servers 8.8.8.8 and 8.8.4.4.
Now here is what decides if your setup will work or not. If you have access to use 8.8.8.8 and 8.8.4.4 things will still work. If you are on a network that blocks external DNS services and you have to use specific internal DNS servers then it will fail. Specifying custom_dns for the plugin can get around this then.
To expand on the workaround provided by @jmccann , you can also set the custom dns globally using the global environment variable feature [1]
- name: PLUGIN_CUSTOM_DNS
value: 1.1.1.1 # your dns address here
This problem seems to be persisting to date. It seems like a major bug to me to leak DNS requests to third party hostnames that the user has never configured or authorized for use.
root@las1:~# docker images | grep plug
plugins/docker latest 29c70b6af6af 2 months ago 182MB
root@las1:~# docker rmi plugins/docker
Untagged: plugins/docker:latest
Untagged: plugins/docker@sha256:1d4743c50cfe06e84962a45337dc7ac200982c00c98d67852b54bf9475d37358
Deleted: sha256:29c70b6af6af2fb454b19ce8f7b51b35a5655c8398b6dd76938f6184ff7fb05a
Deleted: sha256:2b52935f5ac6ecad710c8ec05acfd172929022010e2fce6feee1d9c967f46013
Deleted: sha256:9bceba7972a6ac6471f2515c3dbf869abd8ff74964bb5ecdae340ad4554f7653
Deleted: sha256:f9d5a45945e1f93e2a2e8a81ac440f0309409d836d119de67dbd61572f7e8c2c
Deleted: sha256:01a062ec6974efa55446c81a9276f20d27d3635fe025d071a6637cfc2dfb13dc
Deleted: sha256:6a07e4cab25962d6b819f0508607d0c8d98e91121a83dbfbd6aec202eebded77
Deleted: sha256:e1bc276529a5de677bb7c41f28c76fce259b69fe35de7a8d1e443fc630c185e7
Deleted: sha256:6789d66fedded194adfa52ade2cf79aa4f84a244b58c2e2e57a85c5883f44b2d
Deleted: sha256:649f547f80b238767bc19dea8cf242adc2fa7164d3aff47b5e2a45dd873bdd6e
Deleted: sha256:1ee98fa99e925362ef980e651c5a685ad04cef41dd80df9be59f158cf9e52951
Deleted: sha256:78c8e55f8cb4c661582af874153f88c2587a034ee32d21cb57ac1fef51c6109e
Deleted: sha256:7bff100f35cb359a368537bb07829b055fe8e0b1cb01085a3a628ae9c187c7b8
root@las1:~# date -u
Wed Feb 12 06:01:13 UTC 2020
root@las1:~#
... start build, wait a sec ...
root@las1:~# docker ps | head -2
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4bceb265b144 plugins/docker:latest "/usr/local/bin/dockā¦" 7 seconds ago Up 3 seconds 2375/tcp drone-xl5Q9qFh4kAv2TI9KEp8
root@las1:~#
root@las1:~# docker exec -ti drone-xl5Q9qFh4kAv2TI9KEp8 /bin/sh -c "docker run -ti ubuntu /bin/bash -c 'cat /etc/resolv.conf'"
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
5c939e3a4d10: Pull complete
c63719cdbe7a: Pull complete
19a861ea6baf: Pull complete
651c9d2d6c4f: Pull complete
Digest: sha256:8d31dad0c58f552e890d68bbfb735588b6b820a46e459672d96e585871acc110
Status: Downloaded newer image for ubuntu:latest
search CORRECT-DHCP-DOMAIN-NAME-REDACTED
options ndots:0
nameserver 8.8.8.8
nameserver 8.8.4.4
root@las1:~# docker exec -ti drone-xl5Q9qFh4kAv2TI9KEp8 /bin/sh -c "docker info | grep -i version"
Server Version: 18.09.0
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Kernel Version: 4.15.0-76-generic
WARNING: No swap limit support
root@las1:~#
1 Like
same problem.
Why do containers raised by dind use 8.8.8.8 and 8.8.4.4 DNS serverļ¼
Same here - using plugins/docker with drone on kubernetes
I would recommend asking this question in the Docker Community Forum since Drone has no influence over how DNS is configured inside a Docker-in-Docker container. The Docker maintainers are the most qualified individuals to answer this question and explain how DNS works when using Docker-in-Docker.
DNS inside the Docker-in-Docker container is determined by the parent environment; this is not something that Drone has any influence over. In Kubernetes you might need to set mtu for example [1] or you may need to configure custom DNS as suggested above.
[1] https://discourse.drone.io/t/drone-on-kubernetes-with-docker-plugin-strange-network-problem/8420/4