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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
