To Thomas in #9 >> Yet, it is sufficient to retry the operation to have a good chance of success.
> How does an application know that it should retry? It has received an authoritative answer on the first try that the name does not exist. Most things that are critical to operation get retried even automatically, no matter how authoritative the answer. It only depends on the trade off. If the trade off is to stay off the network at all, I guess the operation will first or later be retried. With sequential action, retry may likely succeed. With the current dnsmasq behavior, retry will likely not succeed and if you are behind an authorization portal you gonna stay off the network forever. Anyway this is the behavior that all the world has had with libc resolv up to yesterday, so it shouldn't look that weird. The alternative appears to me as saying that the way in which nameservers are used together with intranets is completely broken. >> An alternative would be not to search sequentially, but to keep asking the other nameservers > You mean send duplicate requests out every single time? >From what I understand, dnsmasq already asks all the servers concurrently. Meaning that if you have 3 nameservers, triple requests are sent. However, dnsmasq listens to the first answer only. While I suggest that if the first answer is "no, I do not know this host", some time is given to see if other answers come in too. Which may mean waiting a little, but not every single time. Just when you receive an answer like "I do not know this host" or when a name is really unknown to anybody. In common scenarios, maybe 3% of the time. Seems a tolerable price to pay for accessing nameservers in a non sequential way. -- 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: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed 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/network-manager/+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
