Simon wrote:
> Consider
[...]
> server=/google.com/3.3.3.3
> server=/google.com/4.4.4.4
[...]
> Queries sent to *google.com will be sent 3.3.3.3 or 4.4.4.4 in the
> same way as if strict order was set, ie, to 3.3.3.3 first, and only to
> 4.4.4.4 if 3.3.3.3 returns a SERVFAIL or REFUSED error, or doesn't
> reply at all.
>
> This should be changed, but the code which implements it is knarly
> and old, and won't stand more tinkering, it needs rewriting. I've
> not found the time, as of yet.
That doesn't sound as if it's urgently needed for anything we are
talking about here.
What we do need is for strict-order to work when addresses are provided
over D-Bus. (That this requires work: see #49. That this is needed: see
below.)
>> 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.
>
> Detect non-equivalent servers is hard. I'm very much in favour of
> doing it, if a way can be found.
Well, let's look at the ideas that have been put forward so far.
Solution #1. Disable NM-dnsmasq by default. This is the only solution
we have right now.
Other ideas that probably need more thought...
Solution #2. Enhance dnsmasq such that it can be given an ordered list
of nameservers via D-Bus and can process this list in strict-order
fashion. Then do every lookup in strict-order fashion, but detect
offline nameservers and omit them temporarily from the list. (This is my
interpretation of Stéphane's suggestion in #37.)
Solution #3. Enhance dnsmasq such that it can be given an ordered list of
nameservers via D-Bus and can process this list in strict-order fashion. Then
do a given lookup in strict-order fashion if
* the lookup is being routed to a specific nameserver due to a "server"
option;
* the name is in one of the search domains returned by DHCP (as suggested
my M T-L in #34);
* the name is not in any of the recognized TLDs; or
* we have detected nameserver nonequivalence since the last time the list
of nameservers changed. The detection mechanism is as described in #28: on
encountering NODATA or NXDOMAIN, dnsmasq returns the negative result
immediately but also reiterates the query to all nameservers listed earlier
than the one that answered. If one of those nameservers later returns an
address then nameserver nonequivalence has been detected. (This combines
several earlier suggestions.)
--
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
