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"?

With the current behavior, whenever I need to access a captive portal, I 
basically have to press the "reload page" button 50 times until for some 
reasons 
the order in which the nameservers reply becomes the good one.

Cheers,

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

Reply via email to