Comment 36 for bug 1163147

Thomas, the more I've read about dnsmasq and the complaints from other
users in bug 1003842, the more I think that we might be better off taking
a different approach entirely. Please let me know what you think.

Your dnsmasq-A, dnsmasq-B, dnsmasq-C daisy-chain approach could probably
work. But guest VMs or guest LXC domains that are using dnsmasq-B couldn't
then look up hosts registered with dnsmasq-C.

This daisy chain would be brittle: if dnsmasq-B is stopped by the
administrator or otherwise dies, dnsmasq-C's configuration would need
to be updated to forward to dnsmasq-A instead.

And, libvirt-controlled guests and lxc-controlled guests would also
need networking properly configured to route between libvirt guests and
lxc guests. This might not be desirable. (In that case, you wouldn't
care that they couldn't look up hostname information from the other
virtualization technology anyway.)

So, instead of a chain, how about a flatter layout?

I haven't yet wrapped my head around the entirety of the implementation.
But I wanted to share what I'd thought of so far to get your feeling if
this is even useful to pursue to the end.

Have dnsmasq-lxc, dnsmasq-libvirt, authoritative for their own little
networks. If an lxc guest wants to resolve libvirt guests, the lxc guest
needs to have /etc/resolv.conf configured to query both dnsmasq-lxc
and dnsmasq-libvirt. If a libvirt guest wants to resolve lxc guests,
the libvirt guest needs to have /etc/resolv.conf configured to query
both dnsmasq-libvirt and dnsmasq-lxc.

If those guests also want to resolve LAN hosts or Internet hosts, they'll
need to add more "nameserver" lines. Don't abuse dnsmasq as a forwarder,
because it doesn't handle it as smoothly as it could.

The glibc resolver appears to handle multiple nameservers all configured
as 'nameserver' lines in /etc/resolv.conf even if they serve up different
data. dnsmasq does not appear to handle this case well (I think this is
what you called "NNN" in bug 1003842), and thus we should probably try to
avoid using dnsmasq in this way. If it were instead authoritative-only
for the dhcp-registered hosts, I have a feeling we could construct a
simpler answer.

We may need to increase MAXNS in /usr/include/resolv.h and rebuild nearly
everything. So I guess there are downsides. :)

If the glibc resolver doesn't actually handle multiple nameservers
with different data in them well, then probably Someone needs to write
a DNS resolver that can handle this well. Bug #1003842 would probably
also benefit from a dns resolver that forwards to all configured DNS
servers and tries to give the "best" of all available responses. (This
could eliminate the "rebuild everything" step, so it might be worthwhile
anyway.)

So, what do you think? Is there an argument to be made for a flat approach
that does not use the dnsmasq instances as forwarders? Or is the better
approach still the chaining approach, and hooking together libvirt, lxc,
and the various VPN servers in one long chain?

Thanks