<div><div dir="auto">In the case I was seeing ... one of the three servers was returning nxdomain for internal queries (user had defined google as a ‘backup’ resolver). So the subsequent replies had massive value (they contained information, rather than no information).</div></div><div dir="auto"><br></div><div dir="auto">I’ve removed the ‘backup resolver’ from their config, cloud systems get very fast response times from google!</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 7 Mar 2019 at 18:24, Simon Kelley <<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/02/2019 09:49, John Robson wrote:<br>
> Hi all,<br>
> <br>
> I'm trying to understand the mechanism by which dnsmasq uses the<br>
> resolvers specified (in this case they are all specified in<br>
> /etc/resolv.conf).<br>
> Specifically I am trying to work out why dnsmasq is (erratically)<br>
> sending the same query to multiple servers, and not listening beyond the<br>
> first response.<br>
> <br>
> <br>
> As I understand it the default (i.e. non dnsmasq) resolver behaviour is<br>
> to try the first name server entry first, then the second etc.  This can<br>
> be changed by use of the 'rotate' option in that file.<br>
> <br>
> However, dnsmasq reads it's name servers from /etc/resolv.conf, but the<br>
> defaults are different - relevant options from the man page say:<br>
> *-o, --strict-order*<br>
>     By default, dnsmasq will send queries to any of the upstream servers<br>
>     it knows about and tries to favour servers that are known to be up.<br>
>     Setting this flag forces dnsmasq to try each query with each server<br>
>     strictly in the order they appear in /etc/resolv.conf<br>
> *--all-servers*<br>
>     By default, when dnsmasq has more than one upstream server<br>
>     available, it will send queries to just one server. Setting this<br>
>     flag forces dnsmasq to send all queries to all available servers.<br>
>     The reply from the server which answers first will be returned to<br>
>     the original requester.<br>
> <br>
> To me that means that, by default, dnsmasq will send to any one of the<br>
> upstream servers, favouring servers it thinks are up - that seems<br>
> reasonable.<br>
> <br>
> <br>
> What I am seeing is that sometimes (and I can't figure a packet count, a<br>
> query count, or a time based correlation) dnsmasq forwards a query to<br>
> both of the listed name servers (I presume this is part of the<br>
> 'aliveness' testing?).<br>
> When this happens dnsmasq then only listens to the first reply, meaning<br>
> that the server which is slightly slower/further away then gets their<br>
> response bounced in an ICMP port unreachable message from the dnsmasq box.<br>
> <br>
> I then see dnsmasq stick to the 'first responding' server until it<br>
> forwards a query to both again (always in the same order, that listed in<br>
> /etc/resolv.conf) and, depending on the first response, it either sticks<br>
> or flips it's preferred server until ???<br>
> <br>
> <br>
> Two questions:<br>
>  - What triggers dnsmasq to forward a query to multiple upstream<br>
> resolvers (aside from the first query after startup, which seems reasonable)<br>
<br>
Kevin answered this.<br>
<br>
>  - Why does dnsmasq not bother to listen for the second (or more)<br>
> response - which would surely be useful in terms of timing/aliveness<br>
> information, as well as less odd for the upstream server*.<br>
<br>
Because to do so involves keeping resources around: at least some state<br>
and an open network socket. Since a server may never respond, those<br>
resources have to be reclaimed at some point (this functions exists<br>
already, since no answer may be forthcoming from any server) If dnsmasq<br>
is sending queries to a server which never answers, that implies far<br>
more resources hanging around during a long timeout, which increases the<br>
resource footprint for the daemon, and maybe even provides an DoS attack<br>
opportunity. TBH, it never occurred to me that the subsequent replies<br>
had any real utility, but I can see that they might. I'm not aware of<br>
any DNS server which would react in any way to an ICMP port unreachable.<br>
Don't forget that this is UDP. The server sends the reply "fire an<br>
forget". I think it would be next to impossible to get the OS to even<br>
tell the server that the port unreachable message had been seen.<br>
<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<br>
<br>
> <br>
> Cheers,<br>
> <br>
> John<br>
> <br>
> <br>
> * I can imagine an upstream server eventually deciding that it is being<br>
> used in an amplification attack and just not responding any more.<br>
> <br>
> <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" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><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" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div>
</div>