[Dnsmasq-discuss] Finding actual DNS server used
albert.aribaud at free.fr
Sun Jan 15 11:14:42 GMT 2017
Le Sun, 15 Jan 2017 09:53:00 +0000
Chris Green <cl at isbd.net> a écrit:
> On Sun, Jan 15, 2017 at 09:21:25AM +0100, Albert ARIBAUD wrote:
> > 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
> > time.
> There aren't any! These are systems where dnsmasq is run by Network
> Manager rather than directly, thus there is no spcific dnsmasq
> configuration file.
... and then the configuration is known from the dnsmasq process command
line. So let me amend my statement above: "... read the configuration
options, from the dnsmasq process command line if it contains any, and
from the configuration file or files if applicable".
> > - 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.
> It would be a whole lot easier than the above though wouldn't it?
It would be more straightforward, but not a whole lot easier: the
tcpdump command is dead simple, as is reading the wireshark log.
> To 'log DNS queries' one may have to actually stop and start the
> system and that may well make the problem one is trying to look at
So would modifying the dnsmasq code to add diagnostics-related
features, actually. :)
Seriously, though: diagnostics always run the risk of affecting the
issue anyway. Even doing a tcpdump could stop a time-sensitive bug fom
So I don't personally consider the 'debugging risks affecting the
issue' criterion much.
Besides, in my empirical experience, the specific act of turning
logging on for DNS or DHCP never affected any issue I ever came
across, except in the sense that it helped pinpoint the root cause, but
of course YMMV.
Note: if stopping/starting the dnsmasq server [without any logging
added or removed] makes Lars' client work again, then it is valuable
input to diagnosing the issue.
> Both tcpdump and wireshark are quite esoteric utilities, it would take
> quite a bit of knowledge of using them to extract the required
I would disagree on the 'esoteric' point, or at least I would make a
difference between becoming generally proficient with tcpdump/wireshark
and using it for a given purpose.
Indeed, if trying to master all of tcpdump/wireshark's features, these
tool will look quite esoteric.
But one does not need to /master/ tcpdump in order to get a capture of
DNS traffic; one does just need to install the tools (which is *not*
esoteric) and to know which commands to run (and finding thes commands
it not an esoteric task either; it takes less than a minute's googling).
Granted, that won't make this person a tcpdump guru, but it will get
the DNS diagnostic job done.
> Surely there's a case for something that simply lists the upstream DNS
> servers that a dnsmasq instance is using.
Which would it be? For DNS troubleshooting, equally simple tools can be
used (and put to good profit later on for other network issues).
More information about the Dnsmasq-discuss