© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
Simon wrote:
> Consider
[...]
> server=
> server=
[...]
> 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.)