Closed gclawes closed 4 years ago
medyagh
commented
4 years ago @gclawes
That is a bug ! you found ! you are right we need to mind the people in corp network !
I would be happy to review any PR that would address this. either by providing a way for people to disable the check or provide the custom DNS
medyagh
commented
4 years ago @gclawes on your corp setup, if we wanted to auto-detect the nameserver for look up how would we do it ? could you kindly provide us more info, how we could auto-detect this and use the crop provided ns?
gclawes
commented
4 years ago What's the purpose of this check? To verify that DNS resolution is working?
I think the most platform independent should be able to do it in go with net.LookupHost:
https://golang.org/pkg/net/?m=all#hdr-Name_Resolution
https://golang.org/pkg/net/?m=all#LookupHost
tstromberg
commented
4 years ago The purpose is to warn users if the VM is unable to directly connect to the internet. An app that they run in the VM won't be able to directly contact an external IP, without using a proxy server.
I'd be open to improving the appearance of the check, removing it, and/or adding a flag to prevent this connection check. Thoughts?
gclawes
commented
4 years ago It looks like minikube is getting it's /etc/resolv.conf set to the gateway for the hypervisor's (in this case hyperkit) network. I think making the check to resolve k8s.io is fine, but it shouldn't be necessary to hard-code the DNS resolvers. nslookup k8s.io or dig k8s.io should be sufficient.
Liveware-Problem :: ~ % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ cat /etc/resolv.conf
# 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.65.1
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 62:13:6f:a2:5b:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.65.17/24 brd 192.168.65.255 scope global dynamic eth0
valid_lft 85023sec preferred_lft 85023sec
inet6 fe80::6013:6fff:fea2:5b5d/64 scope link
valid_lft forever preferred_lft foreverLiveware-Problem :: ~ % ifconfig bridge100
bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
options=3<RXCSUM,TXCSUM>
ether a6:5e:60:dd:ef:64
inet 192.168.65.1 netmask 0xffffff00 broadcast 192.168.65.255
inet6 fe80::44a:652b:7d69:92b7%bridge100 prefixlen 64 secured scopeid 0x12
Configuration:
id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
ipfilter disabled flags 0x2
member: en11 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 17 priority 0 path cost 0
Address cache:
62:13:6f:a2:5b:5d Vlan1 en11 1198 flags=0<>
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active@gclawes - I encourage you to take a look if #5802 seems like more appropriate behavior.
PS - Thank you for opening this bug. I'm sure others have seen this unusual new behavior and just decided that it was annoying without letting us in on the issue.
tstromberg
commented
4 years ago Fixed in v1.5.2. Thank you for reporting this issue!
nomansadiq11
commented
4 years ago restart my network adapter and its works.
Minikube attempts to connect to the internet by running
nslookup k8s.ioagainst8.8.8.8and1.1.1.1, and pinging8.8.8.8if those fail. In a corporate/closed network behind a proxy these DNS endpoints are not available. Minikube should use the local DNS resolvers, and possibly have a different behavior in the presence ofhttp_proxy/HTTP_PROXYThe exact command to reproduce the issue:
minikube startThe full output of the command that failed:
The output of the
minikube logscommand:The operating system version: macOS Mojave 10.14.6