On Thu, Aug 8, 2013 at 7:26 PM, Seth Arnold <email address hidden> wrote:
> 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.


Yes, it's a characteristic of the daisy chain approach that query-upstream nameservers can consult query-downstream ones but not vice versa.


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


It's the intent that this be automated using resolvconf. That takes care of the case where an instance of dnsmasq is stopped correctly. It doesn't take care of the case where a dnsmasq instance crashes or is stopped improperly. If a query-downstream dnsmasq instance crashes then upstream instances won't be able to resolve any downstream names.


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


I don't understand you here.  Can you elaborate?


> So, instead of a chain, how about a flatter layout?
> [...]
> 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.


The glibc resolver is not a good place to route queries to different nameservers. The glibc resolver can only consult one nameserver at a time.  It queries the first nameserver in the list, waits five seconds, then queries the next nameserver in the list if it hasn't received a reply. Queries to the second nameserver are delayed by TIMEOUT every single time. Queries to the third nameserver are delayed by TIMEOUT * 2.  There can be no fourth nameserver.  That is not acceptable.  And shortening the timeout is no solution.


> Don't abuse dnsmasq as a forwarder,
> because it doesn't handle it as smoothly as it could.


Dnsmasq works very well as a forwarder.  And unlike the glibc resolver, dnsmasq can route queries by domain suffix without introducing delays, e.g., it can be configured to consult nameserver A for *.lbvrt and nameserver B for *.lxc.


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


Dnsmasq handles this case either as well as, or better than, the glibc resolver. If various nameservers are available, each containing different data, then either (1) dnsmasq can be run in strict-order mode, in which case it works in the same way as the glibc resolver in the relevant respect, or (2) dnsmasq can be told to route queries to nameservers by domain suffix, in which case it works much better than the glibc resolver because it processes the queries without delay.

Bug #1003842 does not necessarily detract from dnsmasq's usefulness in this case. Bug #1003842 is simply the fact that when dnsmasq is not running in strict-order mode and is given multiple nameservers to forward to (for a given domain) then it assumes that they are equivalent whereas on some networks the nameservers are not equivalent.


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


Yep, unfortunately MAXNS is not configurable at run time.
 

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


I don't want to repeat the bug #1003842 discussion here.


> 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?

The daisy chain approach will work and so will the routing-by-domain-name approach that Serge has proposed and which I discussed in comment #27.  Other solutions can be imagined.

Cheers