DNS queries are forwarded as A queries in NAT mode

[Peter Husen]

I am unable to properly connect to an AD domain from a Windows 7 guest (on an Ubuntu 13.04 host) and it seems to be due to DNS problems. By capturing network traffic on the guest using

VBoxManage modifyvm MyVM --nictrace1 on --nictracefile1 /tmp/VBOX.pcap

and on the host using Wireshark, i can see that queries on the guest to "SRV _ldap._tcp.dc._msdcs.mydomain.lan" (when logging in) result in queries from the host to "A _ldap._tcp.dc._msdcs.mydomain.lan", which fail, since _ldap._tcp.dc._msdcs is not a host. Similarly, running

nslookup -type=ALL mydomain.lan

on the guest produce queries to "ANY mydomain.lan", which are then forwarded as queries to "A mydomain.lan". This again fails, as it is not supposed to be a query for a host.

I have tried combinations of natdnsproxy1 and natdnshostresolver1 on and off, but the behavior seems to be the same in all cases.

[vasily Levchenko]

Could you please attach the log file and wireshark dumps you're looking at?

[Peter Husen]

DNS traffic on the host

[Peter Husen]

DNS traffic on the guest

[Peter Husen]

During the attached network captures, I did the following:

• Started the Windows 7 VM
• Logged on (to an AD domain)
• Ran the following commands in cmd:

C:\>nslookup -type=ALL emazys.lan
Server:  UnKnown
Address:  10.0.2.3

*** UnKnown can't find emazys.lan: Non-existent domain

C:\>nslookup -type=SRV emazys.lan
Server:  UnKnown
Address:  10.0.2.3

*** UnKnown can't find emazys.lan: Non-existent domain

C:\>nslookup -type=ALL google.com
Server:  UnKnown
Address:  10.0.2.3

google.com      internet address = 87.104.252.48
google.com      internet address = 87.104.252.53
google.com      internet address = 87.104.252.27
google.com      internet address = 87.104.252.24

If I specify the external DNS explicitly for nslookup, I get

C:\>nslookup -type=ALL emazys.lan 192.168.100.1
Server:  OpenWrt.emazys.lan
Address:  192.168.100.1

emazys.lan      nameserver = emaserver.emazys.lan
emazys.lan      internet address = 192.168.100.2
emazys.lan
        primary name server = emaserver.emazys.lan
        responsible mail addr = hostmaster.emazys.lan
        serial  = 3
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 0 (0 secs)
emaserver.emazys.lan    internet address = 192.168.100.2

C:\>nslookup -type=ALL google.com 192.168.100.1
Server:  OpenWrt.emazys.lan
Address:  192.168.100.1

Non-authoritative answer:
google.com      AAAA IPv6 address = 2a00:1450:4013:c00::64
google.com
        primary name server = ns1.google.com
        responsible mail addr = dns-admin.google.com
        serial  = 1525383
        refresh = 7200 (2 hours)
        retry   = 1800 (30 mins)
        expire  = 1209600 (14 days)
        default TTL = 300 (5 mins)
google.com      nameserver = ns1.google.com
google.com      nameserver = ns4.google.com
google.com      nameserver = ns3.google.com
google.com      nameserver = ns2.google.com
google.com      internet address = 87.104.252.48
google.com      internet address = 87.104.252.53
google.com      internet address = 87.104.252.27
google.com      internet address = 87.104.252.24
google.com      internet address = 87.104.252.38
google.com      internet address = 87.104.252.31
google.com      internet address = 87.104.252.37
google.com      internet address = 87.104.252.35
google.com      internet address = 87.104.252.16
google.com      internet address = 87.104.252.20
google.com      internet address = 87.104.252.42
google.com      internet address = 87.104.252.49
google.com      internet address = 87.104.252.26
google.com      internet address = 87.104.252.46
google.com      internet address = 87.104.252.59
google.com      internet address = 87.104.252.57

google.com      nameserver = ns2.google.com
google.com      nameserver = ns1.google.com
google.com      nameserver = ns4.google.com
google.com      nameserver = ns3.google.com
ns1.google.com  internet address = 216.239.32.10

I have filtered the captures quite a bit to avoid posting too much sensitive data. The full capture would reveal that the DNS queries from 127.0.0.1 to 127.0.1.1 (NetworkManager) are forwarded properly to 192.168.100.1.

[vasily Levchenko]

Ah defect is bit mixed, nathostresolver and dnsproxy have got very different implementation ... and perhaps it better to split this defect on two. dns proxy could just forward packets from guest to servers registered in host system one by one, but host resolver uses host API for name resolving (actually gethosbyname is core function with all known bottlenecks, and perhaps it will be changed someday, if we'll find more or less portable way to keep functionality on all supported platforms).

[Peter Husen]

Replying to Hachiman:

dns proxy could just forward packets from guest to servers registered in host system one by one ...

"could" but doesn't? Or am I failing to configure the VM to use dnsproxy? As I said, I tried various configurations, and if I e.g. run

$ VBoxManage modifyvm "Windows 7 64bit" --natdnshostresolver1 off
$ VBoxManage modifyvm "Windows 7 64bit" --natdnsproxy1 on

the observed behavior is exactly the same (as if I e.g. similarly try to set it to the host resolver). Is the guest supposed to be configured (by DHCP) to use 10.0.2.3 as DNS server in both configurations?

[vasily Levchenko]

Replying to phusen:

Replying to Hachiman:

dns proxy could just forward packets from guest to servers registered in host system one by one ...

"could" but doesn't? Or am I failing to configure the VM to use dnsproxy? As I said, I tried various configurations, and if I e.g. run

$ VBoxManage modifyvm "Windows 7 64bit" --natdnshostresolver1 off
$ VBoxManage modifyvm "Windows 7 64bit" --natdnsproxy1 on

the observed behavior is exactly the same (as if I e.g. similarly try to set it to the host resolver). Is the guest supposed to be configured (by DHCP) to use 10.0.2.3 as DNS server in both configurations?

10.0.2.3 is just alias for packet processing it's constant for both modes... the difference is only how packets are processed. to be sure commands above switches off resover and on dns proxy.

[Peter Husen]

to be sure commands above switches off resover and on dns proxy.

Um, are you telling me or asking me? I indeed expect these commands to switch to dns proxy. From your description of the difference, the problem could very well stem from the use of "gethostbyname". But then it should be better with dnsproxy, right? However, the result is exactly the same, so it feels like the setting doesn't actually change. Are there any other observable differences between the two, I might check?

[saliya]

Me Too(tm). One workaround is to perform the SRV query manually, then use returned nameservers in guest NIC properties

[Valery Ushakov]

Host-resolver has been updated in 5.0.20, it will now reject SRV records properly since it doesn't support them by design.