DNS resolving is extremely slow in NAT mode.

[zhuhaow]

This is something that troubles me a lot. In NAT mode, DNS request takes several seconds to return.

I can confirm that in guest vms running win 10 and boot2docker, so I'm pretty sure it's a Fusion problem.

I run nslookup with hostname baidu.com and server 114.114.114.114 to prevent the government censorship in China having any impaction.

Running nslookup on host returns results immediately.

In boot2docker,

docker@dev:~$ time nslookup baidu.com

Server:    172.16.67.2

Address 1: 172.16.67.2

Name:      baidu.com

Address 1: 111.13.101.208

Address 2: 123.125.114.144

Address 3: 220.181.57.217

Address 4: 180.149.132.47

Address 5: 220.181.57.217

real 2m 0.24s

user 0m 0.00s

sys 0m 0.01s

yes, it takes 2 minutes.

docker@dev:~$ time nslookup baidu.com 114.114.114.114

Server:    114.114.114.114

Address 1: 114.114.114.114 public1.114dns.com

Name:      baidu.com

Address 1: 180.149.132.47

Address 2: 111.13.101.208

Address 3: 123.125.114.144

Address 4: 220.181.57.217

real 0m 0.42s

user 0m 0.00s

sys 0m 0.00s

so the default DNS 172.16.67.2 takes a lot of time (at least tens of seconds) for each DNS request.

The /etc/resolv.conf file is:

search localdomain

nameserver 172.16.67.2

which is obtained from DHCP server running by Fusion (I guess). I can't change the DNS server because the system will revert /etc/resolv.conf now and then (based on DHCP response).

output of ifconfig:

docker@dev:~$ ifconfig

docker0   Link encap:Ethernet  HWaddr 02:42:70:D0:B5:A9

          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:0C:29:37:64:5E

          inet addr:172.16.67.131  Bcast:172.16.67.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe37:645e/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:1186 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1017 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:151294 (147.7 KiB)  TX bytes:134513 (131.3 KiB)

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:65536  Metric:1

          RX packets:16 errors:0 dropped:0 overruns:0 frame:0

          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:1376 (1.3 KiB)  TX bytes:1376 (1.3 KiB)

output of route -n:

docker@dev:~$ route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         172.16.67.2     0.0.0.0         UG    1      0        0 eth0

127.0.0.1       0.0.0.0         255.255.255.255 UH    0      0        0 lo

172.16.67.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

The situation will be a little better in Windows 10 because the Windows has a much shorter timeout threshold:

C:\Windows\system32>nslookup baidu.com

DNS request timed out.

    timeout was 2 seconds.

服务器:  UnKnown

Address:  172.16.67.2

名称:    baidu.com.localdomain

Addresses:  220.181.57.217

          220.181.57.217

I'm not sure why this works when the request timed out, but it does return result in 2 seconds, which is so much better comparing to boot2docker.

Running  nslookup baidu.com 114.114.114.114 returns result immediately of course.

Switch to host-only mode (if that's the right name since I'm using Chinese version) solves everything since it no longer use DNS server running by Fusion, but I need NAT for safety and boot2docker only works great in NAT mode, and I can't set DNS in guest vm by myself.

The settings of Fusion are almost default as there is literally no network setting I could change.

To sum up, running nslookup returns result in several ms as long as we do not use the DNS server bundled with Fusion which takes minutes to resolve a request.

I wonder if there is any solution to this problem or will it be fixed soon.

[nancyz]

Hi zhuhaow,

Thanks for using Fusion.

Although I'm not quite familiar with Docker, I would like to know your setup.

I can confirm that in guest vms running win 10 and boot2docker, so I'm pretty sure it's a Fusion problem.

So you installed boot2docker in your windows 10 vm?

docker@dev:~$ ifconfig

docker0   Link encap:Ethernet  HWaddr 02:42:70:D0:B5:A9

          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:0C:29:37:64:5E

          inet addr:172.16.67.131  Bcast:172.16.67.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe37:645e/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:1186 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1017 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:151294 (147.7 KiB)  TX bytes:134513 (131.3 KiB)

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:65536  Metric:1

          RX packets:16 errors:0 dropped:0 overruns:0 frame:0

          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:1376 (1.3 KiB)  TX bytes:1376 (1.3 KiB)

Where did these outputs come from? Looking at the NIC name, they came from your Mac, but I could not find virtual network adapter of Fusion.

[zhuhaow]

I created two vms, one running boot2docker and another windows 10.

