On 04/02/2013 17:07, Simon Kelley wrote: > On 04/02/13 15:36, Sergio Callegari wrote: >> On 04/02/2013 15:40, Simon Kelley wrote: >>> On 03/02/13 07:48, Thomas Hood wrote: >>>>> there's still the unresolved question >>>>> of whether re-enabling --strict-order >>>>> will suffice as a workaround, since >>>>> 12.10 relies on DBus to populate the >>>>> nameservers. Is there any extra >>>>> information on this? >>>> Please try it and report back. :-) >>>> >>>> (Put "strict-order" in a file in /etc/NetworkManager/dnsmasq.d/; stop >>>> network-manager; make sure all dnsmasq processes are dead; start >>>> network-manager.) >>>> >>> It doesn't work: It will always use the same server first, but the order >>> of servers given to the DBus interface isn't preserved internally, and >>> actually changes each time the DBus interface is used. >>> >>> >>> Cheers, >>> >>> Simon. >> Isn't it possible to change dnsmasq behavior to query the servers in any >> order >> or in parallel and in the case the first server to reply says "I don't know" >> avoid relying on that information, rather wait and see if in a reasonable >> time >> some other server answers "I do"? > You're far from the first person to ask that question. The answer is > that there is no possible response in the DNS protocol which means "I > don't know". NXDOMAIN or NODATA answers _don't_ mean that; they mean "I > know that this domain doesn't exist". They also make up quite a large > proportion of the DNS results returned to the average host, so that all > of those queries would suddenly take much longer.
Yes, I realize that the problem is with the setup of the intranet, that should not add names to a domain that is known on the internet or invent a subdomain of something that is on the internet. But as a workaround, having a switch to activate "wait for further answers if you get an 'it does not exist'" would be nice for those willing to pay the price of a longer wait (or possibly even auto-activate it if a dns is detected to be on an intranet). Best regards, Sergio -- 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
