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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1163147 Title: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1163147/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
