[Dnsmasq-discuss] Finding actual DNS server used

Albert ARIBAUD albert.aribaud at free.fr
Sun Jan 15 08:21:25 GMT 2017

Hi Chris,

Le Sat, 14 Jan 2017 19:27:28 +0000
Chris Green <cl at isbd.net> a écrit:

(re getting dnsmasq to say which upstream servers it uses)

> Why is is so difficult to provide this information?  At the very least
> it would provide a confidence check that all is working as intended.
> It might very well help if something isn't working too.

It is not difficult at all to get this information. It's just that
dnsmasq does not provide any "API" to get it, because it's easy to get
it  otherwise for diagnosis purposes.

For diagnosis, the operator can:

- read the configuration file(s) dnsmasq uses and find "server="
  lines in it, and read the /etc/resolv* tree, if dnsmasq uses them,
  and that will give the list of servers dnmasq uses at any point in

- log DNS queries, which will give the additional info about
  which client actually queried dnsmasq, which queries were cached vs
  sent upstream (to which server), and what the answer was.

- run tcpdump or wireshark on the dnsmasq host or on the DNS client (or
  both for troubleshooting e.g. timing-related issues). This will give
  a full view of DNS exchanges on the considerd machine, to the last
  bit, litterally.

So, from a diagnosis point of view, pulling the actual list of servers
from a running dnsmasq is not that much of a need.

I don't mean to say that such an "API" would be unneeded for other
requirements than network troubleshooting, and if it existed, I would
use and suggest it for troubleshooting too; but here, I mean to say
that helping solving Lars' problem does not require such an "API".

I feel that Lars' question was more "How can I troubleshoot my possibly
dnsmasq-related issue?" rather than "How can I find which servers my
dnsmasq uses?", and for this, we have the means above, which emcompass
the one Lars asks for and go well beyond -- plus, the first step to
troubleshooting an issue is to get the situation as precise as
possible, possibly ignoring the initially assumed cause (here the list
of upstream servers may be actually correct and the issue may be on the
client side, so the "API" question should be set aside, and getting a
more precise view of the issue should come first).

> For example if my machine can't connect to another machine on the LAN
> but can see the outside world it suggests it's getting DNS from
> something other than my Pi DNS server.  If I could check what DNS it
> is using then it would confirm that either it has got it's DNS set up
> from somewhere else or that it has got the right DNS (the Pi) but that
> the Pi is set up wrong somehow.

This case can be tested (and boy do I know it) with the host command on
the client as Jim suggested (although I personally use dig).


More information about the Dnsmasq-discuss mailing list