Minikube: hyperkit: external DNS resolution fails: conflict with DNS server running on host

Created on 1 Aug 2018  ·  32Comments  ·  Source: kubernetes/minikube

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Please provide the following details:

Environment: MacOS High Sierra

Minikube version (use minikube version): 0.25.0 and above

  • OS (e.g. from /etc/os-release): MacOS High Sierra, version 10.13.6
  • VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): hyperkit
  • ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): .minikube/cache/iso/minikube.25.0.0.iso
  • Install tools: curl -#Lo minikube https://storage.googleapis.com/minikube/releases/v0.25.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
  • Others:

What happened: dns in minikube does not work. DNS cluster can not start, because can not download images from registry. 192.168.64.1 - it is my host IP

nslookup ya.ru
Server:    192.168.64.1
Address 1: 192.168.64.1

nslookup: can't resolve 'ya.ru'

What you expected to happen: DNS works. If I change DNS server in minikube to 8.8.8.8, it works.

su root
rm -f /etc/resolv.conf && echo nameserver 8.8.8.8 > /etc/resolv.conf
nslookup ya.ru
Server:    8.8.8.8
Address 1: 8.8.8.8 google-public-dns-a.google.com

Name:      ya.ru
Address 1: 87.250.250.242 ya.ru
Address 2: 2a02:6b8::2:242 ya.ru

How to reproduce it (as minimally and precisely as possible):

minikube stop && minikube delete
minikube start --vm-driver hyperkit

Output of minikube logs (if applicable):

Anything else do we need to know:

aredns chyperkit good first issue help wanted kinbug needs-faq-entry omacos prioritawaiting-more-evidence prioritimportant-soon

Most helpful comment

I am using minikube using the hyperkit driver on macOS and experiencing the same problems with dnscrypt-proxy, which listens on 127.0.0.1:53 (udp+tcp). This binary is part of the Cisco Umbrella (corporate OpenDNS) roaming client. I cannot modify the configuration used by dnscrypt-proxy. The dnsmasq.conf changes linked are insufficient to resolve the issue for others.

Is there no way to apply a persistent DNS configuration change to minikube and the system pods?

~
❯ sudo lsof -i :53
Password:
COMMAND     PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
dnscrypt- 44992 nobody    7u  IPv4 0x94dd190be9fa26c5      0t0  UDP localhost:domain
dnscrypt- 44992 nobody    8u  IPv4 0x94dd190bff44e9ed      0t0  TCP localhost:domain (LISTEN)

~
❯ ps ax 44992
  PID   TT  STAT      TIME COMMAND
44992   ??  Ss     0:02.69 /Library/Application Support/OpenDNS Roaming Client/dnscrypt-proxy --user nobody --local-address=127.0.0.1:53 --plugin=/Library/Application Support/OpenDNS Roaming Client/libdcplugin_erc.so -d

~
❯ minikube ssh -- 'cat /etc/resolv.conf; echo "Ping by Name:" && ping -v -c 4 google.com; echo "Ping by IP:" && ping -c 4 8.8.8.8'
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.64.1
Ping by Name:
ping: bad address 'google.com'
Ping by IP:
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=51 time=23.489 ms
64 bytes from 8.8.8.8: seq=1 ttl=51 time=25.994 ms
64 bytes from 8.8.8.8: seq=2 ttl=51 time=27.537 ms
64 bytes from 8.8.8.8: seq=3 ttl=51 time=25.740 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 23.489/25.690/27.537 ms

All 32 comments

I have exactly the same issue

  • OS: MacOS High Sierra, version 10.13.6
  • VM Driver: hyperkit
  • ISO: minikube-v0.28.1.iso

Same here, had that issue a couple month ago alrady and just tried again after upgrading all components it is still there:

  • OS: MacOS Sierra
  • VM Driver: hyperkit
  • ISO: minikube-v0.28.2.iso

Interesting - it sounds like kube-dns is effectively broken within minikube. https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/ has some tips on how to debug internal DNS service issues. Do you mind sharing the output of:

kubectl get svc --namespace=kube-system

kubectl get ep kube-dns --namespace=kube-system

kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubedns

kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasq

kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar

Thanks!

Also, please check if the host (Mac OS) has anything listening on port 53 already, or specifically, if dnsmasq is running.

In my case, I have something listening on :53 and this process running:
/usr/local/opt/dnsmasq/sbin/dnsmasq --keep-in-foreground

