Comment 13 for bug 231060

Thierry Carrez wrote:
> @Simon: what are the options from a dnsmasq perspective ?
>

Some background: dnsmasq can run in two modes.

Default mode: dnsmasq binds the wildcard address and does network magic
to determine which interface request packets actually come from, so that
the results can be send back with the correct source address. This has
the advantage that network interfaces can come and go and change IP
address and dnsmasq will keep working. It's possible to restrict dnsmasq
to only reply to requests on some interfaces; requests from other
interfaces will be read by dnsmasq and then silently dropped. Telling
dnsmasq to use an interface which doesn't exist but might in the future
will result in a logged warning, but dnsmasq will still start and when
the interface comes up it will work.

Bind-interfaces mode: This is the traditional way to do UDP servers. At
startup dnsmasq enumerates all the extant interfaces and then opens a
socket for each one, listening on the interfaces's IP address.
Interfaces may be skipped if excluded by the --interface and
--except-interface flags, and any interface specified in --interface
which doesn't exist at start-up will generate a fatal error.

In almost all cases, default mode is better: --bind-interfaces is only
there to cope with old platforms which don't support enough socket
options to do default mode.

The only time when --bind-interfaces works better is when it's desirable
to run more than one instance of dnsmasq. This is not possible in
default mode, but it does work in bind-interfaces mode, providing than
_all_ instances are in bind-interfaces mode, and that they listen on a
disjoint set of interfaces. This is what the libvirt package attempts to
do, as I understand it: it starts its own dnsmasq in --bind-interfaces
mode listening on a virtual interface and it forces any "system" dnsmasq
into --bind-interfaces mode and away from the the virtual interface by
dropping a configuration fragment into /etc/dnsmasq.d

This method brings the disadvantages of --bind-interfaces to the private
libvirt dnsmasq instance (the race condition at start-up) and to the
"system" dnsmasq (which will no longer cope with changes to network
interfaces.)

Options.

1) Keep doing what you're doing, work around the race condition and
accept that installing libvirt will limit the functionality of a system
dnsmasq by forcing it into --bind-interfaces mode.

2) Arrange that if libvirt and a "system" dnsmasq co-exist, libvirt uses
the system dnsmasq, rather than starting its own. It should be possible
to drop some configuration to make the system dnsmasq do what is needed
  for libvirt. There's a problem here if libvirt is installed alone and
using a private dnsmasq, and then subsequently a system dnsmasq is
installed.

3) Make some changes to dnsmasq to improve the situation when two
instances are running. This may be possible, but I don't have many clues
what could be done.

4) Look at some sort of partitioning in the kernel so that the virtual
interface is in some sort of separate partition with effectively two
network stacks. A sort of chroot for networking. I don't know if this
exists in the Linux container stuff, or could be done. It's not really
my area.

HTH

Simon.