On 04/02/13 22:05, Thomas Hood wrote: > Simon in #49: >> It doesn't work [...] the order of servers given to the DBus >> interface isn't preserved internally > > Aha, so the answer to my question > >> Will switching on strict-order have the same effect >> now that nameserver addresses are sent over D-Bus? > > (in comment #42) is "No". So switching strict-order back on is no > solution. And solutions depending on strict-order including mine in #28 > also won't work. Unless dnsmasq is somehow changed such that it > remembers the order in which nameserver addresses come in over D-Bus so > that strict-order is useful in the D-Bus case, if we want to avoid > breaking name service on machines connected to NNNs then we have to > disable dnsmasq by default; or disable it initially and only enable it > when we know that we aren't on a NNN.
Note that setting --strict-order is pretty much equivalent to telling dnsmasq to use only the first nameserver, so you can very easily provide the same behaviour - only pass the first nameserver to dnsmasq. Maybe provide a button in NM that does this - "press here if you're in a captive portal". > > (NNN = nonequivalent-nameserver network. As discussed in comment #5, > such networks are not properly configured. But as observed several > times, there are many NNNs out there. Which is why *many* people have > been commenting out "dns=dnsmasq".) > > There is another problem with NM-dnsmasq (bug #1072899). Some VPNs have > multiple nameservers. NM uses dnsmasq to direct VPN domain name queries > to the *first* one. But then, if the first one goes down, the second one > is not tried. Once again, for the sake of speed enhancement in the > favorable case, users suffer radical name service failure in the > unfavorable case. This is not a good deal, IMHO. NM-dnsmasq should be > disabled by default until these problems are solved. That's a different problem, and could be solved. Ironically, I think the problem arises because for nameservers associated with particular domains, the equivalent of --strict-order is always in play. Cheers, Simon. > -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
