On 06/03/13 17:32, Sjors Gielen wrote:
Op 04-03-13 00:29, Ed W schreef:
Dnsmasq by default queries all dnsservers simultaneously and locks
onto the one which gives the fastest response (rechecking every few
queries or every 60 seconds - or some numbers like that)
So I guess it's just bad luck that the fastest resolver has a bad
record?
Thanks for your response. In my tests the two main resolvers were
both equally fast (≈ 1 ms as they had the results cached), so even
though one may be a tiny bit quicker than the other, I doubt it would
be an explanation for it choosing a specific server 19 out of 20
times. Though it would be interesting to verify this; is there some
debug option that shows dnsmasq's train of thought?
The decision is made by which resolver's packet arrives first, so
microseconds count: I guess the ultimate arbiter is the first common
switch in the path from the resolvers to the host running dnsmasq.
Of course, one resolver will have an advantage because it gets the query
sent to it first. The order that the query is sent to the resolvers
isn't defined, but it's probably a consistent function of their order in
the configuration file.
Using strictorder should prove that this is the case?
What do you mean here?
strict-order tell dnsmasq to always send queries to one server at a
time, in the order they appear in /etc/resolv.conf. Since it defeats the
ability of dnsmasq to pick the resolvers which are up and fast, it's not
recommended.
Cheers,
Simon.
Thanks, Sjors
_______________________________________________ Dnsmasq-discuss
mailing list Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
