<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
No, but it provides me with a perfect opportunity for a public service announcement, since this information needs to go to a wider audience.</blockquote><div><br></div><div>IMHO, the best place for such information is here: <a href="http://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html">http://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html</a></div>
<div>Much wider audience.</div><div><br></div><div>I think the logging has contributed to the confusion as well. First, use of strongly discouraged options ought to generate a warning at startup. Next, in a configuration with multiple DNS servers, knowing which one responded could be pretty important but I don't see that information in the log above (just a supposition that since the response came after the third request that it came from the third server). At least I'm not convinced that an early nameserver didn't simply spend a full second doing disk I/O to check its cache, contacting upstream nameservers, bringing up a vpn connection to the upstream nameserver, etc.</div>
<div><br></div><div>Just my 2cents.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
Sorry about the shouting;<br>
<br>
DON'T USE --STRICT-ORDER<br>
<br>
Strict-order almost never does what people expect/want it to do, which is to put a priority order on the list of servers in /etc/resolv.conf. It mainly just disrupts dnsmasq's mechanism for dealing with broken or down servers. If I could, I'd remove it. If there is ever dnsmasq-3, it will go.<br>
<br>
<br>
If you remove --strict order, then dnsmasq will send the first query, in parallel, top all the name servers. It will note that first one which provides a good answer, and use just that until a query times-out, when it will "run the race" over all the servers again.<br>
<br>
BTW My guess is that the behaviour difference you are seeing in how the queries are handled is because the repeated query from 127.0.0.1 doesn't have the same transaction-id as teh first query, so dnsmasq doesn't recognise it as a retry.<br>
<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<br>
<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div><br>