[Dnsmasq-discuss] using dnsmasq with 4 upstream servers

/dev/rob0 rob0 at gmx.co.uk
Fri Sep 2 17:39:12 BST 2016

On Fri, Sep 02, 2016 at 01:23:44PM +0200, Daniel Steglich wrote:
> I've got 4 upstream DNS Servers from my ISP (2 IPv4, 2 IPv6) and 
> use all of them in /etc/resolv.conf.

I think you'd be better off to simplify this.  Furthermore I am 
always leery of trusting ISP nameservers.  Sooner or later the ISP 
bosses get the idea to increase revenue with NXDOMAIN redirection.
Really, I'd trust Google before an ISP (but my own solution is to 
point dnsmasq at my own local caching resolver.)

> I start sending DNS SRV querys from a client to dnsmasq DNS relay 
> every 5 seconds.
> Each request is sent to four DNS upstream servers (primary DNS v4, 
> secondary DNS v4, primary DNS v6, secondary DNS v6). The answer 
> from the fastest server is used.
> As the requests are DNS SRV records, the reply is not cached by 
> dnsmasq.

What?  Why not?  Caching is done based on TTL, not based on the 
RRtype.  If the upstream server gives you a zero TTL, then that 
record is not cached ... regardless of RRtype.

> During my tests the first IPv6 DNS server was always the fastest 
> replying server and for this reason the answer from this server
> is passed to the client always,

Do the answers from other upstream servers differ?

> After some time the dnsmasq relay is not forwarding the requests to 
> the four known DNS servers any more but only sends out the requests 
> to either the first IPv4 DNS server or the first IPv6 DNS server. 
> So only one server is used. After about 20 seconds (4 requests 
> later) the dnsmasq process falls back to the expected behaviour of 
> sending the request to all known DNS Servers.

I guess there is an implied "but the server fails to answer" in this, 
and it presents yet another reason why you might want to consider 
these ISP nameservers unreliable.

> does anybody knows the reason for this?

See --all-servers and --server in the manual.
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

More information about the Dnsmasq-discuss mailing list