DNS Resolver/NAT does not work if a local DNS is running (Linux Host, Any Guest) => Fixed in 2.1.0

[znerol]

If the host system is setup in a way that it uses its own (caching) DNS server (i.e. /etc/resolv.conf contains only the line "nameserver 127.0.0.1") virtualbox guests using nat will not be able to resolve names using the DNS assigned by dhcp (10.0.2.3). However resolving using the standart gateway (10.0.2.2) works without problems from within guest systems. This issue is probably related to #377 and #421.

The relevant entry in the log looks like this for guests refusing to resolve via 10.0.N.3:

00:03:29.873 NAT: DNS address: 127.0.0.1

Im running virtualbox 1.5.6_OSE on Debian Lenny (testing). I did not test version 1.6.0.

[zebul6]

i confirm that bug in vbox 1.5.6 binary version and 1.6.0 binary edition too (linux host, windows xp guest, opensolaris guest)

i have used wireshark to try to found out what is happening :

if 10.0.2.3 is used as the dns server in the guest, the dns request is passed to my local IP 192.168.1.10 (eth0) on the host instead of 127.0.0.1. but the dns cache server (dnrd) is listening on 127.0.0.1 only and not on the 192.168.1.1 network. and it does not have to.

if 10.0.2.2 is used for dns server in the guest, then the query is sent to 127.0.0.1 in the host as it should in the previous setup

[Stéphane Charette]

This is a serious bug for me. Every time I restart one of my virtual machines (several times per day for development environments) I have to fix up /etc/resolv.conf in my guest for name resolution to work. Is there a workaround available?

Host is Ubuntu 8.04-64bit, running VirtualBox v1.6.0, 64-bit. Guests are Ubuntu 7.10 & 8.04, and Fedora 8 & 9.

[zebul6]

i gave a work around just above. use 10.0.2.2 as dns instead of 10.0.2.3

you might need to tweak your dhcp client configuration in the guest so that it does not ask for dns but use the one you defined. if not you will continue to use 10.0.2.3

[Stéphane Charette]

This is still a problem in VB 2.0.2.

Makes it hard to do a network-based installation of a new OS; e.g., Debian has a minimal boot disk that DHCPs an address and grabs the rest of the installation files from the 'net. But when it DHCPs the address, it doesn't provide an easy way to override the DNS entry. Installation just hangs there forever as it tries to resolve names.

As for the "work around" stated above: in Ubuntu, even when you override the DNS from 10.0.2.3 to 10.0.2.2, when the DHCP lease is renewed the override is overwritten, and your guest OS reverts back to 10.0.2.3, obviously leading to name resolution issues.

[dummytaurus]

To make sure resolv.conf does not change, you can follow ​http://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/. Option #1 works for me.

[Chris Howie]

It seems to me that the issue here is in the fact that VirtualBox sends requests to a non-loopback address assigned to the host, according to klaus in #vbox. It's picking something other than 127.0.0.1 (for whatever reason, makes no sense to me but I'm not a dev) and on my setup dnsmasq is listening only on 127.0.0.1. In other words, vbox should not assume that it can reach the DNS server by any other address than the one it finds in resolv.conf. That's the point of resolv.conf, no? :)

I will do some tests later to confirm that this is in fact the case.

[Chris Howie]

Ok, based on my sniffing tests, VirtualBox is sending queries to 127.0.1.1 instead of 127.0.0.1, and since my DNS server is only listening on 127.0.0.1, the queries go nowhere. What's the rationale for using 127.0.1.1 when resolv.conf contains 127.0.0.1?

[Frank Mehnert]

cdhowie, please could you attach your resolv.conf file (not cut'n'paste please)?

[Stéphane Charette]

I suffer from this same problem (see my posting near the top of this ticket). I'll attach my resolv.conf file as well.

[Stéphane Charette]

/etc/resolv.conf from Stéphane Charette

[Frank Mehnert]

Thanks. Could you attach the output of 'ifconfig' as well?

[Stéphane Charette]

ifconfig output from Stéphane Charette

[Stéphane Charette]

This ticket is easy to reproduce. E.g., install Ubuntu as the host, then start Synaptic Package Manager, search for and install the package named "bind9".

Next install VirtualBox. Install any type of guest (linux, windows); select NAT networking. When the guest comes up and DHCPs an address, the dns server it tries to use wont work.

[Frank Mehnert]

