Re: [Dnsmasq-discuss] Query forwarding behaviour with multiple name servers.
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). I’ve removed the ‘backup resolver’ from their config, cloud systems get very fast response times from google! On Thu, 7 Mar 2019 at 18:24, Simon Kelley wrote: > On 08/02/2019 09:49, John Robson wrote: > > Hi all, > > > > I'm trying to understand the mechanism by which dnsmasq uses the > > resolvers specified (in this case they are all specified in > > /etc/resolv.conf). > > Specifically I am trying to work out why dnsmasq is (erratically) > > sending the same query to multiple servers, and not listening beyond the > > first response. > > > > > > As I understand it the default (i.e. non dnsmasq) resolver behaviour is > > to try the first name server entry first, then the second etc. This can > > be changed by use of the 'rotate' option in that file. > > > > However, dnsmasq reads it's name servers from /etc/resolv.conf, but the > > defaults are different - relevant options from the man page say: > > *-o, --strict-order* > > By default, dnsmasq will send queries to any of the upstream servers > > it knows about and tries to favour servers that are known to be up. > > Setting this flag forces dnsmasq to try each query with each server > > strictly in the order they appear in /etc/resolv.conf > > *--all-servers* > > By default, when dnsmasq has more than one upstream server > > available, it will send queries to just one server. Setting this > > flag forces dnsmasq to send all queries to all available servers. > > The reply from the server which answers first will be returned to > > the original requester. > > > > To me that means that, by default, dnsmasq will send to any one of the > > upstream servers, favouring servers it thinks are up - that seems > > reasonable. > > > > > > What I am seeing is that sometimes (and I can't figure a packet count, a > > query count, or a time based correlation) dnsmasq forwards a query to > > both of the listed name servers (I presume this is part of the > > 'aliveness' testing?). > > When this happens dnsmasq then only listens to the first reply, meaning > > that the server which is slightly slower/further away then gets their > > response bounced in an ICMP port unreachable message from the dnsmasq > box. > > > > I then see dnsmasq stick to the 'first responding' server until it > > forwards a query to both again (always in the same order, that listed in > > /etc/resolv.conf) and, depending on the first response, it either sticks > > or flips it's preferred server until ??? > > > > > > Two questions: > > - What triggers dnsmasq to forward a query to multiple upstream > > resolvers (aside from the first query after startup, which seems > reasonable) > > Kevin answered this. > > > - Why does dnsmasq not bother to listen for the second (or more) > > response - which would surely be useful in terms of timing/aliveness > > information, as well as less odd for the upstream server*. > > Because to do so involves keeping resources around: at least some state > and an open network socket. Since a server may never respond, those > resources have to be reclaimed at some point (this functions exists > already, since no answer may be forthcoming from any server) If dnsmasq > is sending queries to a server which never answers, that implies far > more resources hanging around during a long timeout, which increases the > resource footprint for the daemon, and maybe even provides an DoS attack > opportunity. TBH, it never occurred to me that the subsequent replies > had any real utility, but I can see that they might. I'm not aware of > any DNS server which would react in any way to an ICMP port unreachable. > Don't forget that this is UDP. The server sends the reply "fire an > forget". I think it would be next to impossible to get the OS to even > tell the server that the port unreachable message had been seen. > > > Cheers, > > Simon. > > > > > > Cheers, > > > > John > > > > > > * I can imagine an upstream server eventually deciding that it is being > > used in an amplification attack and just not responding any more. > > > > > > -- > > > > > > ___ > > 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 > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query forwarding behaviour with multiple name servers.
On 08/02/2019 09:49, John Robson wrote: > Hi all, > > I'm trying to understand the mechanism by which dnsmasq uses the > resolvers specified (in this case they are all specified in > /etc/resolv.conf). > Specifically I am trying to work out why dnsmasq is (erratically) > sending the same query to multiple servers, and not listening beyond the > first response. > > > As I understand it the default (i.e. non dnsmasq) resolver behaviour is > to try the first name server entry first, then the second etc. This can > be changed by use of the 'rotate' option in that file. > > However, dnsmasq reads it's name servers from /etc/resolv.conf, but the > defaults are different - relevant options from the man page say: > *-o, --strict-order* > By default, dnsmasq will send queries to any of the upstream servers > it knows about and tries to favour servers that are known to be up. > Setting this flag forces dnsmasq to try each query with each server > strictly in the order they appear in /etc/resolv.conf > *--all-servers* > By default, when dnsmasq has more than one upstream server > available, it will send queries to just one server. Setting this > flag forces dnsmasq to send all queries to all available servers. > The reply from the server which answers first will be returned to > the original requester. > > To me that means that, by default, dnsmasq will send to any one of the > upstream servers, favouring servers it thinks are up - that seems > reasonable. > > > What I am seeing is that sometimes (and I can't figure a packet count, a > query count, or a time based correlation) dnsmasq forwards a query to > both of the listed name servers (I presume this is part of the > 'aliveness' testing?). > When this happens dnsmasq then only listens to the first reply, meaning > that the server which is slightly slower/further away then gets their > response bounced in an ICMP port unreachable message from the dnsmasq box. > > I then see dnsmasq stick to the 'first responding' server until it > forwards a query to both again (always in the same order, that listed in > /etc/resolv.conf) and, depending on the first response, it either sticks > or flips it's preferred server until ??? > > > Two questions: > - What triggers dnsmasq to forward a query to multiple upstream > resolvers (aside from the first query after startup, which seems reasonable) Kevin answered this. > - Why does dnsmasq not bother to listen for the second (or more) > response - which would surely be useful in terms of timing/aliveness > information, as well as less odd for the upstream server*. Because to do so involves keeping resources around: at least some state and an open network socket. Since a server may never respond, those resources have to be reclaimed at some point (this functions exists already, since no answer may be forthcoming from any server) If dnsmasq is sending queries to a server which never answers, that implies far more resources hanging around during a long timeout, which increases the resource footprint for the daemon, and maybe even provides an DoS attack opportunity. TBH, it never occurred to me that the subsequent replies had any real utility, but I can see that they might. I'm not aware of any DNS server which would react in any way to an ICMP port unreachable. Don't forget that this is UDP. The server sends the reply "fire an forget". I think it would be next to impossible to get the OS to even tell the server that the port unreachable message had been seen. Cheers, Simon. > > Cheers, > > John > > > * I can imagine an upstream server eventually deciding that it is being > used in an amplification attack and just not responding any more. > > > -- > > > ___ > 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
Re: [Dnsmasq-discuss] Query forwarding behaviour with multiple name servers.
Aha! I know this (it’s a Unix system… /) > On 8 Feb 2019, at 09:49, John Robson wrote: > > Hi all, > > I'm trying to understand the mechanism by which dnsmasq uses the resolvers > specified (in this case they are all specified in /etc/resolv.conf). > Specifically I am trying to work out why dnsmasq is (erratically) sending the > same query to multiple servers, and not listening beyond the first response. > Two questions: > - What triggers dnsmasq to forward a query to multiple upstream resolvers > (aside from the first query after startup, which seems reasonable) From src/config.h #define FORWARD_TEST 50 /* try all servers every 50 queries */ #define FORWARD_TIME 20 /* or 20 seconds */ The thread http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q2/012226.html > - Why does dnsmasq not bother to listen for the second (or more) response - > which would surely be useful in terms of timing/aliveness information, as > well as less odd for the upstream server*. Now that I cannot answer. Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Query forwarding behaviour with multiple name servers.
Hi all, I'm trying to understand the mechanism by which dnsmasq uses the resolvers specified (in this case they are all specified in /etc/resolv.conf). Specifically I am trying to work out why dnsmasq is (erratically) sending the same query to multiple servers, and not listening beyond the first response. As I understand it the default (i.e. non dnsmasq) resolver behaviour is to try the first name server entry first, then the second etc. This can be changed by use of the 'rotate' option in that file. However, dnsmasq reads it's name servers from /etc/resolv.conf, but the defaults are different - relevant options from the man page say: *-o, --strict-order*By default, dnsmasq will send queries to any of the upstream servers it knows about and tries to favour servers that are known to be up. Setting this flag forces dnsmasq to try each query with each server strictly in the order they appear in /etc/resolv.conf*--all-servers*By default, when dnsmasq has more than one upstream server available, it will send queries to just one server. Setting this flag forces dnsmasq to send all queries to all available servers. The reply from the server which answers first will be returned to the original requester. To me that means that, by default, dnsmasq will send to any one of the upstream servers, favouring servers it thinks are up - that seems reasonable. What I am seeing is that sometimes (and I can't figure a packet count, a query count, or a time based correlation) dnsmasq forwards a query to both of the listed name servers (I presume this is part of the 'aliveness' testing?). When this happens dnsmasq then only listens to the first reply, meaning that the server which is slightly slower/further away then gets their response bounced in an ICMP port unreachable message from the dnsmasq box. I then see dnsmasq stick to the 'first responding' server until it forwards a query to both again (always in the same order, that listed in /etc/resolv.conf) and, depending on the first response, it either sticks or flips it's preferred server until ??? Two questions: - What triggers dnsmasq to forward a query to multiple upstream resolvers (aside from the first query after startup, which seems reasonable) - Why does dnsmasq not bother to listen for the second (or more) response - which would surely be useful in terms of timing/aliveness information, as well as less odd for the upstream server*. Cheers, John * I can imagine an upstream server eventually deciding that it is being used in an amplification attack and just not responding any more. -- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