boot2docker is a bare-bone linux designed to run docker since docker is not supported on non-linux system such as mac.

These network setting output came from the boot2docker system.

Here is the ifconfig output on my hosting mac:

$ ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

  options=3<RXCSUM,TXCSUM>

  inet6 ::1 prefixlen 128

  inet 127.0.0.1 netmask 0xff000000

  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

  nd6 options=1<PERFORMNUD>

gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

stf0: flags=0<> mtu 1280

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

  ether b8:e8:56:2f:b0:48

  inet6 fe80::bae8:56ff:fe2f:b048%en0 prefixlen 64 scopeid 0x4

  inet 192.168.1.223 netmask 0xffffff00 broadcast 192.168.1.255

  nd6 options=1<PERFORMNUD>

  media: autoselect

  status: active

p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304

  ether 0a:e8:56:2f:b0:48

  media: autoselect

  status: inactive

awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484

  ether 6e:8a:61:0d:d0:1b

  inet6 fe80::6c8a:61ff:fe0d:d01b%awdl0 prefixlen 64 scopeid 0x6

  nd6 options=1<PERFORMNUD>

  media: autoselect

  status: active

en1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500

  options=60<TSO4,TSO6>

  ether 72:00:00:8e:82:b0

  media: autoselect <full-duplex>

  status: inactive

en2: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500

  options=60<TSO4,TSO6>

  ether 72:00:00:8e:82:b1

  media: autoselect <full-duplex>

  status: inactive

bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

  options=63<RXCSUM,TXCSUM,TSO4,TSO6>

  ether ba:e8:56:f2:43:00

  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: en1 flags=3<LEARNING,DISCOVER>

         ifmaxaddr 0 port 7 priority 0 path cost 0

  member: en2 flags=3<LEARNING,DISCOVER>

         ifmaxaddr 0 port 8 priority 0 path cost 0

  nd6 options=1<PERFORMNUD>

  media: <unknown type>

  status: inactive

vboxnet0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

  ether 0a:00:27:00:00:00

vboxnet1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

  ether 0a:00:27:00:00:01

utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

  inet6 fe80::23fd:3818:8bcb:b2c2%utun0 prefixlen 64 scopeid 0xf

  nd6 options=1<PERFORMNUD>

vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

  ether 00:50:56:c0:00:01

  inet 192.168.212.1 netmask 0xffffff00 broadcast 192.168.212.255

vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

  ether 00:50:56:c0:00:08

  inet 172.16.67.1 netmask 0xffffff00 broadcast 172.16.67.255

[nancyz]

vboxnet0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

  ether 0a:00:27:00:00:00

vboxnet1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

  ether 0a:00:27:00:00:01

So you also installed boot2docker on your Mac?

[nancyz]

Thanks for your update. I'll try and see if I could reproduce your problems.

[nancyz]

Thanks for your update. I'll try and see if I could reproduce your problems.

I could not reproduce this issue:

Windows 10:

C:\Users\test>nslookup baidu.com

Server:  UnKnown

Address:  172.16.51.2

Name:    baidu.com.localdomain

Addresses:  180.149.132.47

          180.149.132.47

And screen from dockervm

[pixelrebel]

Okay, this is how you reproduce the issue on MacOS.

Set up network configuration in MacOS to DHCP (make sure your DNS servers are received implicitly from DHCP).

In your guest:
$ nslookup wikipedia.com

The results should be lightning fast, and using the virtual DNS server VMWare put on the NAT.

Now, set up network configuration in MacOS to MANUALLY (make sure your DNS servers are entered explicitly in the 'advanced' tab).

Back to your guest:

$ nslookup wikipedia.com

The results will take about 20 seconds.

This has been recognized as a bug since 2009.  VMWare needs to fix this ASAP.

[dariusd]

I have followed your steps to reproduce the problem here, but on my system nslookup inside the guest is still fast even when the host's network configuration is set to Manually.

My config: OS X 10.10.5 host, Fusion 8.0.2, Ubuntu 14.10 Desktop amd64 guest.  The host is using an Apple Thunderbolt-to-GigE adapter on a wired network.

Are you connecting via wired or wireless?  Maybe mention which networking hardware and Internet connection you are using in case others encountering this problem happen to have the same setup.  Perhaps we can find a common thread...

Also, If you can run Wireshark or tcpdump on your Mac at the time of the slow lookups, it might give us a clue what's happening.  Also look launch Console and see if any messages appear at the time of the slow lookup.

Cheers,

--

Darius