/etc/hosts and hostname are important. The slirp code determines the host name with gethostname() and determines the host IP with gethostbyname() from that name. If one of both functions does not work, 127.0.0.1 is used. cdhowie, I assume your /etc/hosts contains a 127.0.1.1 entry. We will think about a proper fix.

[Chris Howie]

frank: You are correct, my hostname maps to 127.0.1.1. I still do not understand why this matters at all. Why should vbox proxy the requests to any other address but the one in resolv.conf? What's so special about 127.0.0.1 that it must suddenly behave differently?

[Frank Mehnert]

cdhowie, my previous comment should be clear enough why this failed for several users. The reason for this behavior is unknwon as the VBox NAT code is inherited from slirp.

[Chris Howie]

frank: I understand why it's failing. I was simply expressing my confusion as to the rationale for this behavior. It looks like we are actually saying the same thing, just different ways.

[Flemming Madsen]

Yes this is a problem for me too. Using resolvconf (ie openresolv) and dnsmasq on Arch linux.

I have been able to resolve the issuue like this:

1) Add another lo if for the 127.0.1.1 address:

ifconfig lo:0 127.0.1.1

2) Make dnsmasq listen on both addresses: Add line to /etc/dnsmasq.conf:

listen-address=127.0.0.1,127.0.1.1

Thanx for your wireshark work guys! This really got me puzzled

[Chris Howie]

Replying to themadsens:

I have been able to resolve the issuue like this

Yeah, that's roughly what I've had to do as well. But it's not actually a resolution, only a workaround. VirtualBox should not be doing any kind of special interpretation of what's in resolv.conf, it should use exactly the addresses it contains.

[Flemming Madsen]

Replying to cdhowie:

it should use exactly the addresses it contains.

Agreed!

[Frank Mehnert]

Actually this issue should be fixed in VirtualBox 2.1.0.

[Martin Decky]

I don't believe that this issue has been fixed in 2.1.0. As cdhowie pointed out earlier, if you have a following nameserver line in /etc/resolv.conf

nameserver 127.0.0.1

then VirtualBox is not using 127.0.0.1 as the nameserver address, but sends requests to a non-loopback address assigned to the host. Which is obviously not what you have in mind if you have a local caching DNS server running.

Here is a simple patch which solves the issue. It removes the strange rewriting of loopback address to non-loopback address. The patch is originally for 2.0.6, but as you can clearly see, it will apply also to 2.1.0. And let me stress this out: it should be applied in order to finally fix the issue.

diff -Naur VirtualBox-2.0.6.orig/src/VBox/Devices/Network/slirp/slirp.c VirtualBox-2.0.6/src/VBox/Devices/Network/slirp/slirp.c
--- VirtualBox-2.0.6.orig/src/VBox/Devices/Network/slirp/slirp.c	2008-11-21 22:40:00.000000000 +0100
+++ VirtualBox-2.0.6/src/VBox/Devices/Network/slirp/slirp.c	2008-12-20 00:18:55.353284845 +0100
@@ -142,8 +142,6 @@
         if (sscanf(buff, "nameserver%*[ \t]%256s", buff2) == 1) {
             if (!inet_aton(buff2, &tmp_addr))
                 continue;
-            if (tmp_addr.s_addr == loopback_addr.s_addr)
-                tmp_addr = our_addr;
             /* If it's the first one, set it to dns_addr */
             if (!found)
             {

[Frank Mehnert]

Did you actually test if 2.1.0 fixed the issue for you? I assume not because in version 2.1.0, our_addr is 127.0.0.1 in every case. Therefore your patch is not necessary.

[Martin Decky]

No, I did not test 2.1.0 yet. However, I believe that the condition above (which I propose to be removed) is wrong in any case.

Setting our_addr to 127.0.0.1 certainly fixes the issue with local caching DNS server, but then the condition above is even more useless and it is yet another reason for removing it.

Has somebody tracked somewhere why the value of our_addr was changed to 127.0.0.1? If you don't remove the condition above and somebody else changes the value of our_addr again, you will end up with the same or very similar problem as before. A bug should be fixed where it actually happens, not workaround it in a totally unrelated place. IMHO.

[Frank Mehnert]

I agree, we should probably remove that line.

However, our_addr is never set to a different value than 127.0.0.1. We changed the function getouraddr() accordingly some time ago. And yes, the condition for this change was exactly this defect.

Therefore, to be pedantic, the bug was already fixed although removing that misleading statement will prevent further confusion.

[Martin Decky]

OK, I agree.

[Frank Mehnert]

Done so in 2.1.4.