Why DNS stops resolving under QEMU "user networking" when the host roams to a particular network?

Question

I use GNOME Boxes on a laptop. The guest machines get the Internet connection automatically with default settings whenever the laptop moves between networks (Ethernet, Wi-Fi in different locations, or a cellular phone as a USB modem).

The guest machines are not bridged with the host and are not visible on the host's LAN implying that the MAC addresses of the guests are overwritten before passing the frames to the host's LAN.

By default QEMU will create a SLiRP user network backend and an appropriate virtual network device for the guest…

User Networking is implemented using "slirp", which provides a full TCP/IP stack within QEMU and uses that stack to implement a virtual NAT'd network.

QEMU's final, and most bizarre, networking option is also its default option. What this does is connect a "usermode network stack" to a vlan. This network stack is a standalone implementation of the ip, tcp, udp, dhcp and tftp (etc.) protocols. It can handle frames from the vlan by e.g. responding to dhcp requests with a valid address, responding to tftp requests with a file from the host filesystem or by creating udp/tcp sockets over which packet data can be forwarded.

Note that this network stack is running within the qemu process itself. So, for example there is no separate dhcp or tftp process handling those requests. Also, the stack is effectively acting as a proxy by unpacking application data from udp/tcp packets and forwarding them over a socket connecting the qemu process and the destination process.

Note, in the above context, "vlan" stands for "emulated" LAN, it doesn't mean IEEE 802.1Q VLAN ID.

By default, the guest has 10.0.2.15 IP address on 10.0.2.0/24 network. The gateway is 10.0.2.2. The DNS server is 10.0.2.3. The guest can access the host by connecting on 10.0.2.2 gateway IP.

At a particular Wi-Fi network, all guest machines lose Internet access. I found another question about lack of Internet in the guest under QEMU, which discovered that DNS may not work out-of-the-box under certain setup. So, I checked mine. I can access websites by their IP from the guest. Also, if I configure an IPv4 connection manually, resolving gets restored if I add another known resolver, such as 8.8.8.8, as a backup in addition to the default 10.0.2.3.

According to the local administrator, this Wi-Fi network has VLAN tagging enabled to separate local computers from visitors' computers. Apparently, if VLAN were an issue, it would cause complete loss of Internet access, not just resolving.

Another particularity of that network is that the first DNS resolver is configured to refuse most request. The second resolver 8.8.8.8 is provided, but, apparently, not used by QEMU.

The issue persists across devices. I tried on two completely different laptops with Intel wireless. The issue is found in Debian "Buster" at least since 10.4, "Bullseye" and "Sid".

Answer 1

In the default "user mode" networking, QEMU uses only the first DNS nameserver from the host machine. So, if that nameserver doesn't resolve properly, QEMU will not fallback to any other nameservers which may be configured as secondary at the host. It results in the apparent loss of Internet connection by the guests while the host can still use its fallback nameservers "hiding" the problem.

It is a known QEMU behavior, which is not expected to be fixed in QEMU. Here is a quote from a Debian Bug report log #625689 from 2011:

No the limitation isn't documented (yet), and it will be difficult to fix too, or maybe not worth a trouble really. Two reasons. First of all, user-mode networking is not suitable for anything serious, you really want tap networking with bridges, which is about 100 times faster and actually works (e.g. ICMP). Second, the implementation is rather simplistic - for DNS it merely forwards (like a NAT box) packets from guest to a nameserver from host /resolv.conf - only one nameserver, because you can't NAT to TWO destinations at once. So in order to fix that, qemu has to become application-level proxy for DNS, instead of a simplande NAT "device".

It is easy to reproduce the issue by adding some garbage as the first nameserver to /etc/resolv.conf at the host. The guest stops resolving immediately.

For a Debian guest machine, to restore networking, it was enough to add another known resolver, such as 8.8.8.8, to /etc/resolv.conf. Such change of configuration does not survive rebooting the guest.