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