On 06/02/13 09:18, Thomas Hood wrote: > [...cont'd after "in order to fix"...] bug #1072899, dnsmasq will > have to be enhanced such that proposition #1 is true. But we can > discuss the details of that in bug #1072899. > > <parenthesis> There is a close analogy between the problem here (bug > #1003842) and a problem we have with avahi. Avahi resolves names in > the domain ".local". Networks should not use this TLD, but many do > and at least in the past Microsoft actually recommended doing so. > When users connect to such networks with avahi enabled the result is > malfunction. Upstream purisitically says[*] "If you come across a > network where .local is a unicast DNS domain, please contact the > local administrator and ask him to move his DNS zone to a different > domain. If this is not possible, we recommend not to use Avahi in > such a network at all." In practice avahi attempts to detect "bad" > networks and disables itself if it thinks it is on a bad network, > subject unfortunately both to false positives (bug #327362) and false > negatives (bug #80900). > > We aren't yet doing even that well. We say that networks ought to > have equivalent nameservers and we make no attempt to detect networks > that have non-equivalent nameservers, of which there are very many. > > [*]http://avahi.org/wiki/AvahiAndUnicastDotLocal </parenthesis> >
Detect non-equivalent servers is hard. I'm very much in favour of doing it, if a way can be found. Simon. -- 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