kubedebug.log


Update, fix to my issue:
dnsmasq was running and ignoring the dns request, since it was not listening to the right local addresses

If you are using dnsmasq in your setup and cluster creation fails (stuck at kube-dns initialization) you might need to add listen-address=127.0.0.1,192.168.64.1 to dnsmasq.conf.

Note: If dnsmasq.conf contains listen-address=127.0.0.1 kubernetes discovers dns at 127.0.0.1:53 and tries to use it using bridge ip address, but dnsmasq replies only to reqests from 127.0.0.1

My /usr/local/etc/dnsmasq.conf looks like that:

address=/kube.local/192.168.64.1
listen-address=127.0.0.1,192.168.64.1

Also, please check if the host (Mac OS) has anything listening on port 53 already, or specifically, if dnsmasq is running.

Yep, I am using dnsmasq on local host, it is neccesary for routing *.kube hosts to minikube

It seems there is progress ongoing .. there is an open PR with a workaround: https://github.com/kubernetes/minikube/pull/3003/files

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperkit-driver

there is a problem with the current solution, dnsmasq will fail to start when minikube is not running, 192.168.64.1 does not exist

finally I decided to stop my dnsmasq when running minikube, this is a easy way

I am using minikube using the hyperkit driver on macOS and experiencing the same problems with dnscrypt-proxy, which listens on 127.0.0.1:53 (udp+tcp). This binary is part of the Cisco Umbrella (corporate OpenDNS) roaming client. I cannot modify the configuration used by dnscrypt-proxy. The dnsmasq.conf changes linked are insufficient to resolve the issue for others.

Is there no way to apply a persistent DNS configuration change to minikube and the system pods?

~
❯ sudo lsof -i :53
Password:
COMMAND     PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
dnscrypt- 44992 nobody    7u  IPv4 0x94dd190be9fa26c5      0t0  UDP localhost:domain
dnscrypt- 44992 nobody    8u  IPv4 0x94dd190bff44e9ed      0t0  TCP localhost:domain (LISTEN)

~
❯ ps ax 44992
  PID   TT  STAT      TIME COMMAND
44992   ??  Ss     0:02.69 /Library/Application Support/OpenDNS Roaming Client/dnscrypt-proxy --user nobody --local-address=127.0.0.1:53 --plugin=/Library/Application Support/OpenDNS Roaming Client/libdcplugin_erc.so -d

~
❯ minikube ssh -- 'cat /etc/resolv.conf; echo "Ping by Name:" && ping -v -c 4 google.com; echo "Ping by IP:" && ping -c 4 8.8.8.8'
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.64.1
Ping by Name:
ping: bad address 'google.com'
Ping by IP:
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=51 time=23.489 ms
64 bytes from 8.8.8.8: seq=1 ttl=51 time=25.994 ms
64 bytes from 8.8.8.8: seq=2 ttl=51 time=27.537 ms
64 bytes from 8.8.8.8: seq=3 ttl=51 time=25.740 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 23.489/25.690/27.537 ms

DNSMASQ.
followed recommendations:
https://github.com/kubernetes/minikube/issues/2456
https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/

I have disabled dnsmasq and deleted and started minikube over..

I get the same logging issue.

It seems like the bridge that is reachable from outside the minikube:
64 bytes from 192.168.64.1: icmp_seq=0 ttl=64 time=0.052 ms
is not reachable from inside

minikube ssh
#traceroute 192.168.64.1
traceroute to 192.168.64.1 (192.168.64.1), 30 hops max, 46 byte packets
 1 * * *

this is also what coredns sees.

$ kubectl logs --namespace=kube-system coredns-5c98db65d4-9vpk8
.:53
2019-09-10T23:29:49.664Z [INFO] CoreDNS-1.3.1
2019-09-10T23:29:49.665Z [INFO] linux/amd64, go1.11.4, 6b56a9c
CoreDNS-1.3.1
linux/amd64, go1.11.4, 6b56a9c
2019-09-10T23:29:49.665Z [INFO] plugin/reload: Running configuration MD5 = 5d5369fbc12f985709b924e721217843
2019-09-10T23:29:55.669Z [ERROR] plugin/errors: 2 6233357733929179938.7507841895618823623. HINFO: read udp 172.17.0.2:33644->192.168.64.1:53: i/o timeout
2019-09-10T23:29:58.669Z [ERROR] plugin/errors: 2 6233357733929179938.7507841895618823623. HINFO: read udp 172.17.0.2:48448->192.168.64.1:53: i/o timeout
ram9:etc/ $ minikube version                                           [17:01:12]
minikube version: v1.3.1
commit: ca60a424ce69a4d79f502650199ca2b52f29e631



