DNS lookups broken in 3.14 (minikube & mac using virtualbox)

[kmaounis]

Apologies for yet another DNS lookup issue but I am out of options.

As I see now (for example) there is now a 7.3.29-fpm-alpine3.14 docker image but no 7.3.29-fpm-alpine3.12 because it is expected that we drop support for alpine 3.12.

When we are using alpine 3.13 and 3.14 inside minikube locally for mac with the driver of virtualbox we have the same issue that others reported. Dns resolving does not behave the same as 3.12

• If inside the /etc/resolv.conf we leave the original nameserver defined from k8s (lets assume 10.96.0.10) then we can access the internal k8s services but not the internet.

• If inside the /etc/resolv.conf we add nameserver 8.8.8.8 then a container can access the internet but not the k8s internal services.

I really can not pinpoint the following:

• why alpine 3.13/3.14 behaves differently compared to other containers (node) regarding the dns resolving.
• If docker is not the issue ( since minikube is using virtualbox as a driver) why only alpine 3.13 , 3.14 has the issue?
• Is this a issue only on mac and if then why and how to bypass it?

[kmaounis]

On the positive side it seems to work for minikube using --driver=hyperkit and --hyperkit-vpnkit-sock (needed because of VPN)

[rowanparker]

* Is this a issue only on mac and if then why and how to bypass it?

It's not mac only, I have the same problem (3.12 worked, 3.13 and 3.14 did not) on a Windows host. If I ran nslookup inside the actual DockerDesktopVM (not the containers) I would get the same error.

nslookup pecl.php.net
Server:         192.168.65.5
Address:        192.168.65.5:53

Non-authoritative answer:
Name:   pecl.php.net
Address: 104.236.228.160

*** Can't find pecl.php.net: No answer

If I force docker to ignore the my host system DNS settings and use Google it works fine.

docker run -it --rm alpine:3.14 ping pecl.php.net
ping: bad address 'pecl.php.net'

docker run -it --rm --dns 8.8.8.8 alpine:3.14 ping pecl.php.net
PING pecl.php.net (104.236.228.160): 56 data bytes
64 bytes from 104.236.228.160: seq=0 ttl=37 time=215.437 ms

I then realised that I try running nslookup on my actual host machine (not the Docker VM or a container) would fail a few times then succeed with an IPv4 address.

I then disable IPv6 completely on my Ethernet adapter and everything works fine. I suspect there might be an issue with my cheap router and IPv6 (in my own personal case).

Try disabling IPv6 on your machine and see if that does anything.

* why alpine 3.13/3.14 behaves differently compared to other containers (node) regarding the dns resolving.
* If docker is not the issue ( since minikube is using virtualbox as a driver) why only alpine 3.13 , 3.14 has the issue?

I believe it's because 3.13 and 3.14 use a new version of musl-1.2.1-r1 or busybox-1.32.0-r2 as per this:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/11879

[jheiselman]

I'm seeing similar behavior on Linux on my raspberry pi 3 (armv7l). Rolling back to 3.12.3 resolves the issue. However, specifying the DNS argument to the docker CLI does not resolve the issue for me, nor does specifying it in the daemon.json config file. I did no testing with IPv6 vs IPv4, so cannot attest to that scenario.

[zalox]

I think I've run into the same problem. When running 3.13 I get a /etc/resolv.conf containing the correct nameserver. In 3.14 it contians nameserver 127.0.0.11 for some reason.

[jstangroome]

This is a bug in Virtualbox, finally fixed in v6.1.36.

NAT: Prevent issue when host resolver incorrectly returned NXDOMAIN for unsupported queries (bug #20977)

[gzwxh]

At present, in version 3.17 and 3.16, the ping net suffix domain name still reports the same error. Attempting to replace other basic images can be pinged normally