[Dnsmasq-discuss] Finding actual DNS server used

Albert ARIBAUD albert.aribaud at free.fr
Sun Jan 15 08:58:38 GMT 2017

Hi Lars,

Le Sun, 15 Jan 2017 10:21:01 +0200
Lars Noodén <lars.nooden at gmail.com> a écrit:

> On 01/15/2017 09:55 AM, Albert ARIBAUD wrote:
> > Hi Lars,
> > 
> > Le Sat, 14 Jan 2017 20:18:13 +0200
> > Lars Noodén <lars.nooden at gmail.com> a écrit:
> >...  
> >>  Because it's not my system and it is remote, I
> >> have to go step by step, slowly.  
> > 
> > ... Do you mean that you have good control of the remote system but
> > have to go there physically to run tests, or that you do not have
> > control of the system and must ask someone else to perform tests
> > there? This makes a difference in the way you can run your tests  
> I have to describe the steps in e-mail and they are then carried out
> on site by a non-technical person.


> >> Since everything on that system, in
> >> regards to DNS, is going via Dnsmasq, I'd like to see what it has
> >> loaded and is using.  
> > 
> > This bring me back to your description of the bug above: "somewhere
> > early on the DNS fails". What do you mean with that? Did you check
> > that the client keeps sinding DNS requests to your dnsmasq?  
> The client application (Blink) will apparently default to Google's DNS
> if it cannot connect to the server right away.  What's happening is
> that half the time DNS replies, half the time it times out.  Thus the
> client can start to register with the SIP server, but then fails to
> publish its presence or be able to initiate a call.
> > ... Or is
> > it that they come back from your dnsmasq with an error code for
> > domains which you know your dns should resolve properly?  
> It seems to be this -- sometimes.
> So is the short answer that there's no direct or easy way to poll a
> running Dnsmasq instance and see what it's pointing to?  If so, then
> I'll not bother the list more with this issue.  However, may I put in
> a feature request if there is a wish list?

See my other replies, but I'll make the main suggestion: the way to get
the info you want (and more, which might be useful for your diagnostics)
is to run tcpdump on the dnsmasq host on the "any' interface (or run
two tcpdumps, one on the interface used to talk to the client, one on
the interface used to talk to the Internet) with a capture filter set
for DHCP and DNS protocols, and write the capture into a file (or two,
if running two tcpdump instances). Then if you have two captures you
can use Wireshark's mergecap tool to merge them into a single one. Last,
you open the single capture file in Wireshark and see:

- whether your client was sent out a DHCP reply configuring DNS servers

- which DNS requests your client sent to dnsmasq

- which DNS requests your dnsmasq sent to which upstream server

- which DNS replies your dnsmasq received from which upstream server

- which DNS replies your client received from dnsmasq

That's the info you're asking for (of course, I assume you have control
of the host running dnsmasq) and much more. The method can be useful
for diagnosing other network or protocol issues as well.

Speaking of which, my first hunch re your problem is that it's not a
dnsmasq problem, but a problem with the client's networking
configuration. I suspect it connects through some VPN and gets an
additional (or replacement) DNS, and that at some point the VPN
connection goes bad and the client reverts (in part or in full) to its
original DNS.

In any case, the test above will give you a hint about that too: if you
see that the client stops sending requests at some point, you can
pretty much conclude it stopped using your dnsmasq as its DNS (you can
even know when it last did, and compare that with logs from the client
if you can get the non-tech person to do it.

BTW: I suspect there is no way to get the non-tech person to install a
remote access client (even ssh would be enough) and also no way for
you to get root privileges on it?

> Regards,
> /Lars


More information about the Dnsmasq-discuss mailing list