VirtualBox

Ticket #1470 (closed defect: fixed)

Opened 6 years ago

Last modified 4 years ago

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

Reported by: znerol Owned by:
Priority: major Component: network/NAT
Version: VirtualBox 1.5.6 Keywords:
Cc: Guest type: other
Host type: Linux

Description

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.

Attachments

resolv.conf_from_stephanecharette Download (191 bytes) - added by stephanecharette 5 years ago.
/etc/resolv.conf from Stéphane Charette
ifconfig_output.txt Download (978 bytes) - added by stephanecharette 5 years ago.
ifconfig output from Stéphane Charette

Change History

comment:1 Changed 6 years ago by 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

comment:2 Changed 6 years ago by stephanecharette

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.

comment:3 Changed 6 years ago by 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

comment:4 Changed 6 years ago by frank

  • Host type changed from other to Linux

comment:5 Changed 6 years ago by frank

  • Component changed from other to network

comment:6 follow-up: ↓ 7 Changed 6 years ago by stephanecharette

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.

comment:7 in reply to: ↑ 6 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by cdhowie

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.

comment:9 Changed 5 years ago by cdhowie

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?

comment:10 Changed 5 years ago by frank

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

comment:11 Changed 5 years ago by stephanecharette

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

Changed 5 years ago by stephanecharette

/etc/resolv.conf from Stéphane Charette

comment:12 Changed 5 years ago by frank

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

Changed 5 years ago by stephanecharette

ifconfig output from Stéphane Charette

comment:13 Changed 5 years ago by stephanecharette

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.

comment:14 Changed 5 years ago by frank

/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.

comment:15 Changed 5 years ago by cdhowie

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?

comment:16 follow-up: ↓ 17 Changed 5 years ago by frank

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.

comment:17 in reply to: ↑ 16 Changed 5 years ago by cdhowie

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.

comment:18 follow-up: ↓ 19 Changed 5 years ago by themadsens

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

comment:19 in reply to: ↑ 18 ; follow-up: ↓ 20 Changed 5 years ago by cdhowie

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.

comment:20 in reply to: ↑ 19 Changed 5 years ago by themadsens

Replying to cdhowie:

it should use exactly the addresses it contains.

Agreed!

comment:21 Changed 5 years ago by frank

Actually this issue should be fixed in VirtualBox 2.1.0.

comment:22 follow-up: ↓ 23 Changed 5 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed
  • Component changed from network to network/NAT
  • Summary changed from DNS Resolver/NAT does not work if a local DNS is running (Linux Host, Any Guest) to DNS Resolver/NAT does not work if a local DNS is running (Linux Host, Any Guest) => Fixed in 2.1.0

comment:23 in reply to: ↑ 22 Changed 5 years ago by mdecky

  • Status changed from closed to reopened
  • Resolution fixed deleted

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)
             {

comment:24 Changed 5 years ago by frank

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.

comment:25 Changed 5 years ago by mdecky

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.

comment:26 Changed 5 years ago by frank

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.

comment:27 Changed 5 years ago by mdecky

OK, I agree.

comment:28 Changed 5 years ago by frank

  • Status changed from reopened to closed
  • Resolution set to fixed

Done so in 2.1.4.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use