It has been a few months since the last comment. If no solution along the lines of those outlined earlier (see comments #28, #29, #34, #37) is forthcoming then nm-dnsmasq should simply be put back into strict-order mode, thus reversing the change made at the suggestion of bug #903854.
Stéphane wrote in #37: > Switching back to strict-order is a bad idea for the reasons > listed in bug 903854, namely, we'd loose our biggest > advantage from using dnsmasq. The biggest advantage is only a performance advantage under some circumstances. This in no way stacks up against outright failure under other circumstances — circumstances typical of many LANs. If no solution for this bug (#1003842) is forthcoming then it is time to admit that switching off strict-order was the wrong thing to do. Knowing what we know now, we should switch it back on, and only switch it off again when a solution has been found for this bug. If switching on strict- order eliminates the only advantages of using nm-dnsmasq then nm-dnsmasq itself should be switched off (as proposed at bug #1086693) until that time. -- 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 : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
