[Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour

John Knight John.Knight at belkin.com
Wed Oct 12 22:49:50 BST 2016


Hi,

I am having an issue with dnsmasq version 2.55.

First a little background about when the issue occurs: In our router, we have both an ether wan port and a 3G dongle.  If the wan cable is plugged in, the connectivity to the internet is via the wan cable.  However, if the wan cable is unplugged and there is a dongle plugged into the router, connectivity to the internet now switches to the 3g dongle.  In essence a switchover occurs.  What we have found is that the dnsmasq's dns sometimes fails after the switchover.  The /etc/resolv.conf file in this case remains the same before and after the switchover.

I have invoked dnsmasq with the debugging option -q, and I see that at time 22:09:33 a message "no servers found in /etc/resolv.conf, will retry". Presumably this is because at the time dnsmasq found that it could not connect to the google dns server 8.8.8.8, probably while the connection was being switched over.  For nearly an hour according to the dnsmasq.log file, I see various queries to dnsmasq asking for IP addresses associated with the given URLs.  Unfortunately, no response is given to these queries.  During this period after the switchover, I can ping the google dns server at 8.8.8.8 and it responds; I can NOT ping google.com as it fails to resolve the IP address for google.com.  I can also ping other IP addresses successfully after the switchover as long as I ping with the IP address and not the URL.  Nslookup consistently fails to resolve the IP addresses.  So it is pretty certain that we have connectivity to the internet, just no DNS server to help return the IP addresses for the URLS.

Now back to the dnsmasq.log, at timestamp 23:08:02 we finally see the message "reading /etc/resolv.conf".  After this dnsmasq is now successfully answering the queries from the clients, resolving their addresses once again.  >From my perspective, it appears that there is something wrong with dnsmasq not doing the retry to connect to the upstream dns server (8.8.8.8) in a timely manner.  I have now seen this anomaly twice, both times with a delay of almost exactly an hour for the dnsmasq to come back to life. The immediate question is what is driving how often does dnsmasq do the retry?  I would think that if the upstream dns server is not accessible, it would retry and a fairly short time interval... but alas, I don't see this in the dnsmasq.log file. How often should dnsmasq be retrying?  And what would do you think would make it retry at almost exactly an hour later?

Is this a known issue?  I have looked at the CHANGELOG and I see only a few changes that from their description might be related... changes in version 2.72:

version 2.72
            Fix race condition which could lock up dnsmasq when an
            interface goes down and up rapidly. Thanks to Conrad
            Kostecki for helping to chase this down.

            Fix bug which caused dnsmasq to become unresponsive if it
            failed to send packets due to a network interface disappearing.
            Thanks to Niels Peen for spotting this.

But alas, I don't know if these fixes have anything to do with the issue I am seeing; there is not enough info here to know how the issues manifested themselves.
I have attached the dnsmasq.log file for you review.
Please let me know what you think.  I need to get to the bottom of this asap.
Best Regards,
John Knight




__________________________________________________________________ Confidential This e-mail and any files transmitted with it are the property of Belkin International, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Pour la version fran?aise: http://www.belkin.com/email-notice/French.html F?r die deutsche ?bersetzung: http://www.belkin.com/email-notice/German.html __________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20161012/fdce9af6/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dnsmasq.log.txt
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20161012/fdce9af6/attachment-0001.txt>


More information about the Dnsmasq-discuss mailing list