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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1003842
Title:
dnsmasq sometimes fails to resolve private names in networks with non-
equivalent nameservers
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
