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.