Comment 58 for bug 1003842

Revision history for this message
Simon Kelley (simon-thekelleys) wrote : Re: [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers

On 06/02/13 08:59, Thomas Hood wrote:
> Hi Simon.
>
> Before I forget to ask: can you please update dnsmasq(8) to include
> under "--strict-order" a description of what happens when nameserver
> addresses are passed in via D-Bus instead of via a file?
>
> You wrote,
>> you can very easily provide the same behaviour - only pass the first nameserver to dnsmasq
>
> Because NM doesn't use dnsmasq to cache, if NM were to give dnsmasq only
> one address then I guess the only service that dnsmasq would still
> provide is that of name-to-server mapping.
>
> And it turns out that the way NM currently uses dnsmasq to do this is
> seriously flawed. So I conclude that it's better for NM not to use
> dnsmasq at all until these problems are solved.
>
>> [That NM only supplies one nameserver address per domain name]
>> is a different problem, and could be solved.
>
>>From the man page it's not completely clear how to solve it. Can you
> confirm (1) that it's possible to give multiple server options as
> follows
>
> server=/google.com/1.2.3.4
> server=/google.com/5.6.7.8
>
> and that the result will be that 1.2.3.4 and 5.6.7.8 will be treated
> equally for the purpose of resolving names in domain google.com? (2) And
> likewise via D-Bus?
>
> (3) What effect does strict-order have on this?
>
>> Ironically, I think the
>> problem arises because for nameservers associated with particular
>> domains, the equivalent of --strict-order is always in play.
>
> What you say here suggests that my proposition #1 above is false. If #1
> is false then it seems that in order to fix
>

proposition #1 is true, as is #2: you can configure the same thing via DBus.

Consider

server=1.1.1.1
server=2.2.2.2
server=/google.com/3.3.3.3
server=/google.com/4.4.4.4

Queries not sent to *.google.com will behave in the normal dnsmasq
manner, sent non-deterministically to 1.1.1.1 and/or 2.2.2.2 in a way
which tries to favour the fastest/most up 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.

Cheers,

Simon.