minikube: DNS not working when building Dockerfiles FROM alpine:3.13 only in minikube

I was investigating broken docker builds because of DNS issues and narrowed it down to building FROM alpine:3.13 specifically on minikube inside virtualbox. So I don’t know if this is the right place for this bug report.

Starting with a fresh minikube / virtualbox install:

me@myhost: $ minikube start --driver=virtualbox
😄  minikube v1.18.1 on Debian bullseye/sid
    ▪ MINIKUBE_ACTIVE_DOCKERD=minikube
✨  Using the virtualbox driver based on user configuration
👍  Starting control plane node minikube in cluster minikube
🔥  Creating virtualbox VM (CPUs=2, Memory=3900MB, Disk=20000MB) ...
🐳  Preparing Kubernetes v1.20.2 on Docker 20.10.3 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v4
🌟  Enabled addons: default-storageclass, storage-provisioner
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

me@myhost: $ minikube ssh
                         _             _            
            _         _ ( )           ( )           
  ___ ___  (_)  ___  (_)| |/')  _   _ | |_      __  
/' _ ` _ `\| |/' _ `\| || , <  ( ) ( )| '_`\  /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )(  ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)

$ docker run -it alpine:3.12.4 ping google.com
PING google.com (172.217.171.238): 56 data bytes
64 bytes from 172.217.171.238: seq=0 ttl=61 time=7.985 ms
64 bytes from 172.217.171.238: seq=1 ttl=61 time=8.862 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 7.985/8.423/8.862 ms
$ docker run -it alpine:3.13 ping google.com
Unable to find image 'alpine:3.13' locally
3.13: Pulling from library/alpine
Digest: sha256:a75afd8b57e7f34e4dad8d65e2c7ba2e1975c795ce1ee22fa34f8cf46f96a3be
Status: Downloaded newer image for alpine:3.13
ping: bad address 'google.com'

Testing with debian also doesn’t show DNS issues.

What makes me think this might be a minikube issue is the fact that running the same commands on the host (Ubuntu / Pop!_OS 20.10 ) works as expected:

wapiflapi@box$ sudo docker run -it alpine:3.12.4 ping google.com
PING google.com (142.250.74.238): 56 data bytes
64 bytes from 142.250.74.238: seq=0 ttl=114 time=18.783 ms
64 bytes from 142.250.74.238: seq=1 ttl=114 time=19.358 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 18.783/19.070/19.358 ms
wapiflapi@box$ sudo docker run -it alpine:3.13 ping google.com
PING google.com (172.217.21.14): 56 data bytes
64 bytes from 172.217.21.14: seq=0 ttl=116 time=9.466 ms
64 bytes from 172.217.21.14: seq=1 ttl=116 time=9.738 ms
64 bytes from 172.217.21.14: seq=2 ttl=116 time=7.548 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.548/8.917/9.738 ms

I’m not sure how to further investigate this, or if I should submit this as a bug report at alpine?

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 6
Comments: 16 (3 by maintainers)

Commits related to this issue

Update Dockerfile to fix alpine version to avoid breaking changes. When alpine 3.13 was released I had breaking changes when building in minikube. In general I think it's better to have fixed vers... — committed to wapiflapi/openfaas-python3-fastapi-template by wapiflapi 3 years ago

Most upvoted comments

So I ran into this again today while building from a Dockerfile utilizing alpine 3.14 and found no combination of flags between --dns-proxy and --host-dns-resolver that would keep the “DNS lookup error” from happening.

I also tried and couldn’t find any working ENV vars or switches for docker build that would were reported to work: I tried DOCKER_OPTS, --dns was not accepted by docker build, and --network=host was accepted but also did not change things either for me.

I did find two ways through modifying docker daemon’s dns setting or overwriting /etc/resolv.conf in the RUN step.

Because docker daemon tries to use the host, one could probably just change the minikube VM’s resolv configuration but I did not succeed in doing so.

Here is modifying daemon’s dns setting. Affects future docker commands. Ported from this answer for minikube like so:

minikube-ssh...
$> sudo vi /etc/docker/daemon.json
# Add
...,
"dns": ["8.8.8.8"]
# Write and save
$> sudo systemctl restart docker

Then the build succeeded.

Here is overwriting the /etc/resolv.conf in the RUN step:

As described in this answer I can confirm that by prefixing my RUN command with echo "nameserver 8.8.8.8" > /etc/resolv.conf && it built successfully, without the above daemon change.

This is nice because it only affects the area that needs it, but requires modification of the Dockerfile itself.

+12

r4j4h on Oct 25, 2021

Docker Machine has flags to toggle this:

   --virtualbox-host-dns-resolver									Use the host DNS resolver [$VIRTUALBOX_HOST_DNS_RESOLVER]
   --virtualbox-no-dns-proxy										Disable proxying all DNS requests to the host [$VIRTUALBOX_NO_DNS_PROXY]

They are available in Minikube as well, as:

      --dns-proxy=false: Enable proxy for NAT DNS requests (virtualbox driver only)
      --host-dns-resolver=true: Enable host resolver for NAT DNS requests (virtualbox driver only)

The machine ticket references these:

https://gitlab.alpinelinux.org/alpine/aports/-/issues/6221

https://www.virtualbox.org/ticket/18171

So it looks like yet another unhappy DNS customer

afbjorklund on Mar 15, 2021

Ran into this issue and pinning my docker build to Apline v 3.12 worked as per this.

ShahNewazKhan on Jan 23, 2022

OKay, minutes after posting this I found:

https://github.com/alpinelinux/docker-alpine/issues/149

Which is probably related.

wapiflapi on Mar 15, 2021