[Dnsmasq-discuss] Dnsmasq switching to using secondary DNS exclusively

JD jd1008 at gmail.com
Mon Aug 17 19:46:48 BST 2009



On 08/17/2009 09:06 AM, Simon Kelley wrote:
> JD wrote:
>>
>> On 08/17/2009 08:47 AM, Simon Kelley wrote:
>>> Michael Kraft wrote:
>>>> I have a WRT54GLv1 with Tomato 1.25 on it.  Tomato uses Dnsmasq 
>>>> 2.47 for
>>>> DNS.  I realize the latest Dnsmasq is 2.49, but I don't see 
>>>> anything in
>>>> the change log related to what I'm seeing.   I have tomato set up to
>>>> cache DNS (150 entries) and handle the DNS queries itself.  This 
>>>> results
>>>> in a dnsmasq.conf of:
>>>>
>>>> pid-file=/var/run/dnsmasq.pid
>>>> interface=br0
>>>> resolv-file=/etc/resolv.dnsmasq
>>>> addn-hosts=/etc/hosts.dnsmasq
>>>> expand-hosts
>>>> min-port=4096
>>>> dhcp-range=192.168.1.100,192.168.1.149,255.255.255.0,10080m
>>>> dhcp-option=3,192.168.1.1
>>>> dhcp-lease-max=255
>>>> dhcp-authoritative
>>>> dhcp-host=00:13:CE:2A:1E:82,192.168.1.6,10080m
>>>>
>>>> The resolv.dnsmasq is:
>>>> nameserver 68.87.64.146
>>>> nameserver 68.87.75.194
>>>>
>>>> resolv.conf is:
>>>> nameserver 127.0.0.1
>>>>
>>>> So my primary DNS is 68.87.64.146 and my secondary DNS is 
>>>> 68.87.75.194.
>>>>
>>>> Every now and then the router starts using the secondary DNS
>>>> exclusively.  During this time the dnsmasq.conf and resolv.dnsmasq 
>>>> don't
>>>> change.  I can get the router to start using the primary DNS again by
>>>> killing and restarting Dnsmasq (or refreshing the DHCP release from my
>>>> ISP).
>>>>
>>>> It's my understanding that the secondary DNS should only be used if 
>>>> the
>>>> primary DNS doesn't answer the DNS query, but at the times I'm
>>>> experiencing the problem the primary DNS is responding to queries so
>>>> Dnsmasq should be using that.  There is nothing in the logs that 
>>>> seem to
>>>> indicate any kind of problem as far as I can tell.  The only log 
>>>> entries
>>>> I ever see relating to nameservers look like the following with the
>>>> secondary listed first and the primary listed second:
>>>>
>>>> Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver
>>>> 68.87.75.194#53
>>>> Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver
>>>> 68.87.64.146#53
>>>>
>>>>
>>>> Since my ISP's secondary DNS is a lot farther away geographically from
>>>> me than the primary, this not only slows down DNS queries, but causes
>>>> performance issues with Limelight, Akamai and any other server that
>>>> determines the server farm, by the DNS location.
>>>>
>>>> My question is why would Dnsmasq be switching to using the 
>>>> secondary DNS
>>>> exclusively and how (short of removing the secondary DNS server
>>>> manually) can I stop it from doing this?
>>> Dnsmasq doesn't treat these servers as primary and secondary - it
>>> considers them equal. The reason that the server in use changes is that
>>> dnsmasq sometimes sends a query to both servers, to see which one is
>>> fastest. Whichever replies first gets used until the next time the
>>> "race" gets run.
>>>
>>> You can change this behaviour with "strict-order", but be aware that
>>> will make performance much worse if the first server ever does fail.
>>>
>>>
>>> Cheers,
>>>
>>> Simon.
>>>
>>
>> That still does not explain why dnsmasq sticks with a nameserver that 
>> is slow???
>> Is it possible to have a config option that will force dnsmasq to 
>> switch server if no
>> response comes within a user-settable timeout?
>>
>> JD
>
> It does that test once, and uses which ever server is faster 
> _for_that_query_. That could be affected by cache effects in the 
> upstream server. The test is not run again until a query times-out 
> then the retry is sent to both servers to see which one will reply first.

Yes indeed it is. I have run timings on the primary and the secondary.
The secondary is always much much slower.
This is why I think that the speed of response test ought to be run
via  a  user settable option as far as test frequency, and timeout 
threshold.

>
> Are you sure that your "secondary" is in fact slower?
>
>
> Cheers,
>
> Simon.
>

Regards,

Joe



More information about the Dnsmasq-discuss mailing list