md5-739d80a42916a6c700cae82d239bae7f



ram9:etc/ $ kubectl version                                            [17:01:15]
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T12:36:28Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}



md5-739d80a42916a6c700cae82d239bae7f



ls -la /usr/local/bin/*hyperkit*                           [17:18:01]
-rwsr-xr-x  1 root  wheel  26811068 Apr 20  2018 /usr/local/bin/docker-machine-driver-hyperkit
lrwxr-xr-x  1 root  admin        67 Sep 10 15:05 /usr/local/bin/hyperkit -> /Applications/Docker.app/Contents/Resources/bin/com.docker.hyperkit



md5-739d80a42916a6c700cae82d239bae7f



$ sudo lsof -i :53                                           [17:18:34]
Password:
COMMAND   PID           USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
mDNSRespo 205 _mdnsresponder   64u  IPv6 0x1e8f1c64183077e5      0t0  UDP *:domain
mDNSRespo 205 _mdnsresponder   66u  IPv6 0x1e8f1c6416ac90cd      0t0  TCP *:domain (LISTEN)



md5-2ca09aabb3c88f4cfe71454b0bf0f879



 brew reinstall hyperkit # force link instructions 



md5-739d80a42916a6c700cae82d239bae7f



curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit && sudo install -o root -g wheel -m 4755 docker-machine-driver-hyperkit /usr/local/bin/

Using the newest version of the hyper kit the dns resolution is solved enough that i can launch busybox. I was also able to install tiller. I am not able to re-enable dnsmasq.

hyperkit: 0.20190802

This is still a thing, but at least it's documented.

I suppose we could have a driver pre-run check that sniffs out if something is listening on the port already. It'd be nice to compare the lsof output for a working vs non-working configuration.

I haven't heard anyone running into this issue in a while. Anyone else?

I has run into this issue and it take me a while to fix that.
This happends actually only with dnsmasq (or any other dns service) locally installed.

Here is my working dnsmasq.conf for anyone who may get into this error, too.
Ofc you need to restart dnsmasq after adding the listen-address.


address=/.localhost/127.0.0.1
listen-address=127.0.0.1
listen-address=192.168.64.1

We're hitting this issue and also have an Umbrella / dnscrypt-proxy setup we can't change.

As a possible workaround, it appears that using Docker Desktop's vpnkit, e.g. minikube start ... --hyperkit-vpnkit-sock=/Users/zarenner/Library/Containers/com.docker.docker/Data/vpnkit.eth.sock works, correctly forwarding DNS requests to dnscrypt-proxy. But it's not really ideal since we'd rather not also have Docker Desktop installed and running in addition to minikube. I'm not sure if running a separate vpnkit instance would make more sense.

Discovered that while possible, a separate vpnkit instance is difficult to set up without Docker Desktop due to lack of standalone vpnkit and vmnetd binaries.

Currently facing the same issue on linux with dnsmasq

Currently facing the same issue in macOs 18.7.0 Darwin Kernel Version 18.7.0: Sun Dec 1 18:59:03 PST 2019; root:xnu-4903.278.19~1/RELEASE_X86_64 x86_64

Hey folks, you need to check the IP Adresses and the DNS resolution. This issue is mostly based on wrong proxy or dns settings. Just make sure, that the routing and dns is correct and everything will be fine.

If you have dnsmasq, you need to extend your configuration like here

Any other issue should be traced back.

I can confirm that @zarenner's solution works with adding a line for listen-address for 192.168.64.1

I has run into this issue and it take me a while to fix that.
This happends actually only with dnsmasq (or any other dns service) locally installed.

Here is my working dnsmasq.conf for anyone who may get into this error, too.
Ofc you need to restart dnsmasq after adding the listen-address.


address=/.localhost/127.0.0.1
listen-address=127.0.0.1
listen-address=192.168.64.1

I did that and also had to restart dnsmasq to make it work (for macOS):

sudo launchctl stop homebrew.mxcl.dnsmasq
sudo launchctl start homebrew.mxcl.dnsmasq

Had the same issue when starting minikube with hyperkit. There was a dnscrypt-proxy, also corporate solution, running on 53 port

/Library/Application Support/OpenDNS Roaming Client/dnscrypt-proxy --user nobody --local-address=127.0.0.1:53 --plugin=/Library/Application Support/OpenDNS Roaming Client/libdcplugin_erc.so -d

Restarting after

sudo launchctl unload /Library/LaunchDaemons/com.opendns.osx.RoamingClientConfigUpdater.plist

works just fine for me, however, not ideal still

We're hitting this issue and also have an Umbrella / dnscrypt-proxy setup we can't change.

As a possible workaround, it appears that using Docker Desktop's vpnkit, e.g. minikube start ... --hyperkit-vpnkit-sock=/Users/zarenner/Library/Containers/com.docker.docker/Data/vpnkit.eth.sock works, correctly forwarding DNS requests to dnscrypt-proxy. But it's not really ideal since we'd rather not also have Docker Desktop installed and running in addition to minikube. I'm not sure if running a separate vpnkit instance would make more sense.

we should add this to our hyperkit driver documentation

https://minikube.sigs.k8s.io/docs/drivers/hyperkit/

I am looking for someone to evaluate all these workarrounds and put them in the hyperkit driver documentation.

@medyagh
Can I do this issue? I guess I can contribute for editing documentation even if I'm a newbie with k8s and minikube.

But I'm wondering is it a good way to add zarenner's comment in the documentation since I encountered this problem with cloudflared DNS and it's not a solution for cloudflared. (minikube start ... --hyperkit-vpnkit-sock=/Users/zarenner/Library/Containers/com.docker.docker/Data/vpnkit.eth.sock)

We'd be happy to review any PR you submit.

In my case, I have something listening on :53 and this process running:
/usr/local/opt/dnsmasq/sbin/dnsmasq --keep-in-foreground

kubedebug.log

Update, fix to my issue:
dnsmasq was running and ignoring the dns request, since it was not listening to the right local addresses

If you are using dnsmasq in your setup and cluster creation fails (stuck at kube-dns initialization) you might need to add listen-address=127.0.0.1,192.168.64.1 to dnsmasq.conf.

_Note: If dnsmasq.conf contains listen-address=127.0.0.1 kubernetes discovers dns at 127.0.0.1:53 and tries to use it using bridge ip address, but dnsmasq replies only to reqests from 127.0.0.1_

My /usr/local/etc/dnsmasq.conf looks like that:

address=/kube.local/192.168.64.1
listen-address=127.0.0.1,192.168.64.1

Unfortunately these lines were not helpful in my case.
But slightly modify them it is:

server=/kube.local/192.168.64.1
listen-address=127.0.0.1,192.168.64.1

Both directive are important. The docs say that listen-address directive is enough but in my case it start working only with server directive.
Hope it will be helpful to someone.

This seems to help in the meantime:

sudo socat UDP4-RECVFROM:53,bind=192.168.64.1,fork UDP4-SENDTO:127.0.0.1:53

Apart from having that line
listen-address=127.0.0.1,192.168.64.1

the second one also seems to be crucial
address=/.localhost/127.0.0.1

If that does not work check what network is really being used under the hood by minikube (via ifconfig)

Hey @bartkim0426! Are you still interested in this issue?

I was just investigating another DNS-related issue on my colleagues OS X High Sieera, and it turns out, it's really terrible.

He has a mDNSresponder service occupying *:53/UDP. It does not actually respond to any of the requests made by the minikube VM. So, DNS is effectively broken for the VM, using HyperKit. We did not know about the DNSresponder thingie, since we installed dnsmasq, and began using it. Eventually, we realized it's failing to start exactly because it cannot bind.

I think this is yet one more example of horrific engineering on Apple's side. I am not saying everything they do is garbag, but WHY on earth would you have a service that (according to Google) is there to support Bonjour (kind of a discorery protocol) occupiying *:53???

If there was at least a way how to tell it not to occupy ALL the ip addresses, such that actually useful software could listen on them instead :)

EDIT: You could possibly maybe tell Minikube to use a different IP for the DNS resolution, as routing seems to be working, but if you need that IP to be dnsmasq, you will have to host ti likely on a different VM, not the OS X :(((

@petr-motejlek How can you be wrong so much? My mac runs Catalina!

Was this page helpful?
0 / 5 - 0 ratings