Ubuntu
dnsmasq package

  1. Bug #1003842
  2. Comment #28

Comment 28 for bug 1003842

Revision history for this message
Thomas Hood (jdthood) wrote : Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers

Background: Using dnsmasq can give rise to resolution failures on VPNs and other nonequivalent-nameserver networks (NNNs) where early-listed nameservers have more information than later-listed ones. As Sergio (comment #15) and others point out, the failures are grave: dnsmasq might fail to resolve certain names every time. Now, in the case of a VPN we know we're on a VPN and we could solve the problem by having NM or resolvconf feed only the VPN nameserver addresses to dnsmasq (see Scott's comment #3). But this won't work for NNNs in general. Sergio suggested in #19 that some listed nameserver address being in a local IP address range be used as a trigger to switch dnsmasq to strict-order mode. This would indeed catch all the NNNs (including the VPNs), assuming that all special local nameservers have local IP addresses; but it would also result in some false positives and is subject to pdf's criticisms in comment #20. So we are trying to think of an algorithm for detecting all and only NNNs. Such an algorithm would have to be implemented in dnsmasq because only it has access to the required information.

Simon in #27> I worry that #17 will make (real) NXDOMAIN/NODATA replies much slower, since there at least two round-trips, and possibly a timeout, if a server never replies.

OK, here's #17 but with immediate return as in #18.

#28: "On encountering NODATA or NXDOMAIN, dnsmasq returns the negative result immediately but also reiterates the query to all nameservers listed earlier than the one that answered. If one of those nameservers returns an address then dnsmasq switches to strict-order mode until the next change in the nameserver address list."

With this approach there is no delay in returning results; NNNs are detected quickly, yet the number of duplicated DNS queries is limited; on NNNs, dnsmasq fails to return one or a few addresses before switching modes, but thereafter does not. The disadvantages of strict-order mode can be avoided even on NNNs if "lookup routing" (i.e., the --server=/name/adress feature) is properly configured. (This won't be easy to configure given that the networking environment changes a lot. Could dnsmasq be made smart enough to figure out the appropriate lookup routing on the fly? I don't see how, but maybe someone else has a good idea.)
--
Thomas